Re: PATCH: compadd (+ questions)

[Peter Stephenson <pws@xxxxxxxxxxxxxxxxx>]

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

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.


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.

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?

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

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

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

-- 
Peter Stephenson <pws@xxxxxxxxxxxxxxxxx>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy