Re: Prompt expansion on signals

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sun, Nov 28, 2021 at 12:32 PM Roman Perepelitsa
<roman.perepelitsa@xxxxxxxxx> wrote:
>
> On Sun, Nov 28, 2021 at 8:50 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> >
> > On Sun, Nov 28, 2021 at 2:01 AM Roman Perepelitsa
> > <roman.perepelitsa@xxxxxxxxx> wrote:
> > >
> > > For this to work correctly, prompt_subst must be set when prompt is
> > > expanded. However, this requirement can be violated when prompt is
> > > expanded in a signal handler.

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.

> > A more egregious example might be when the global settings have
> > "unsetopt promptpercent".
>
> I can control these in my config.

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".

> I cannot control options that are
> active when zsh processes SIGCHLD though (unless I never change
> options in zle widgets).

For SIGCHLD in particular you could try "setopt nonotify" in your zle
widgets.  That doesn't help with SIGWINCH, but it might give us an
idea of whether there's a problem with delaying those signals.

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?

> > Are prompts the only case where this is an issue, though?  The most
> > visible, certainly, but "zle -F" for example?
>
> As far as I'm aware, prompt expansion on signals is the only place
> where it's impossible to set options. Perhaps I'm misunderstanding
> what you mean by "zle -F" in this context?

Sorry, I got the question sort of inside-out (see above about "in a
signal handler" confusion).  The relevant bit is that, like a zle
widget, a zle -F handler might have changed local options and then be
hit with SIGWINCH.

> > What about the reverse situation, where the signal handler is a
> > function that changes options locally?
>
> What do you mean?

Ignore that, more confusion.