Re: Some possible bugs...

[Sven Wischnowsky <wischnow@informatik.hu-berlin.de>]

Bart Schaefer wrote:

> } The problem is that in things like `zsh -c "ls <TAB>' one doesn't want 
> } the shell to treat the `"ls ' as one string. So when completing inside 
> } quotes, zsh treats words separated by spaces as outside the quotes.
> 
> How hard would it be to make this context-sensitive?

Well, currently this is done by get_comp_string() which calls the
lexer and this *has* to be done at the very beginning, because we
first have to get the command line words and position to find out
which compctl to use. However, we could remove all this quote-removal
stuff and make it always just return the whole quoted string.

> For example, when
> the effective compctl says to complete file names, treat the entire
> quoted string as one word and attempt to complete it as a file (this is
> what bash appears to do); similary for command names or anything else
> that normally results in a single shell "word"; otherwise, complete the
> way it's presently done.  This might require another compctl option,
> similar to using	compctl -x ... -l '' ...	except that the
> "range of command line words that are considered to be arguments" is a
> single word that has to be split at IFS before completing.

I think this wouldn't be enough. One example is the:

  % zsh -c "ls 'foo b<TAB>

I mentioned. This should complete to 'foo bar' if there is such a
possible match. So we would need a way to `remove one level of
quotes'. But the quotes may also contain things where we would need
the whole lexing/parsing if we suddenly decide to work on the parts of 
the quoted string. And, of course, such a quoted string may contain
other quoted parts on which we may or may not want to work separately.

> So to get the current behavior you'd use something like (writing old style)
> 
> 	compctl -x 'c[-1,-c]' -1 -l '' -- zsh
> 
> where I'm using -1 as this new option I've described for no better reason
> than that I can't remember which (if any) letters are left for compctl.

(The only free letter is `h').

> This would also mean that, in the case where a single word such as a file
> name is expected to result, zsh could automatically close the quotes and
> append a space after the closing quote.

Sure, yes. Enhancing cmatch a bit...

> This so-called -1 option could apply to any other flag that followed it,
> not just -l ... generically, it would mean "unquote and split the current
> word, find a new current word after the split, then complete using the
> following flags, and finally requote the result."

If we really want `all flags *following* it' we would have to change
the argument parsing of compctl, which is already pretty complicated.
If we just let it work on all flags surrounding it, at least the
parsing would be simple (of course).

I confess that I hadn't thought about a flag that `works like -l'
(without trying to implement it I would prefer to make it work like -l 
in that it doesn't have an effect on the surrounding flags -- I think
this would be much easier to implement, but I may be wrong).
This sounds good to me, with that we could even use the lexing code
(calling it on the string we should work on). However, if this gets
mixed with completions for the whole quoted string, keeping track of
the positions (where to re-insert the completed string, etc.) may turn 
out to be complicated. Hm, using the quote-removal code when handling
this flag and not using the lexer may be easier, but wouldn't allow us
to complete at places like `zsh -c "[[ -o <TAB>'.

For the new completion system we would need a way, too. We could use
something I've been thinking about when we were discussing it at the
beginning. We could give an option to compset which gets one string as 
argument, parses it and stores the result in $words, $compstate,
$IPREFIX, and so on.

Bye
 Sven

P.S.: I'm mainly thinking about ways to implement this, so some of my
      remarks may be hard to understand, sorry.

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de