zsh-workers
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <opk@zsh.org>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>,
	Daniel Shahaf <d.s@daniel.shahaf.name>,
	Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: Bug in completion with curly braces?
Date: Wed, 25 Nov 2020 00:21:55 +0100	[thread overview]
Message-ID: <23476-1606260115.748247@tHME.aGU-.iDnX> (raw)
In-Reply-To: <CAH+w=7bAL3XO0HW59EDsM2rzTrEbyevWNuGoBUEwt7N9B4-WyA@mail.gmail.com>

Bart Schaefer wrote:
> Consequently if the calling function does not apply quoting, -Q is
> only going to work well in cases where the matches either have no
> common prefixes, or the common prefixes do not contain any of the
> special characters, or menu completion is going to be forced (so the
> user selects an entire match all at once rather than exit/re-enter
> completion with the prefix).
>
> (I would be happy to have someone (Oliver?) argue the untruth of that
> last statement.)

I think it is essentially true except that your list of three special
cases can perhaps be expanded. To say it doesn't "work well" perhaps
misrepresents that it does do something well-defined, just not
especially useful when misused.

If you search for compadd.*-Q in completion functions, the cases are not
normal. It is often combined with -U which disables matching altogether.
You'll see cases where $PREFIX was used in building the actual values
passed to compadd. Cases where compquote has been used first. And where
QIPREFIX is checked. And anything that looks normal is probably wrong,
e.g. in _gdb.

I've been assuming that in Felipe's case, he is forced to use -Q because
that is what bashcompinit does. bashcompinit uses it because of a patch
he submitted in 30136 to make it do so. At the time, I wasn't motivated
to review it but can remember being somewhat skeptical. Looking in more
detail now, it is correct in essence but it doesn't surprise me that it
should also cause some unexpected issues.

Looking at the bash example in 30136, it would appear that quoting
is left up to the completion function. Is that always true for bash
completions? Matches are added with an unquoted trailing space but also
some quoted spaces. To get it to pass through compgen, it seems two
levels of quoting and removing space from IFS was necessary. Is this
idiom common?

We could do something like the following in bashcompinit to special case
only space suffixes:

-      compadd -Q "${suf[@]}" -a matches && ret=0
+      compadd "${suf[@]}" - "${(@)${(Q@)matches}:#*\ }" && ret=0
+      compadd -S ' ' - ${${(M)${(Q)matches}:#*\ }% } && ret=0

For the more general case, we'd need to identify characters
with one-level of quoting. Or do a limited number of special cases cover
real-world usage?

Ultimately there's always going to be a mismatch between what needs
quoting in bash and in zsh. Note that in bash no quoting is needed for
git stashes:

bash$ echo stash{1}
stash{1}

So a bash completion for git didn't need to add quotes - hence this
whole discussion. Perhaps we could add an option to allow that. Stuff
like @\{1\}.. is also common in git.

If completion that comes with git is really a lot faster, I think you'd
be better served by finding out why and adding styles to zsh's
completion to allow it to take a faster, more rudimentary approach in
certain cases. It may even already be possible by disabling the right
tags.

Oliver


  reply	other threads:[~2020-11-24 23:22 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-20  1:50 Felipe Contreras
2020-11-20  2:52 ` Mikael Magnusson
2020-11-21 15:28 ` Daniel Shahaf
2020-11-21 21:08   ` Felipe Contreras
2020-11-21 22:32     ` Bart Schaefer
2020-11-22  0:37       ` Felipe Contreras
2020-11-22  2:28         ` Bart Schaefer
2020-11-22  2:58           ` Felipe Contreras
2020-11-22 20:35             ` Bart Schaefer
2020-11-22 21:20               ` Bart Schaefer
2020-11-23  3:03               ` Daniel Shahaf
2020-11-23  7:15                 ` Bart Schaefer
2020-11-23  6:46               ` Felipe Contreras
2020-11-23  7:17                 ` Bart Schaefer
2021-04-18 21:43                   ` Bart Schaefer
2020-11-23 17:31                 ` Bart Schaefer
2020-11-24 23:21                   ` Oliver Kiddle [this message]
2020-11-25  5:06                     ` Felipe Contreras
2021-12-02 19:45                       ` PATCH: bashcompinit quoting (was Re: Bug in completion with curly braces?) Oliver Kiddle

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=23476-1606260115.748247@tHME.aGU-.iDnX \
    --to=opk@zsh.org \
    --cc=d.s@daniel.shahaf.name \
    --cc=felipe.contreras@gmail.com \
    --cc=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).