Re: completion oddity

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On May 22,  6:55pm, Greg Klanderman wrote:
}
} OK, thanks for looking into this Bart.  So _main_complete is still
} looping over zstyle matcher-list values in completing parameters but
} it's not used?  I do see that _arguments uses _description which uses
} _matcher if non-empty (as you noted earlier).

Hmm, hadn't thought about that ... _parameters calls _wanted so it does
go through _description, which means the matcher-list is also applied
to parameter names.  At this point I have no idea whether that is
intentional.

} I have to confess I cannot follow all this completion code though.

I'm not sure anyone can.
 
On May 22,  7:09pm, Greg Klanderman wrote:
}
} > You're right; in the first case the completion system has recorded a
} > list of "ambiguous positions" that distinguish what it filled

Sorry, thinko there -- it actually records UNambiguous positions, and
insert_positions which are the places that something needs to be added
or changed in order that the word on the line match one of the possible
completions.

} Oh the horrors never end.. could you be so kind as to point me to some
} of the relevant bits of code that are doing this logic and how that
} state is stored?  Please tell me it's not in the even more
} impenetrable C code..

The state is available in the compstate hash, which is actually pretty
thoroughly documented (though exactly what the internals do with the
values isn't, so much).  However, yes, the logic that figures out what
are insert_positions and what are unambiguous_positions is all deep
in the C code.  There is exactly one example of shell code making use
of one of those values:  Functions/Zle/cycle-completion-positions --
but it's not very helpful.