Re: Completion in braces limitation

[Oliver Kiddle <opk@xxxxxxxxxxxxxxx>]

Sven Wischnowsky wrote:

> This was intentional, the completion gave up as soon as it found the `$'.
> The patch below makes it try a little harder by looking at what comes

> I would be thankful if someone (you?) could test this more thoroughly,
> though.

Brilliant. That seems to work well. I've tested it quite thoroughly but
will do some more testing of it later (when I'm not at work).
 
> Well, the new style completion can do this, of course...

I really ought to find some time to try this new completion.

One thing which I did notice while testing a few things out with
completion in braces is that it doesn't work quite as I'd like with
things of the form $(...).
Try:
zsh -f
sw() { echo /home/native_rs6000 }
cd $(sw)/{<tab>

This expands $(sw) and quotes the brace. There may be a reason for doing
this but I can't think of one.

Also (not using a brace), typing a bit more before the tab:
cd $(sw)/tes<tab>
will expand $(sw), leave '/tes' on the end and add a space. What would
be nice is if it had completed to the 'test' directory which I have
there. Back quotes behave in the same way.

Another way that $(...) is treated differently to a variable regards
when zsh expands it:
cd $PWD<tab> - expands the value of $PWD
cd $PWD/<tab> - does not expand $PWD. I find this useful.
cd $(sw)/<tab> - this will expand $(sw).

Finally, I noticed this behaviour:

bindkey "^G" list-expand
cd $PWD/<tab><^G><tab>
This lists directories in $PWD after the first tab. I then listed the
value of PWD with Ctrl-G, then wanting to go back to the list of
directories, I pressed tab again. This started menu completion instead
of returning to the list. I suppose I should remember to use Ctrl-D
instead of tab again but if it's a simple change, it might be useful if
things which overwrite the list (such as list-expand) revert things as
if the original tab had not been pressed.

Thanks

Oliver Kiddle