Re: Redirection completion

[Sven Wischnowsky <wischnow@berkom.de>]

[I'm withholding the patch for now...]

Many questions from Bart:

> ...
> 
> Firstly I'd like to keep the "flavor" of redirection tightly associated
> with the word `redirect', i.e. rather than
> 
> 	-redirect-echo-2>
> 
> It should be
> 
> 	-redirect-2>-echo

That's ok, I think.  What do you suggest for values, then?
`-value-<name>-<type>-<command>'?  <name> is the parameter name,
<type> is scalar/array/... and <command> is only set when completing
after something like `make FOO=<TAB>'.  That, by the way, is the
reason why I put the command directly after the `-value-' or
`-redirect-': it can be there in both cases.

> Then, I think, it would not be necessary to try each of `-redirect-',
> `-redirect-2>', and `-redirect-2>-echo' in turn, because styles could be
> written easily with wildcards e.g. `-redirect-*' or `-redirect-2>*'.
> 
> Unless I'm missing something about why all three are tried?

Yes.  The main reason for this is that I want it to be easy to define
functions (not styles) for types of redirections or for parameters
without having to use `compdef -[pP]' everywhere.

> This points up the second change I'd like to request:  Make this style
> fragment work the same way that styles in general work, e.g., define a
> fixed set of delimiter-separated segments and have them always be there
> even if sometimes empty.  E.g. supposing we switched to comma as the
> delimiter, as Sven tossed out in one of the earlier messages on this
> thread, the context would look like `-redirect-,2>,echo' and if for some
> reason the command name were not known it would be `-redirect-,2>,'.

I've actually been thinking the same (before that idea with the
comma).  I'd prefer a solution where the different can have at least
almost the same meaning in every case, though (i.e. values and
parameters for now).  Just as we did with full context names.

> I suppose strictly speaking the first of those commas could be omitted
> because we must always know what redirection operator we're dealing with
> (else we wouldn't be in -redirect- context at all), e.g. `-redirect-2>,'.

If we go this way, I'd be in favour of putting it there -- it might
also make the description in the docs easier (`some functions
redispatch and modify the context name to show this, leaving the base
name of the command/context field and appending to it the more precise
description, separated by commas').

> Random additional comments:
> 
> If we do stick with hyphens, what does the context look like in the case
> of completion after:
> 
> zsh% - 2>
> 
> (It's perfectly legal syntax to put the redirection anywhere on the line,
> even before the command for which the precommand modifier is intended.)

Since completion for redirection is determined on the same lave as
_precommand would be found, you should (haven't tried) currently get
`-' in the command part.  Hrm, that's ugly, obviously, because you
would get the same for `- foo > <TAB>'.  We've got to thnk some more
about this...

> If we instead switch to commas, what do we do in case of a command named
> `,'? (I knew people in grad school who used a csh script named that, for
> reasons too obscure to go into).  On a similar note, do we need to fix
> somehow the existing contexts for completing after the `:' command?

Hrm.  We could quote the separation character if it appears inside the
command name.

> Different tack:  If I have
> 
> zsh% ls >
> 
> with the cursor positioned ON the `>', what context(s) get tried when I
> press TAB?  I might expect it to complete file descriptor numbers ...
> and in that case, I'd want to complete only the numbers of *valid* file
> descriptors, but those aren't available to shell functions (yet).

Yes that would be nice.

Currently you should get argument completion (but strangely, trying
`echo ><TAB>' shows that `-command-' is tried, only after `echo foo ><TBA>'
do we get argument completion -- I'll have to have a look).


Bye
  Sven

-- 
Sven Wischnowsky                          wischnow@berkom.de