Completion oddities

Completion oddities

[Bart Schaefer]

Maybe I'm just confused.

#1
It appears that setting MENUSELECT globally, overrides the "no-select"
string in the "menu" zstyle.  I would think it should be the other way
around.

#2
When the "original" style is true for _approximate and _correct, the
REC_EXACT option seems to be ignored.  Is there a way around that?

#3
According to _complete_debug output, this is the context _approximate
is using for looking up a style when called from _correct_word (that
is, as "_main_complete _correct"):
    zstyle -t ":completion:correct-word:correct-1:::" original
Appending the count to the completer is documented for _approximate
but not mentioned in _correct.

#4
The way that the function field of a context is computed is a bit
annoying.  For example, if I call
    zle _correct_word
from _generic, then instead of the widget name in the function slot,
the function is correct-word.  This makes it impossible to specify
styles for the widget separately from styles for using _correct_word
directly. It's done this way by a large number of functions.

Re: Completion oddities

[Bart Schaefer]

On Sun, Dec 10, 2023 at 9:27 AM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> #1
> It appears that setting MENUSELECT globally, overrides the "no-select"
> string in the "menu" zstyle.

It's a problem with mixing no-select and yes=NUM:

  zstyle ':completion:*' menu no-select yes=2

Having yes=2 means arriving at _main_complete line 301 with
compstate[insert]=unambiguous from line 293 so we never take the
branch that would unset MENUSELECT.

> #2
> When the "original" style is true for _approximate and _correct, the
> REC_EXACT option seems to be ignored.  Is there a way around that?

This seems to do it:

  zstyle -e ':completion:*:(approximate|correct)*:*' original \
    'if [[ $compstate[nmatches] -eq 1 && -o recexact ]]; \
     then reply=(false); else reply=(true); fi'

#3 and #4 are sort of rehetorical.

Re: Completion oddities

[Oliver Kiddle]

Bart Schaefer wrote:
> Maybe I'm just confused.
>
> #1
> It appears that setting MENUSELECT globally, overrides the "no-select"
> string in the "menu" zstyle.  I would think it should be the other way
> around.

The menu selection was built to work even with compctl completion.
MENUSELECT is the interface _main_complete uses to control it. So the
way it is doesn't surprise me.

> #2
> When the "original" style is true for _approximate and _correct, the
> REC_EXACT option seems to be ignored.  Is there a way around that?

While you've since posted a solution, I've not managed to construct an
example to demonstrate the difference.

> #3
> According to _complete_debug output, this is the context _approximate
> is using for looking up a style when called from _correct_word (that
> is, as "_main_complete _correct"):
>     zstyle -t ":completion:correct-word:correct-1:::" original
> Appending the count to the completer is documented for _approximate
> but not mentioned in _correct.

The documentation does state under _correct that "It is based on
_approximate" so that can imply that some functionality is shared. That
does continue with "but the completer field in the context name is
correct." So perhaps it should be explicit about the change count also
being in that field.

> #4
> The way that the function field of a context is computed is a bit
> annoying.  For example, if I call
>     zle _correct_word
> from _generic, then instead of the widget name in the function slot,
> the function is correct-word.  This makes it impossible to specify
> styles for the widget separately from styles for using _correct_word
> directly. It's done this way by a large number of functions.
>

How are you calling `zle _correct_word` from _generic? In my testing,
this worked fine:
  zle -C corrupt-word complete-word _generic
  zstyle ':completion:corrupt-word:*' completer _complete_word
  bindkey '^Xz' corrupt-word
  zstyle ':completion:corrupt-word:*' ignored-patterns '*?.h'

Oliver

Re: Completion oddities

[Bart Schaefer]

On Mon, Dec 11, 2023 at 4:28 PM Oliver Kiddle <opk@zsh.org> wrote:
>
> Bart Schaefer wrote:
> > Maybe I'm just confused.
> >
> > #1
> > It appears that setting MENUSELECT globally, overrides the "no-select"
> > string in the "menu" zstyle.
>
> The menu selection was built to work even with compctl completion.
> MENUSELECT is the interface _main_complete uses to control it. So the
> way it is doesn't surprise me.

It's inconsistent, though.  If you use no-select by itself, it kills
MENUSELECT.  And the doc suggests that it should always prevail:

     Menu selection can be turned off explicitly by defining a value
     containing the string 'no-select'.

> > #2
> > When the "original" style is true for _approximate and _correct, the
> > REC_EXACT option seems to be ignored.  Is there a way around that?
>
> While you've since posted a solution, I've not managed to construct an
> example to demonstrate the difference.

I had an example but it's long since scrolled out of my terminal history.

> > #4
> > The way that the function field of a context is computed is a bit
> > annoying.  For example, if I call
> >     zle _correct_word
> > from _generic, then instead of the widget name in the function slot,
> > the function is correct-word.  This makes it impossible to specify
> > styles for the widget separately from styles for using _correct_word
> > directly. It's done this way by a large number of functions.
> >
>
> How are you calling `zle _correct_word` from _generic?

Sorry, I mis-"spoke" there.  I meant "from a generic widget" not
literally "_generic".

The initial widget is not a zle -C widget, it's a zle -N that fiddles
around with $BUFFER, sets up $curcontext, and then runs "zle
_correct_word".

But given this:

if [[ -z "$curcontext" ]]; then
  curcontext="correct-word:::"
else
  curcontext="correct-word:${curcontext#*:}"
fi

I don't see how the function context can ever be anything other than
"correct-word", even if it was started from _generic?  Unless the
style is tested either before _correct_word is called or after it
returns.

Re: Completion oddities

[Bart Schaefer]

On Mon, Dec 11, 2023 at 6:10 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> The initial widget is not a zle -C widget, it's a zle -N that fiddles
> around with $BUFFER, sets up $curcontext, and then runs "zle
> _correct_word".

I know, I'm doing exactly what I ask others not to do and not showing
an actual example.  I don't have a short one yet, the place this
happens is buried in a larger project.  I'll follow up when I can.

Re: Completion oddities

[Bart Schaefer]

On Mon, Dec 11, 2023 at 6:48 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> I know, I'm doing exactly what I ask others not to do and not showing
> an actual example.

OK, stupid minimal example:

dummy_correct() {
  local curcontext=${WIDGET}:::
  zle _correct_word
}
zle -N dummy_correct
bindkey ^Xc dummy_correct

zstyle -e '*' ignored-patterns 'zle -I; print -- ignore: $curcontext;
reply=(\*)'
zstyle -e '*' fake 'zle -I; print -- fake: $curcontext; reply=(\*)'

Hit ^Xc after any word (preferably not in command position or you'll
get a LOT of output) and note what $curcontext is printed.

_correct_word is kind of a silly example because aside from clobbering
$curcontext it's a one-line wrapper for _correct, but consider e.g.
_history_complete_word which does the same thing (incorrectly, I
think, it's missing a colon?) and is over 100 lines.  _expand_alias is
(accidentally?) reasonable because it checks $funcstack before
whacking the context.