From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: zsh-workers@zsh.org
Cc: "Thomas Gläßle" <thomas@coldfix.de>
Subject: Re: Path with spaces in _canonical_paths
Date: Wed, 23 Nov 2022 14:13:57 +0000 [thread overview]
Message-ID: <20221123141357.GL27622@tarpaulin.shahaf.local2> (raw)
In-Reply-To: <CAH+w=7a1_O7nBO4jUH2otCnjvcW+tJmzPHqm_Zw+CVJtM_PyJw@mail.gmail.com>
Bart Schaefer wrote on Mon, Nov 21, 2022 at 13:32:41 -0800:
> On Mon, Nov 21, 2022 at 9:41 AM Thomas Gläßle <thomas@coldfix.de> wrote:
> >
> > + local -a tmp_buffer
> > + compadd -A tmp_buffer "$__gopts[@]" -a files
> > [...]
> > + matches+=( "${(@)tmp_buffer/$canpref/$origpref}" )
> > else
> > # ### Ideally, this codepath would do what the 'if' above does,
> > # ### but telling compadd to pretend the "word on the command line"
> > # ### is ${"the word on the command line"/$origpref/$canpref}.
> > - matches+=(${${(M)files:#$canpref*}/$canpref/$origpref})
> > + matches+=(${${(M)tmp_buffer:#$canpref*}/$canpref/$origpref})
> > fi
>
> I'm not confident that's the right fix for other examples, given the
> "Ideally" comment there. Daniel, you were the last editor of that
> section of _canonical_paths but the change appears to have been
> related to its use in _mount (where it is no longer used now).
The change in question is workers/39070 (= zsh-5.2-406-gaa041f7a5).
> Any comment?
Not really.
The log message and thread of that change describe what use-case that
change was fixing: namely, «umount /f/b<TAB>» → «umount /foo/bar».
The comment quoted above concerns how the candidate completions are
compared to the word on the command line. The comment says that,
instead of applying s/foo/bar/ to the word on the command line and
comparing the result against the raw candidate completions, the reverse
is done — s/bar/foo/ is applied to the candidate completions and that's
compared to the raw word on the command line — and implies that that's
not exactly equivalent to the former, and that the former would be
preferred over the latter.
Adding or removing -Q or {(@)} (or ${(b)}, cf. workers/39080) might well
be independent of that issue, though.
HTH.
Daniel
P.S. Feel free to Cc me directly when there's a question to me
specifically.
next prev parent reply other threads:[~2022-11-23 14:14 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 [this message]
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
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=20221123141357.GL27622@tarpaulin.shahaf.local2 \
--to=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).