Reading completion manual

["Andrej Borsenkow" <borsenkow.msk@sni.de>]

[Not having a car has it's advantages - you can read zsh completion manual
on the way home :-)]

Some random comments/questions

1. compctl -K parameter

I don't like the new convention to make underscore magic. IMHO it is the
same hack, as before, but it can possibly cause havoc. Underscore is pretty
well established for "private" names, and I expect, that some users really
use it in this way (I did at least). That is, define "helper" functions as
started with underscore as opposed to "normal" ones that are expected to be
called directly.

I think, the possible solutions are

 - use new option character (do we have one free?)
 - implement long options
 - (really wild one) implement name spaces.

I'd like the last one, but it is probably impossible. A command name may
have any character, so there is simply no char that can be (safely) used as
delimiter. So, long options is probably the only viable solution. And quite
useful in other places as well.

It may be useful to interpret return code from such a function (a lá -t).
Consider:

compctl -T -K _default

_default () {
    case $compstate[context] in
       redirect )
             do redirect completion
             return 1 # stop any more processing
       ;;
          ...
     esac
     return 0 # do normal comcptl command/argument completion
}

This is easy way to add hooks for new extended stuff that compctl cannot
handle.

2. PREFIX, IPREFIX, SUFFIX

I'd like to have some way to atomically modify them. What I mean is, I'd
expect it to be a common source of errors, when somebody modifies IPREFIX
but forgets to modify PREFIX (or does it incorrectly). So, some command,
that could be used to remove string from PREFIX *and* add it to IPREFIX as
atomic operation is quite usable. I understand, that one may want to modify
them independently, but this should be really unusual cases.

How *PERFIX and SUFFIX are related to words[$CURRENT]? When I modify PREFIX,
does it change current word? Other way round? Or are they "read-only" (with
exception of IPREFIX<->PREFIX relation)?

Do I understand correctly, that PREFIX/SUFFIX respect COMPLETE_IN_WORD? That
should probably be explicitly mentioned.

3. compgen

I never used explanation myself, but still ... What happens, if I use
several compgen's with different explanation strings? What happens, if I use
several compgen's with different listings (-y parameter)? Are they merged?
If yes, how?

4. compadd

It's impossible to understand (based on manual) how -P, -p -i actually work
(the same for suffixes). This definitely needs not only better description,
but some examples as well. And how it all plays together with -W?

Do I understand correctly, that normally compadd only adds strings if they
match command line? It is implied, but is not stated explicitly.

5. compcall

As I vaguelly remember, compcall now returns result codes? Is it correct?


Applied to all three: what about some return code to indicate, if some
matches were added? Currently one has to save, and then compare,
compstate[nmatches], that looks somewhat ugly. Using return code would
provide for

compgen -k friends || compgen -u

Looks better for me. Probably, this idea could be used for all helper
functions as well - is it useful?

6. Conditions

As most of us, I don't like the idea of conditions with side effects. But I
don't like the Sven's suggestion of replacing conditions with shell code
either (at least, with *THIS* code :-) Even more, as it does not solve the
original problem - you still have to save parameters and restore them after
that. I'd suggest something in between - conditions set special parameters
(elements of hash?) that can be used to extract matched substrings/words.
That is almost the same, as Sven's suggestion, but probably more
user-friendly :) something like

if [[ -between string1 string2 ]]; then
   local -a nwords
   nwords=(words[$FIRST,$LAST])
    ...


There is no way to say "from here to eternity", you are forced to set
``end'' to some silly large value. What about using literal string "end" as
possible value for ``end''?

Description of -nmatches and -matcher still use NMATCHES and MATCHER. Is it
correct?

cheers

/andrej