Re: PATCH: compadd (+ questions)

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

On Feb 10,  5:26pm, Peter Stephenson wrote:
} Subject: Re: PATCH: compadd (+ questions)
}
} 1) I suspect most people are going to use much of it as it stands, and
} just alter what they want.  (Who the *other* people might be, I cannot
} imagine.)  So might it be an idea to find a more general name than
} my-comp, and also to define widgets using main-complete for all the
} standard completion functions, not just expand-or-complete?  And
} perhaps do some trickery with bindkey output to rebind any keys using
} the old ones to the new ones?  Some way of supplying options to
} new-completion-examples would be good.
} 
} 2) Currently, existing compctl's take precedence over any of the new
} style functions for given commands.  That's sort of reasonable at the
} moment, since many of the new-style functions are examples rather than
} complete systems.  I wonder if there's a better way of deciding this.
} If we implement something like 3), it might be better for the
} new-style ones to take precedence.

Addressing both of these questions together:

I do think it's a good idea to make the examples as directly usable as
possible, and therefore to carefully choose descriptive names for the
various functions (nothing so uninformative as "my-comp" nor as generic
as "files").  It's probably also a good idea to have separate examples
emulating as many of the old built-in completions as possible, so that
people have "building blocks" from which to construct completions that
have effects similar to the built-in set or combinations thereof.

That'll also provide a good set of test cases to see whether we've (a)
achieved the goal of writing something more understandable than compctl,
and (b) made all the necessary bits of the functionality available to
the shell script programmer.

However, for the simple cases I'm concerned that calling interpreted
shell functions will be "too slow" and we shouldn't encourage people to
simply load up the examples en masse.  Has anybody done any speed
comparisons on having zsh call the old-style compctls directly, vs. the
new-style stuff firing `compcall`, vs. doing the entire thing with the
new stuff?  I confess I haven't had much chance to play with this.

} 3) As far as the example functions are concerned, it might be an idea
} to separate them out into their own directory so they can be
} autoloaded or copied for autoloading.  How about this:  they get
} separated into a directory, and then some code in the main file scans
} that directory and decides file by file how to call defcomp.

This sounds like a good idea.  BTW, defcomp and friends could use some
more commenting up front.  The meaning of, say, "--default--" as the
second parameter to defcomp should be explained near the definition of
defcomp, either instead of or as well as down in main-complete when the
associative array is finally referenced.

 ----------

As to goal (a) above:  This is the first time I've really taken the time
to read through the new-completion-examples file, and I find myself
disappointed by a couple of things that sounded good in theory.  Part
of it may just be Sven's coding style; can we use better variable names
than "a", "b", c", "opa", "epre", and "ppres", please?  It's bad enough
having that in the C code, without exposing mere mortals to it.

I think the worst are the new switches for the conditional expressions,
particularly the ones that take two following strings; it looks wrong.
I just spent several minutes pondering whether [[ -word CURRENT-1 -ef ]]
would look better to me than [[ -current -1 -ef ]], and decided it's
only marginally better.  It using -current or -word a lot faster than
using [[ $@[CURRENT-1] == '-ef' ]]?  Are they doing some other magic?

For the conditionals that don't use two strings, I think some of the
keywords could be better, but I don't yet have a list of suggestions.
Maybe it's just the 'm' prefix on the ones that take a pattern that
bothers me, and which also makes me wonder for a moment whether there's
supposed to be a -matches is when I see that there's a -nmatches.

Also, and I apologize for not responding more immediately to Sven from
zsh-workers/5083, I must say that the way that -iprefix, -position and
-string have parameter-modifying side-effects makes me cringe.  It'd be
fine in another new builtin, but a [[ ]] with side-effects?!?  Yipes!

Don't go changing anything yet just on the basis of my opinion, though;
I'm only trying to hear some discussion about this stuff.  I realize
that the side-effects are merely mirroring the state of the completion
internals, I just question letting this happen from [[ ]], and maybe
whether there should be a builtin equivalent of compsave/compreset.

I should close by saying that I *am* impressed, overall, with the new
completion scheme and the possibilities it presents.  I'm particularly
glad of way it and PWS's completion widgets were able to collapse into
one system.  I think the progress is good, and that we should keep on
speeding towards something even more marvelous.

(BTW, the contract I was supposed to be starting was postponed until
this coming Monday.  Once it starts, my contributions will be rather
limited for several weeks.)

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com