squeeze-slashes false not working?

squeeze-slashes false not working?

[Mikael Magnusson]

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?

-- 
Mikael Magnusson

Re: squeeze-slashes false not working?

[Peter Stephenson]

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.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: squeeze-slashes false not working?

[Mikael Magnusson]

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>.

-- 
Mikael Magnusson

Re: squeeze-slashes false not working?

[Peter Stephenson]

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.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: squeeze-slashes false not working?

[Mikael Magnusson]

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

PATCH Re: squeeze-slashes false not working?

[Bart Schaefer]

On May 13, 10:07pm, Mikael Magnusson wrote:
}
} 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 /.

Yep, I get that too.  But once something is completed (e.g. /home///),
subsequent completions treat the trailing "///" as if it were a
single slash.  This certainly contradicts the assertion in the doc
for squeeze-slashes that by default it behaves as if /*/*/.
 
} 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.

You mean path-completion off, but yes.  In this case it *should* be
happening this way because 

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

These are as expected.  Once it has skipped the slashes there's nothing
for path-completion to act upon.

} 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.

Red herring.  Tab is expand-or-complete and as soon as you explicitly
put in glob characters you're invoking the "expand" instead of the
"complete".

} 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. :)

When the doc for squeeze-slashes says "as if there were a star
between" it is referring to the internal behavior of the match
generation, not to what would have happened if the command line
contained "/*/" before you started completing.

It's a shorter way of saying "as if there were some part of a path
component name between every pair of adjacent slashes on the command
line, so that the match function had something to work with, except
in this case the path component is empty so the function falls back
on grabbing everything it possibly can."

Anyway, almost the entire implementation of squeeze-slashes is:

# Check if we have to skip over sequences of slashes. The value of $skips
# is used below to match the pathname components we always have to accept
# immediately.

if zstyle -t ":completion:${curcontext}:paths" squeeze-slashes; then
  skips='((.|..|)/)##'
else
  skips='((.|..)/)##'
fi

This is followed by using skips here:

  tmp2="${(M)tpre##${~skips}}"
  tpre="${tpre#$tmp2}"

And indeed for "ls ////" with squeeze-slashes off that is

+_path_files:410> tmp2='' 
+_path_files:411> tpre=/// 
+_path_files:413> tmp1=( / ) 

Whereas with squeeze-slashes on it is

+_path_files:410> tmp2=/// 
+_path_files:411> tpre='' 
+_path_files:413> tmp1=( //// ) 

However, as soon as there's anything after the first slash, THAT CODE
IS NEVER REACHED for the consecutive slashes.  We get down to here:

    # There are more components, so skip over the next components and make a
    # slash be added.

    tmp1=( ${tmp1//(#b)([][()|*?^#~<>\\=])/\\${match[1]}} )
    tmp2="${(M)tpre##((.|..|)/)##}"
    if [[ -n "$tmp2" ]]; then
      skipped="/$tmp2"
      tpre="${tpre#$tmp2}"
    else
      skipped=/
    fi

Looks like we need a reference to $skips at that assignment to tmp2
on line 577.

+_path_files:576> tmp1=( /home ) 
+_path_files:577> tmp2=// 
+_path_files:578> [[ -n // ]]
+_path_files:579> skipped=/// 
+_path_files:580> tpre='' 

So try this; but there may be other places where similar things have
been missed as this function evolved ...

Index: Completion/Unix/Type/_path_files
===================================================================
RCS file: /extra/cvsroot/zsh/zsh-4.0/Completion/Unix/Type/_path_files,v
retrieving revision 1.23
diff -u -r1.23 _path_files
--- Completion/Unix/Type/_path_files    6 May 2011 15:29:05 -0000       1.23
+++ Completion/Unix/Type/_path_files    14 May 2011 05:53:20 -0000
@@ -574,7 +574,7 @@
     # slash be added.
 
     tmp1=( ${tmp1//(#b)([][()|*?^#~<>\\=])/\\${match[1]}} )
-    tmp2="${(M)tpre##((.|..|)/)##}"
+    tmp2="${(M)tpre##${~skips}}"
     if [[ -n "$tmp2" ]]; then
       skipped="/$tmp2"
       tpre="${tpre#$tmp2}"


-- 

Re: PATCH Re: squeeze-slashes false not working?

[Mikael Magnusson]

On 14 May 2011 07:58, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On May 13, 10:07pm, Mikael Magnusson wrote:
> }
> } 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 /.
>
> Yep, I get that too.  But once something is completed (e.g. /home///),
> subsequent completions treat the trailing "///" as if it were a
> single slash.  This certainly contradicts the assertion in the doc
> for squeeze-slashes that by default it behaves as if /*/*/.
>
> } 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.
>
> You mean path-completion off, but yes.  In this case it *should* be
> happening this way because

So maybe the squeeze-slashes entry should mention something to the
effect that disabling it will only allow other options to do stuff,
but maybe nothing will. But in a less stupid way.

> } squeeze-slashes on and path-completion on behaves as the second case.
> } squeeze-slashes on and path-completion off behaves the same way.
>
> These are as expected.  Once it has skipped the slashes there's nothing
> for path-completion to act upon.

Right, just wanted to be complete. :)

> } 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.
>
> Red herring.  Tab is expand-or-complete and as soon as you explicitly
> put in glob characters you're invoking the "expand" instead of the
> "complete".

I retried this with bindkey '^I' complete-word; setopt globcomplete.
With or without your patch, ls /*/*/cit completes to
/home/mikachu/citat and /home/mikachu/citat-private and lets me cycle
between them. Without your patch, ls ///cit completes to /tmp/citat
and /tmp/citat.private. With your patch, ls ///cit acts as /*/*/cit
did, which makes me happy. All of this of course with squeeze-slashes
off and path-completion on.

[snip explainy bits as i have nothing helpful to add]

> So try this; but there may be other places where similar things have
> been missed as this function evolved ...
>
> Index: Completion/Unix/Type/_path_files
> ===================================================================
> RCS file: /extra/cvsroot/zsh/zsh-4.0/Completion/Unix/Type/_path_files,v
> retrieving revision 1.23
> diff -u -r1.23 _path_files
> --- Completion/Unix/Type/_path_files    6 May 2011 15:29:05 -0000       1.23
> +++ Completion/Unix/Type/_path_files    14 May 2011 05:53:20 -0000
> @@ -574,7 +574,7 @@
>     # slash be added.
>
>     tmp1=( ${tmp1//(#b)([][()|*?^#~<>\\=])/\\${match[1]}} )
> -    tmp2="${(M)tpre##((.|..|)/)##}"
> +    tmp2="${(M)tpre##${~skips}}"
>     if [[ -n "$tmp2" ]]; then
>       skipped="/$tmp2"
>       tpre="${tpre#$tmp2}"

This seems to work great in my zsh -f. My next project is working out
why none of this helps with my zshrc loaded :). Thanks.

-- 
Mikael Magnusson

Re: PATCH Re: squeeze-slashes false not working?

[Mikael Magnusson]

On 14 May 2011 20:31, Mikael Magnusson <mikachu@gmail.com> wrote:
> This seems to work great in my zsh -f. My next project is working out
> why none of this helps with my zshrc loaded :). Thanks.

Okay, lucky for me it was the third zstyle from the top,
zstyle ':completion:*' accept-exact-dirs 'yes'

I do still want this set, but maybe it can be made not to consider the
empty string an exact dir?
This seems to do it, but I've no idea if it's sane. Sane is a strange
word to use in _path_files though.

--- a/Completion/Unix/Type/_path_files
+++ b/Completion/Unix/Type/_path_files
@@ -361,7 +361,8 @@ for prepath in "$prepaths[@]"; do
   skipped=
   cpre=

-  if [[ ( -n $accept_exact_dirs || -z $path_completion ) && \
+  if [[ ( ( -n $accept_exact_dirs && ${pre} != /* ) || \
+          -z $path_completion ) && \
         ${pre} = (#b)(*)/([^/]#) ]]; then
     # We've been told either that we can accept an exact directory prefix
     # immediately, or that path expansion is inhibited.  Try the longest

-- 
Mikael Magnusson

Re: PATCH Re: squeeze-slashes false not working?

[Bart Schaefer]

On May 14,  8:45pm, Mikael Magnusson wrote:
} Subject: Re: PATCH Re: squeeze-slashes false not working?
}
} Okay, lucky for me it was the third zstyle from the top,
} zstyle ':completion:*' accept-exact-dirs 'yes'
} 
} I do still want this set, but maybe it can be made not to consider the
} empty string an exact dir?
} This seems to do it, but I've no idea if it's sane. Sane is a strange
} word to use in _path_files though.

This change doesn't fix it for me.  If I apply your patch and then set
accept-exact-dirs yes, then //// completes things in the root between
the first and second slashes, but I'm back to /home/// being treated
as /home/.  There must be something else going on.

As an additional observation, even without your patch if I do this:

% mkdir /tmp/ff /tmp/ffzz
% ls //ff/<TAB>

I get silent failure.  It completes /tmp if either I leave off the
trailing slash, or if there is at least one file in one of the
directories.  I can't tell if this is the expected behavior or not.

I suspect that we're also going to run into madness with filesystems
where "//" designates a network root or similar.

Incidentally with the squeeze-slashes false + path-completion true
default behavior repaired, something like this:

% ls //////////<TAB>

Goes off on a merry lark finding all nine-element paths reachable from
the root and checking to see if they contain at least one file.  This
may go wandering happily through networked filesystems and other roads
less traveled by, leaving the shell preoccupied and unresponsive for
long stretches.

We might want to consider changing squeeze-slashes to default to true,
given that the shell has been inadvertently behaving that way for quite
some time now.

Re: PATCH Re: squeeze-slashes false not working?

[Bart Schaefer]

On May 14,  8:31pm, Mikael Magnusson wrote:
}
} On 14 May 2011 07:58, Bart Schaefer <schaefer@brasslantern.com> wrote:
} > On May 13, 10:07pm, Mikael Magnusson wrote:
} > }
} > } 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.
} >
} > You mean path-completion off, but yes.  In this case it *should* be
} > happening this way because

I accidentally left that sentence unfinished:

... because by definition path-completion false means not to try to
do any completing between slashes (whether consecutive slashes or
not) unless the cursor is placed there and complete-in-word is set.
This is independent of the setting of squeeze-slashes.

Given that, does this next thing you said --

} So maybe the squeeze-slashes entry should mention something to the
} effect that disabling it will only allow other options to do stuff,
} but maybe nothing will. But in a less stupid way.

-- still mean anything?


-- 

Re: PATCH Re: squeeze-slashes false not working?

[Mikael Magnusson]

On 15 May 2011 03:39, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On May 14,  8:31pm, Mikael Magnusson wrote:
> }
> } On 14 May 2011 07:58, Bart Schaefer <schaefer@brasslantern.com> wrote:
> } > On May 13, 10:07pm, Mikael Magnusson wrote:
> } > }
> } > } 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.
> } >
> } > You mean path-completion off, but yes.  In this case it *should* be
> } > happening this way because
>
> I accidentally left that sentence unfinished:
>
> ... because by definition path-completion false means not to try to
> do any completing between slashes (whether consecutive slashes or
> not) unless the cursor is placed there and complete-in-word is set.
> This is independent of the setting of squeeze-slashes.
>
> Given that, does this next thing you said --
>
> } So maybe the squeeze-slashes entry should mention something to the
> } effect that disabling it will only allow other options to do stuff,
> } but maybe nothing will. But in a less stupid way.
>
> -- still mean anything?

Yeah, I sort of guessed the part you left out. What I would want is
some sort of hint in the squeeze-slashes description that
path-completion also has to be on, and as it turns out, maybe it
should mention accept-exact-dirs too. Is the squeeze-slashes setting
needed at all though? It seems like changing it or path-completion has
exactly the same effect; does enabling squeeze-slashes change some
behaviour that disabling path-completion does not change?

-- 
Mikael Magnusson

Re: PATCH Re: squeeze-slashes false not working?

[Mikael Magnusson]

On 15 May 2011 11:48, Mikael Magnusson <mikachu@gmail.com> wrote:

> Is the squeeze-slashes setting
> needed at all though? It seems like changing it or path-completion has
> exactly the same effect; does enabling squeeze-slashes change some
> behaviour that disabling path-completion does not change?

Ignore this, I'm not completely awake yet :)

-- 
Mikael Magnusson

Re: PATCH Re: squeeze-slashes false not working?

[Mikael Magnusson]

On 15 May 2011 03:38, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On May 14,  8:45pm, Mikael Magnusson wrote:
> } Subject: Re: PATCH Re: squeeze-slashes false not working?
> }
> } Okay, lucky for me it was the third zstyle from the top,
> } zstyle ':completion:*' accept-exact-dirs 'yes'
> }
> } I do still want this set, but maybe it can be made not to consider the
> } empty string an exact dir?
> } This seems to do it, but I've no idea if it's sane. Sane is a strange
> } word to use in _path_files though.
>
> This change doesn't fix it for me.  If I apply your patch and then set
> accept-exact-dirs yes, then //// completes things in the root between
> the first and second slashes, but I'm back to /home/// being treated
> as /home/.  There must be something else going on.

No idea what then. With /// (//// takes a bit too long), I get all
sorts of stuff completed, dev/disk/by-label/, proc/sys/debug/ etc.

> As an additional observation, even without your patch if I do this:
>
> % mkdir /tmp/ff /tmp/ffzz
> % ls //ff/<TAB>
>
> I get silent failure.  It completes /tmp if either I leave off the
> trailing slash, or if there is at least one file in one of the
> directories.  I can't tell if this is the expected behavior or not.

It acts the same way for me, but ls /tmp/ff/<tab> with no files there also says
---- no match for: `arg', `directories', `file', or `corrections'
so I don't think it's because of squeezing or path-completion. Same
with accept-exact-dirs off. It seems logical that if the final result
isn't accepted when typed explicitly, it isn't produced from a partial
match either.

> I suspect that we're also going to run into madness with filesystems
> where "//" designates a network root or similar.

There's the preserve-prefix style. With it set to //, ls ///<tab> acts
the same as ls //<tab> without it set. So that's something at least.

> Incidentally with the squeeze-slashes false + path-completion true
> default behavior repaired, something like this:
>
> % ls //////////<TAB>
>
> Goes off on a merry lark finding all nine-element paths reachable from
> the root and checking to see if they contain at least one file.  This
> may go wandering happily through networked filesystems and other roads
> less traveled by, leaving the shell preoccupied and unresponsive for
> long stretches.

Yeah, emulating 'locate' extremely badly isn't my primary use-case :).
You can say the same thing for /**/<tab> too. (Though this seems to
behave as a single * in my zshrc, but does hang for a long time from
zsh -f + compinit, another mystery).

> We might want to consider changing squeeze-slashes to default to true,
> given that the shell has been inadvertently behaving that way for quite
> some time now.

-- 
Mikael Magnusson

Re: PATCH Re: squeeze-slashes false not working?

[Bart Schaefer]

On May 15, 12:12pm, Mikael Magnusson wrote:
} Subject: Re: PATCH Re: squeeze-slashes false not working?
}
} On 15 May 2011 03:38, Bart Schaefer <schaefer@brasslantern.com> wrote:
} > This change doesn't fix it for me.  If I apply your patch and then set
} > accept-exact-dirs yes, then //// completes things in the root between
} > the first and second slashes, but I'm back to /home/// being treated
} > as /home/.  There must be something else going on.
} 
} No idea what then. With /// (//// takes a bit too long), I get all
} sorts of stuff completed, dev/disk/by-label/, proc/sys/debug/ etc.

Are you starting from zsh -f and setting ONLY the accept-exact-dirs
zstyle?  Or are you referring to what happens with your full .zshrc?
 
} > As an additional observation, even without your patch if I do this:
} >
} > % mkdir /tmp/ff /tmp/ffzz
} > % ls //ff/<TAB>
} >
} > I get silent failure.  It completes /tmp if either I leave off the
} > trailing slash, or if there is at least one file in one of the
} > directories.  I can't tell if this is the expected behavior or not.
} 
} ---- no match for: `arg', `directories', `file', or `corrections'

Yes, again I'm in zsh -f so I don't have any descriptions set up.  This
is what I suspected was the cause.

What's confusing is that if the slash is auto-appended and therefore
auto-removable, pressing TAB after the trailing slash works the same
as in the case where you start with no trailing slash.

Re: PATCH Re: squeeze-slashes false not working?

[Mikael Magnusson]

On 15 May 2011 20:15, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On May 15, 12:12pm, Mikael Magnusson wrote:
> } Subject: Re: PATCH Re: squeeze-slashes false not working?
> }
> } On 15 May 2011 03:38, Bart Schaefer <schaefer@brasslantern.com> wrote:
> } > This change doesn't fix it for me.  If I apply your patch and then set
> } > accept-exact-dirs yes, then //// completes things in the root between
> } > the first and second slashes, but I'm back to /home/// being treated
> } > as /home/.  There must be something else going on.
> }
> } No idea what then. With /// (//// takes a bit too long), I get all
> } sorts of stuff completed, dev/disk/by-label/, proc/sys/debug/ etc.
>
> Are you starting from zsh -f and setting ONLY the accept-exact-dirs
> zstyle?  Or are you referring to what happens with your full .zshrc?

Oops, that was with my full .zshrc, with zsh -f I get your results.

> } > As an additional observation, even without your patch if I do this:
> } >
> } > % mkdir /tmp/ff /tmp/ffzz
> } > % ls //ff/<TAB>
> } >
> } > I get silent failure.  It completes /tmp if either I leave off the
> } > trailing slash, or if there is at least one file in one of the
> } > directories.  I can't tell if this is the expected behavior or not.
> }
> } ---- no match for: `arg', `directories', `file', or `corrections'
>
> Yes, again I'm in zsh -f so I don't have any descriptions set up.  This
> is what I suspected was the cause.
>
> What's confusing is that if the slash is auto-appended and therefore
> auto-removable, pressing TAB after the trailing slash works the same
> as in the case where you start with no trailing slash.

-- 
Mikael Magnusson