Re: Completion problems.

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Tanaka Akira wrote:

> In article <199908040937.LAA15313@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
>   Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx> writes:
> 
> > I see two ways to go: 1) completely change the completion code to
> > report strings in unquoted form or 2) add a parameter expansion
> > modifier which does something like the opposite of `:q'.
> > Unfortunately, 1) is extremly hard and error-prone.
> 
> I think that (1) is right way though I didn't know it's extremly hard
> because I'm not know the code internal well.

I still don't think that 1) is the right thing to do because some day
someone might come and want to be able to see which words are
quoted. Reporting them as they appear on the line is the only way to
achieve this and together with the Q modifier/flag one can always get
at the unquoted forms.

> > Also: changing a'#' to a\# is intentional and was discussed -- see
> > 6400 and follow-ups (especially 6460 for this example). 
> 
> Ok, I understand. I didn't think match specs.  But... is this
> intentional?
> 
> Z:akr@is27e1u11% zsh-3.1.6-pws-1 -f
> is27e1u11% autoload -U compinit; compinit -D; compdef _tst tst
> is27e1u11% _tst () { compset -P '*/'; compadd tst }
> is27e1u11% var=val
> is27e1u11% tst 'a'$var/<TAB>
> 
> -> 
> 
> is27e1u11% tst 'a$var/tst' 

Yes, it is, err, no it isn't, err -- well I didn't think about the
possibility of $var stuff after the closing quote.


In a message with a completely different Subject Andrej Borsenkow wrote:

> bor@itsrm2:~%> zsh -f
> itsrm2% autoload compinit;compinit -D
> itsrm2% l /t/b/{zsh<TAB>
> itsrm2% l /tool{s/bin/zsh
>               ^^^
> Note, that the brace was (re)inserted at the old place. If I now try to insert
> something with accept-and-menu-complete, it will correctly insert the
> ``s/bin/zsh-xxx'' - but, it is rather unexpected. And, users will probably
> expect, that they simply can type in ``,zsh.old,zsh-what-ever}'' - and this does
> not work any more.

We lost it when we made _path_files do the matching via -D and add the 
matches with -U. This *is* a problem, because with -U the code can't
know where to re-insert the braces. Trying to fix this by using
matching compadds to add the matches revealed that the code also has
problems when the braces are in the path-prefix/suffix under certain
circumstances.


Ok, in the light of these two and the problem that we still can't
complete inside nested braces mentioned by Bart and the multi-quote
problem I keep alluding to I'd say that maybe I should have a look at
all of these together. That'll take a while, though.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx