From: Bart Schaefer <schaefer@brasslantern.com>
To: "Thomas Gläßle" <thomas@coldfix.de>
Cc: Daniel Shahaf <d.s@daniel.shahaf.name>, zsh-workers@zsh.org
Subject: Re: Path with spaces in _canonical_paths
Date: Thu, 24 Nov 2022 10:51:45 -0800 [thread overview]
Message-ID: <CAH+w=7bYzwYPG3KvgoOfYvhcpX_UWuyJcN1+CUFStPYSSaETXQ@mail.gmail.com> (raw)
In-Reply-To: <70f4d652-e824-5594-cdc3-de92d6c6c9b2@coldfix.de>
On Wed, Nov 23, 2022 at 3:36 PM Thomas Gläßle <thomas@coldfix.de> wrote:
>
> On 11/23/22 23:42, Bart Schaefer wrote:
> > + # ### The following approximates that.
> > + matches+=(${(q)${(M)files:#$canpref*}/$canpref/$origpref})
>
> Seems to resolve the issue!
Good!
> However, there is another weird behaviour that I just now noticed>
>
> # cmd <Tab>
> ../../../foo/My\ File
> ../../../tmp/My\ File
> When resolving relative paths from within
> a symlinked directory, it seems to assume the resolved path of the cwd
> as basepath.
Yes, there's a loop that walks up the tree if there's a path prefix on
the file being completed. How far up the tree it will look is
controlled by the canonical-paths-back-limit zstyle (default 8
levels). This is being exacerbated by the -N option because without
-N the :P modifier on the input paths would already have resolved the
symlinks.
Independently, I wonder if we should switch from :P to :A in the
not-dash-N case.
prev parent reply other threads:[~2022-11-24 18:52 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-18 17:41 thomas
2022-11-21 3:57 ` Bart Schaefer
2022-11-21 10:47 ` thomas
2022-11-21 16:30 ` Bart Schaefer
2022-11-21 17:41 ` Thomas Gläßle
2022-11-21 21:32 ` Bart Schaefer
2022-11-23 14:13 ` Daniel Shahaf
2022-11-23 21:36 ` Bart Schaefer
2022-11-23 22:24 ` Daniel Shahaf
2022-11-23 22:42 ` Bart Schaefer
2022-11-23 23:06 ` Daniel Shahaf
2022-11-23 23:12 ` Bart Schaefer
2022-11-24 0:12 ` Daniel Shahaf
2022-11-24 18:42 ` Bart Schaefer
2022-11-23 23:36 ` Thomas Gläßle
2022-11-23 23:40 ` Thomas Gläßle
2022-11-24 18:51 ` Bart Schaefer [this message]
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='CAH+w=7bYzwYPG3KvgoOfYvhcpX_UWuyJcN1+CUFStPYSSaETXQ@mail.gmail.com' \
--to=schaefer@brasslantern.com \
--cc=d.s@daniel.shahaf.name \
--cc=thomas@coldfix.de \
--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).