Re: Path with spaces in _canonical_paths

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

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