Re: squeeze-slashes false not working?

[Mikael Magnusson <mikachu@gmail.com>]

On 13 May 2011 20:53, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> On Fri, 13 May 2011 20:23:15 +0200
> Mikael Magnusson <mikachu@gmail.com> wrote:
>> On 13 May 2011 20:17, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
>> > On Thu, 12 May 2011 19:18:26 +0200
>> > Mikael Magnusson <mikachu@gmail.com> wrote:
>> >> Another old mail:
>> >> """
>> >> estragib noted on irc that
>> >> 21:28:58 <estragib> completing ~/d/p/t/i.<TAB> works for
>> >> ~/dev/prj/test/index.html, as does ~/d/*/*/ind<TAB>. i vaguely remember
>> >> seeing a setting somewhere that will allow ~/d///ind<TAB> but can't find
>> >> it again. help? :)
>> >>
>> >> and it seems that setting squeeze-slashes to true or false has no
>> >> effect, the slashes are always squeezed. But it works in zsh -f.
>> >> """
>> >>
>> >> But now I can't reproduce it working in zsh -f. At best it jumps back
>> >> to the first doubleslash and completes at that point. Maybe another
>> >> option is interfering, any idea which one if so?
>> >
>> > That's the standard feature that it tries to expand path segments before
>> > the first.  It can be turned off by setting the style path-completion to
>> > false, although what setting it to false does is to allow _path_files to
>> > skip a prefix of the file that already exists, and I'm not sure what
>> > happens if there are multiple slashes there.
>>
>> Hm, with that set, zsh -f starts acting like with my .zshrc, ie as if
>> I only had one slash. Does ls /////<tab> just show stuff in / for you
>> too? The documentation for squeeze-slashes says it should act like I
>> typed ls /*/*/*/*/<tab>.
>
> Er, that sounds like it means it works with path-files *on*, and I don't
> know how that's supposed to be implemented.  It also looks I don't know
> what's supposed to be happening in any given case, either, or quite what
> is or isn't working.

Okay, I'll try to sum up :). Starting from zsh -f + compinit, with
path-files on and squeeze-slashes off (the default), I get this
behaviour: ls ////<tab> jumps back to the first slash and allows me to
complete components in /.

With the same and path-files off, it simply behaves as if I had ls
/<tab>, ie it completes components in / after the four slashes.

squeeze-slashes on and path-completion on behaves as the second case.
squeeze-slashes on and path-completion off behaves the same way.

When I type ls /*/*/<tab>, all paths matching that glob are inserted
on the command line, this does not equal any of the above results. In
my zshrc setup it cycles through the matches of the first segment and
leaves the second /*/ alone. Ideally I would like to cycle through the
matches of the whole glob, not just the first segment, but that's a
separate problem I think.

Hm. If I start from zsh -f and compinit and then setopt globcomplete,
it behaves closer to how I want. I get a completion menu that lists
things in both /bin and /tmp starting with 'a' when I do ls //a<tab>.
It still jumps back to the first slash and stops working when I unset
path-completion though. Completing ls /*/a<tab> only works with
path-completion on when globcomplete is on, but behaves the same way
with globcomplete off regardless of the setting of path-completion. In
all cases so far with /*/a it only completes to /tmp/a which is an
exact match, not /bin/attr for example which would be a partial match,
so I think that's actually expansion, not completion?

With globcomplete on and path-completion on, completing /*/a* goes
back to listing only the first segment in the menu, and no obvious way
to accept and start completing the second segment, any cursor movement
does the trick but...

In almost none of the above have I seen any evidence that with
squeeze-slashes on, is any repeated slashes treated as an asterisk
appearing between them though. :) It does sort of come close with
path-completion on, but that seems orthogonal in principle. This is
what the manpage says about squeeze-slashes, "by default the file
completion function behaves as if there were a `*' between the
slashes."

-- 
Mikael Magnusson