zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh workers <zsh-workers@zsh.org>
Subject: Re: PATCH Re: squeeze-slashes false not working?
Date: Sat, 14 May 2011 18:38:50 -0700	[thread overview]
Message-ID: <110514183850.ZM15129@torch.brasslantern.com> (raw)
In-Reply-To: <BANLkTinSk_0LC34u5+6d2eLVdehf04LpmA@mail.gmail.com>

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.


  reply	other threads:[~2011-05-15  1:39 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         ` PATCH " Bart Schaefer
2011-05-14 18:31           ` Mikael Magnusson
2011-05-14 18:45             ` Mikael Magnusson
2011-05-15  1:38               ` Bart Schaefer [this message]
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=110514183850.ZM15129@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).