Re: [BUG] Crash when accessing WIDGETSTYLE from SIGINT trap

[Roman Perepelitsa <roman.perepelitsa@gmail.com>]

On Tue, Nov 12, 2019 at 3:56 PM Mikael Magnusson <mikachu@gmail.com> wrote:
> Have you tried restoring the long prompt in zle-line-init instead?

No, I haven't. zle-line-init is a bit too late. Prompt is already
expanded and printed out at that point. I could still change PROMPT
there and call `zle reset-prompt` but it would be slower than changing
PROMPT in precmd. As I mentioned, I've found a workaround for the bug
that causes the first element of precmd_functions to get skipped over
after Ctrl-C, so the part of my code that restores long prompt works
correctly in all cases where I've tried it.

The unresolved problem is that my code calls set-short-prompt in some
cases when it shouldn't after Ctrl-C. zle can effectively be in two
states and I don't know how to distinguish between the two when my
SIGINT trap triggers.

Normal state: Keyboard input goes into BUFFER. When Ctrl-C is pressed
in this state, new prompt is created. When my SIGINT trap triggers, I
want to shorten prompt.

    Before Ctrl-C:
        /tmp% echo hello█

    After Ctrl-C:
        /tmp% echo hello
        /tmp% █

Modal state: Keyboard input goes into some place other than BUFFER.
When Ctrl-C is pressed, zle state changes to normal but a new prompt
is not created. When my SIGINT trap triggers, I want to do nothing.
(This is where my current code works incorrectly because it always
shortens prompt on SIGINT.)

    Before Ctrl-C:
        /tmp% grep -
        zsh: do you wish to see all 180 possibilities (45 lines)? █

    After Ctrl-C:
        /tmp% grep -█

    Before Ctrl-C:
        /tmp% echo hello
        bck-i-search: hell█

    After Ctrl-C:
        /tmp% █

How can I distinguish between these states? How can I figure out from
within a SIGINT trap whether zle will or won't create new prompt after
my trap function returns?

Roman.