Re: TRAPINT breaks consecutive menu-complete

On Thu, Feb 6, 2025 at 10:51 PM Tomasz Pala <[email protected]> wrote:
>
> That's clear - but what is above "top" level keybinding?
> Because that's where TRAPINT directs:
>
> $ ls [tab, tab -- starts menu completion] [ctrl-c]
>      [tab, tab - nothing happens, 3rd tab required]

Hmm, this is a little different for me -- I get
  [ctrl-c][tab - beeps][tab - menu appears][tab - begin cycling]

What's happening there is this bit from the doc:

     ... Otherwise, the shell will behave as
     interrupted except that the return status of the trap is retained.

"The return status is retained" causes the action in progress -- in
this case, menu-selection -- to also return that status.  Thus I get a
failed widget for the first tab and then two more are required to get
back into menu.  This behavior is unique to menu-selection mode
because entering selection instantiates a new keymap context, which
must be left and re-entered to restart the menu.  With default menu
completion you just get the whole command line killed.

> BTW returning 0 also behaves badly, as it leaves completion on, yet
> clears the menu below, so the completion entries appear after movement

I haven't been able to reproduce this except when I'm twiddling the
LINES value as in your earlier thread, but that doesn't mean there
isn't another way to get there that I haven't stumbled on.  At a
guess, a call to "zle -R" as the last thing in the trap might fix it.