zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: Daniel Shahaf <d.s@daniel.shahaf.name>,
	Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: Bug in completion with curly braces?
Date: Sat, 21 Nov 2020 14:32:59 -0800	[thread overview]
Message-ID: <CAH+w=7ZcJ67eq1cKuSDtb_XxOmcyuk2Esw1ebVSgGhXSAx1V9g@mail.gmail.com> (raw)
In-Reply-To: <CAMP44s1B8sv5Xe-Mvm8peiJ7H4e2oMgTPd8Si4QxcLD5PyaPnQ@mail.gmail.com>

On Sat, Nov 21, 2020 at 1:09 PM Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> On Sat, Nov 21, 2020 at 9:29 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> > Consequently, brace expansion is presumably attempted for the same
> > reason it s attempted when the words don't contain braces.
>
> But zle knows { is part of the completions

Actually, it does not.  Every TAB starts over from scratch with
figuring out how to divide the command line into complete-able
"words".  It doesn't know what is going to be supplied to compadd as
the set of matches until much later.

Consequently the line is split before the unquoted "{" on the
assumption that a brace expansion is going to follow it.

It might be easier to understand/debug this by observing the effect of
the following example:

_foo() { compadd -Q 'stash@{0}' 'stash@{1}'; compstate[list]=keep }
compdef _foo foo

Looking at that with _complete_debug, the prefix is being set to
"stash@" rather than to "stash@{", and you get repeated TABs cycling
through "stash@{{0}" and "stash@{{1}".  It's waiting for you to close
the presumed brace expansion yourself.

This is similar to the situation in Daniel's thread where "{" in
command position is assumed to be the start of a "{ subcommand }".
There's only so much completion can do to guess what a heavily
overloaded token means.

This appears to work around it:

_foo() {
  local -a stashes=( 'stash@{0}' 'stash@{1}')
  if [[ $words[CURRENT] = *@\{ ]];
  then compadd -Q -p ${words[CURRENT]%\{} ${stashes#$words[CURRENT]}
  else compadd -Q $stashes
  fi
}

However, that gets confused if $stashes contains e.g. 'stash@{10}' and
you're trying to complete after the digit "1", so there's more
refinement required.  Any time there's an unquoted "{" on the line
you're eventually going to run into something that wants to treat it
as a brace expansion.

I even tried forcing "ignorebraces" to be on during completion, but
the best that does (in combo with other changes to the compadd) is to
convert the word on the line to be "stash@\{" which you don't want.

I've got one other idea about this but I'll send this email and think
more about the other option.


  reply	other threads:[~2020-11-21 22:33 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 [this message]
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
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='CAH+w=7ZcJ67eq1cKuSDtb_XxOmcyuk2Esw1ebVSgGhXSAx1V9g@mail.gmail.com' \
    --to=schaefer@brasslantern.com \
    --cc=d.s@daniel.shahaf.name \
    --cc=felipe.contreras@gmail.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).