Re: PATCH: compadd (+ questions)

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote:

> 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.

As I have said, the current examples are a mixture of hacking and
re-implementing stuff from the old completion examples. This was
thought to show to people on the workers-list how to use all this
stuff in real-world examples.

> 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.

This was another goal of the example file. Some of the patches I sent
after the initial patch for the new style completion were results of
using the examples and finding bugs, omissions, or better ways. But I
simply need some help in evaluating all this.

> 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.

The difference between `compctl' and `compcall' shouldn't be too
big. As I already said, I have been using only new style completions
all this year. For now, the speed is acceptable (meaning that it
doesn't interrupt things noticeably). Also, my zsh is compiled with
all debugging and without any optimisation, so in a zsh for work, this 
will get faster (and of course this also depends on the machine you
use, I have a older Alpha, dunno how this compares to a Ultra or
Pentium).

> } 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.

This (and the comments) will certainly be cleaned up in the final
version.

> 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.

All these are things I didn't like that much, too. Most of the
conditions were added for completeness' sake.

> 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.

This is what I was questioning again and again from the beginning. For
really clean completion functions we would need a new control
structure to be able to put all tests into one function and having
everything reset to the previous state automatically. Doing something
like:

  if comptest iprefix '-'; then
    ...
    compreset
  else

wouldn't be that easy to glark, too. I have been thinking a lot about
better ways to do all this but haven't found an answer yet (given that 
we won't want to add a new syntactical construct for this).

> 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.

Yes, and now that Peter has started, maybe we can get a discussion
about all this.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx