Re: PATCH: compadd (+ questions)

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Peter Stephenson wrote:

> Just some queries about the new-style completion.  I'll put the more
> general questions first, then there are some more specific questions
> mainly to do with compadd.
> 
> First... I was looking at new-completion-examples and wondered:
> 
> 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?

The new-completion-example file is still a hack. I was planning to
clean it up anyway. As for the name: yes, I took that name to make it
the same I used in the description I sent in the mail. I hadn't
thought about the bindkey-trickery, though.
I also thought about adding a function that lets you bind special
completions to certain keys even more easily than in your replacement
functions for the old `zle -C'.

> Some way of supplying options to
> new-completion-examples would be good.

I don't understand what kind of options you mean here.

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

YES. Of course I made it this way to get people to test the new style
completion stuff. To those who want the new completion functions to
take precedence I suggust removing the call to `compcall' and the
replacing the function __default with:

  [[ -nmatches 0 ]] && compcall -TD

Until we find the final solution.

> 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.
> 
> For example, the file __default might contain
>   #defcomp --default--
>   files
> and then new-completion-examples can contain something like
>   local d f a
>   for d in $fpath; do
>     for f in $d/__*(N); do
>       read -A a <$f
>       if [[ $a[1] = '#defcomp' ]]; then
>   	defcomp $f:t $a[2]
>       fi
>     done
>   done
> Users can then put this directory where they want in their $fpath and
> add or subtract from it to get autoloading of completion functions.
> Also new-completion-examples can have a shorter name in its own
> directory.

I wanted to split the file into separate files and make them
autoloaded, too (that's why I added the `-a' option to defcomp).
Again, I hadn't thought about something like this loop, but I like it.

> Next... I'm late replying to this, but I was just looking over the
> new-style completion again and had some niggling questions...  I have
> half an eye on documentation for this new stuff, which Sven should
> probably have a go at first, although I think with something this
> involved it's good if someone other than the author makes sure they
> can understand it.

When I first sent the patch for all this, I hadn't tested it that
much and thought that probably some things might still change. After
using only the new style completion since the beginning of this year
(and after several fixes, of course) I'm starting to have more
confidence. So I already began to think about writing the manual, but
I don't know when I'll find the time for it.
And having a reputation for writing short and hard-to-understand
manual entries (in a bad English), I always hope others have a look at 
what I write and amend it.

> Sven Wischnowsky wrote:
> > Since `compadd' is the interface to the internals of the completion
> > stuff, it should be possible to use to add any words as matches. But
> > sometimes you probably want to use it only to have control over the
> > prefix/suffix- or the match-type stuff.
> 
> Does this mean a compadd without new matches alters what's there
> already, or what's to come, or are you simply saying you can have
> better control over what you are adding?

The last one. Only with `compadd' you can control all the strings and
flags stored for each match directly.

> > So, the patch below adds the `-m' option to `compadd'
> > which says that the completion code should use normal matching rules
> > to the words given. Of course, for this the `-M' option known from
> > `compctl' and `complist' is also supported.
> 
> This is fine.  Tests with with complist (compcall must be similar)
> suggests that uses the standard rules, is that right?  That would also
> be what I would guess.

Yes, `complist' behaves like `compctl' (and one could say that
`compcall' is `compctl').

> > Another small addition: the option `-F' says that fignore should be
> > used (in the same way as it's done by `compctl').
> 
> Would it not be just as easy to be able to specify a $fignore-type
> variable (maybe in the `compctl -k ...' fmt so you can add literals)?
> If it isn't, it doesn't matter, but I thought maybe that's no
> harder than hard-wiring $fignore in.

Hm, there are a lot of things I hadn't thought about, this is another
one. Meaning: yes, it would be easy to add.

> (Does this do any more than
>   for suf in $fignore; do
>     for match in $matches1; do
>       [[ $match = *$suf ]] || matches2=($matches2 $match)
>     done
>   done
> ?  I can see it's a lot more efficient, anyway.)

It does this plus the scheduling into what I have sometimes called the
list of alternative matches. These alternative matches are those that
match with fignore ignored and are used only if there are no matches
with fignore used.

The options `-m' and `-F' belong together, I wanted to make `compadd'
more user-friendly for those cases where one wants to add some matches
with, e.g. a generated path-prefix, and get all the matching
`complist' does without having to program it all by yourself.

> > And yet another one (this one may still be experimental): `-r <str>'
> > says that the suffix should be removed if the next character typed is
> > one of those given in `<str>'.
> 
> Is there a decision on how this is going to work after Bart got at
> the last proposal?

I'm currently thinking about keeping the `-r ...' option and adding a
`-R func' option that gives a function to be called to remove the
suffix when it is left unchanged by the `-r ...' stuff or the internal 
suffix-removal-code (the non-inserting stuff known from `compctl').

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx