zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh workers <zsh-workers@zsh.org>
Subject: PATCH Re: squeeze-slashes false not working?
Date: Fri, 13 May 2011 22:58:03 -0700	[thread overview]
Message-ID: <110513225805.ZM13712@torch.brasslantern.com> (raw)
In-Reply-To: <BANLkTi=7vnGkz2uPTyd3Br019SuxV5_Q2Q@mail.gmail.com>

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


-- 


  reply	other threads:[~2011-05-14  5:58 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-12 17:18 Mikael Magnusson
2011-05-13 18:17 ` Peter Stephenson
2011-05-13 18:23   ` Mikael Magnusson
2011-05-13 18:53     ` Peter Stephenson
2011-05-13 20:07       ` Mikael Magnusson
2011-05-14  5:58         ` Bart Schaefer [this message]
2011-05-14 18:31           ` PATCH " Mikael Magnusson
2011-05-14 18:45             ` Mikael Magnusson
2011-05-15  1:38               ` Bart Schaefer
2011-05-15 10:12                 ` Mikael Magnusson
2011-05-15 18:15                   ` Bart Schaefer
2011-05-15 18:20                     ` Mikael Magnusson
2011-05-15  1:39             ` Bart Schaefer
2011-05-15  9:48               ` Mikael Magnusson
2011-05-15 10:01                 ` Mikael Magnusson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=110513225805.ZM13712@torch.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).