Re: Bug in completion with curly braces?

[Felipe Contreras <felipe.contreras@xxxxxxxxx>]

On Sun, Nov 22, 2020 at 2:36 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>
> On Sat, Nov 21, 2020 at 6:58 PM Felipe Contreras
> <felipe.contreras@xxxxxxxxx> wrote:
> >
> > So the options are:
> >
> > 1. Fail the completion
> > 2. Complete something I didn't ask for (but it's close)
> > 3. Complete correctly what I asked for
> >
> > I'm saying if 3 is not feasible, then perhaps 2 would make sense
> > rather than 1. It's at least something.
>
> It's up to your completion function to tell it that #2 is OK, and what
> to offer in that circumstance.  That's one thing e.g. _alternative is
> for.

I'm not using _alternative, I'm using compadd. If compadd doesn't do
what I told it to do, then #1 it is.

> In this specific example, though, any time an unquoted "{" appears on
> the command line at the time completion is invoked, it's being treated
> as the start of a brace expansion and therefore removed from the match
> comparisons so that completion can try to fill in a comma-separated
> list of replacements.
>
> This does appear to be related to a couple of actual bugs, because
> "setopt ignorebraces" is supposed to disable this, but does not do so
> correctly.  Before I get into that, here's a hack to take advantage of
> the brace-completion behavior to get something that works the way I
> think you would like:
>
> _foo() {
>   local stashes=('stash@{0}' 'stash@{1}');
>   if [[ $words[CURRENT] = *\{* ]]
>   then compadd -Q -d stashes ${stashes//\{/}
>   else compadd -Q -a stashes
>   fi
> }

Yeah, this almost works, but I'm not interested in hacks.

My real function is something like this:

__compadd () {
  compadd -Q -p "${2-}" -S "${3- }" ${@[4,-1]} -- ${=1}
}

I'm not going to add dozens of lines of code just for this corner-case
depending on the value of $1. If compadd doesn't work on this case,
then it doesn't work on this case.

> As to the bug ... there are actually a few of them, all inter-related.
>
> 1)  _comp_options includes "NO_ignorebraces" so isset(IGNOREBRACES) is
> never true in zle_tricky.c:get_comp_string
> 2) Even if that's removed from _comp_options (and set in the caller
> context), when the brace is added to $PREFIX it is escaped with a
> backslash, so it no longer matches the string on the line and
> completion fails
> 3) When IGNOREBRACES is set, the $debug_indent string in
> _complete_debug is mis-handled
> 4) Possibly as a consequence of that, invoking _complete_debug from
> outside GDB with ignorebraces causes the shell to exit (no reported
> error, it just exits)
>
> #3 is relatively easy to fix but I won't yet in case someone can track
> down #4 (I've had no luck).

So, in theory if the user has ignorebraces set, there would be no need
to use quotes for the curly braces?

Cheers.

-- 
Felipe Contreras