On Mon, Nov 29, 2021 at 2:38 AM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> To clarify this point (in part for Oliver), the question is not what
> happens when the signal handler is a zsh function and that function
> expands prompts.  The problem occurs when a default (C-implementation)
> signal handler causes ZLE to redraw the prompt as a side-effect.  "...
> when prompt is expanded in a signal handler" confused me for a while
> the first time I read through this.

Thank you.

What makes WINCH and CHLD special is that the default signal handler
for them cannot be overridden. User traps for these signals run after
the default handlers not instead of them.

> I'm not understanding the distinction ... you can control prompt_subst
> in your config as well.  I'm just pointing out another case where a
> user might want a particular global config that is messed with by
> "emulate -R".

The case you are bringing up can be fixed by adding "-L" to "emulate",
right? A function that unintentionally resets all global options will
cause other issues apart from breaking prompt.

Aside from signals, prompt expansion happens either with global
options or with options that are active during "zle reset-prompt". If
I have control over my rc files, I have control over these options by
following these rules:

1. Set the desired global options in zshrc.
2. All functions that change options must set local_options.
3. Functions that invoke reset-prompt widget (either directly or
indirectly) must not change options even with local_options.

The nice thing about these rules is that they are already being
followed by all decent plugins and all zsh code bundled with zsh
itself. If I wanted to ensure correct prompt expansion on WINCH and
CHLD, the rules would be stricter:

1. Set the desired global options in zshrc.
2. Functions must not change options, not even with local_options.

Now most plugins and most bundled zsh code are ruled out.

> For SIGCHLD in particular you could try "setopt nonotify" in your zle
> widgets.

This has a surprising effect of suppressing the job notification
altogether. Here's how it goes:

1. CHLD arrives when my zle widget is running with local_options and
no_notify. Notification is not printed.
2. I press ENTER. Notification is not printed because now notify is set.
3. If I run "jobs", notification finally gets printed and the job is
removed from the job table.

> I haven't followed the logic through very thoroughly, but what if
> instead of delaying the signal handling, we delayed reprinting the
> prompt?  Is there a reason an in-progress widget would want the prompt
> redisplayed without an explicit call to reset-prompt?

I like this idea. I'm attaching a patch that implements it. Also
available here:
https://github.com/romkatv/zsh/commit/cdcb141c880799847f2b068fef5d097736d484d6

WDYT?

Roman.