Re: Per command _redirect completion

[Sven Wischnowsky <wischnow@xxxxxxxxx>]

Oliver Kiddle wrote:

> 
>  --- Sven Wischnowsky <wischnow@xxxxxxxxx> wrote: > 
> 
> > And one (mostly) unrelated remark: in a private mail Oliver asked if
> > it were possible to supply the completion widgets with a list of
> > redirections on the line. Collecting this information shouldn't be
> > too
> > complicated. Any suggestions for how we should pas this information
> > to
> > the completion function? An array containing values of the form
> > `<redir-op>:<word>'?
> 
> The array sounds reasonable. What happens with something like 2>&1?
> What can the redir op be - just < and > or a variety of things. What
> about another command being piped to the one it is completing.

You can have a look at it by trying completion after various
redirection operators and then using `echo $_lastcomp[redirect]'.
They are the ones you can see in the table at lex.c:128. There are
almost certainly some interesting things missing (e.g. the descriptor
number used in `2>...'). Just some more things that would have to be
put into that array (and the lookup string in _redirect).

Pipes are generally not supported currently -- separates different
commands and that part of the code is pretty old.

> > diff -ur -r ../oz/Completion/Base/Utility/_contexts
> > +# You may also select the assocs to use with the `-T assoc' option.
> 
> I know we only renamed it a year ago but _contexts perhaps could be
> better named.

Hm. I don't think it's too bad, but then I'm not a native English
speaker.

> > diff -ur -r ../oz/Completion/Zsh/Context/_value_PRINTER
> > ./Completion/Zsh/Context/_value_PRINTER
> > @@ -0,0 +1,3 @@
> > +#compdef -T values PRINTER LPDEST
> > +
> > +_printers
> 
> Do we really want lots of tiny little functions like this one? Can't we
> just stick the compdef line in _printers itself. We have a compdef for
> commands like rmdir in _directories which is a similar situation.

Seems that I didn't make it clear enough that I only consider the core
of this patch to be near its final form (basically the code in
compinit and _normal, where the latter will be slightly modified and
moved to a separate function). I just didn't want to change too many
functions that won't have to be changed anyway.

The way it's implemented we have many different possibilities for how
to handle this. For some of the functions we have already we can, as
you correctly saw, modify already existing function-files like
_printer, for others we could group them together in a single file and
use $service to decide what exactly to complete (grouping together
parameters or redirections that belong together in the same way we
already do it for commands). And for others we can use new files as in
this example patch.

> Have I also understood correctly, that the compdef changes allow
> multiple uses of -T so that _gzip might start with:
>     #compdef gzip gunzip gzcat=gunzip -T values GZIP

Right. Good? ;-)

> Sorry, but I've only had time to glance over this. I'll try it out and
> reply more fully later.

Thanks!


Bye
  Sven

-- 
Sven Wischnowsky                          wischnow@xxxxxxxxx