Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: TRAPINT breaks consecutive menu-complete
- X-seq: zsh-users 30201
- From: Tomasz Pala <gotar@xxxxxxxxxx>
- To: zsh-users@xxxxxxx
- Subject: Re: TRAPINT breaks consecutive menu-complete
- Date: Sat, 8 Feb 2025 12:27:17 +0100
- Archived-at: <https://zsh.org/users/30201>
- In-reply-to: <CAH+w=7YRK=BSHfNSbvgu8dmhg7eCzjScmoAwM-DtqR+_9Lu__A@mail.gmail.com>
- List-id: <zsh-users.zsh.org>
- References: <20250206160947.GB13517@polanet.pl> <CAH+w=7Z9mj+W1smaqEMems5w3WHXoOD7KCQfnsPj9i8MQUaAzA@mail.gmail.com> <20250207065112.GA22123@polanet.pl> <CAH+w=7YRK=BSHfNSbvgu8dmhg7eCzjScmoAwM-DtqR+_9Lu__A@mail.gmail.com>
On Fri, Feb 07, 2025 at 18:55:28 -0800, Bart Schaefer wrote:
> 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
Indeed:
$ echo $?
0
$ echo $? [tab enter]
0
$ echo $? [tab tab ctrl-g enter]
130 -- cannot reproduce after restarting zsh
$ echo $? [tab tab ctrl-c enter]
130
$ function TRAPINT { return 1; }
$ echo $? [tab tab ctrl-g enter]
0
$ echo $? [tab tab ctrl-c enter]
$
Note the last command was not executed at all..!
> 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.
So - TRAPINT must return 1+ to stop completion, and at the same time
return value from TRAPINT influences consecutive action (let it be next
completion, or accept-line...).
This doesn't seem right... shouldn't "TRAPINT { return 1; }" be neutral?
At least after returning to "normal" ZLE mode (I don't know how it's
called - I mean regular typing).
I would expect completion to _handle_ INT (by stopping own execution),
therefore return 0 for "parent" ("normal" mode). After all, since
completion in nested mode and might receive various signals, these
return codes are irrelevant for current buffer editor, aren't they?
Or - how can it be fixed? I can imagine defining custom widget with
always { return 0; } (although I doubt TRY_BLOCK_ERROR will be useful
here...) and rebinding keys to use that, but this seems an overkill...
Anyway - I need TRAPINT to handle ctrl-c in non-completion ("normal"
mode) only. Should I use something other than TRAPINT? Or
unfunction/mask it somewhere in completion?
--
Tomasz Pala <gotar@xxxxxxxxxxxxx>
Messages sorted by:
Reverse Date,
Date,
Thread,
Author