zsh-workers
 help / color / mirror / code / Atom feed
From: Roman Perepelitsa <roman.perepelitsa@gmail.com>
To: Oliver Kiddle <opk@zsh.org>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: Prompt expansion on signals
Date: Sun, 28 Nov 2021 22:36:18 +0100	[thread overview]
Message-ID: <CAN=4vMr7J=Tieo1UxotKvT1HyMVFTmAbxYquSMGre6-h2RtcOA@mail.gmail.com> (raw)
In-Reply-To: <54317-1638133855.690561@cAWR.fGbz.m1n1>

On Sun, Nov 28, 2021 at 10:10 PM Oliver Kiddle <opk@zsh.org> wrote:
>
> Roman Perepelitsa wrote:
> > I sometimes change prompt_* options in functions when I want to use `print -P`.
> >
> >     emulate -L zsh -o prompt_percent no_prompt_subst
> >     print -Pru2 -- '%F{1}error%f: missing required parameter: %F{3}--foo%f'
>
> In some cases, you might be better off using the ${(%)var} prompt
> expansion.

I do this in a few places. I'll probably need to replace all `print
-P` calls with ${(%)} expansions.

As a last resort I'm also considering removing all `emulate -L zsh`
calls from all my code and not using any functions from third-parties
or shipped with zsh, however awful that sounds.

> It isn't necessarily just hooks and signal handlers that are affected.

What do you mean by hooks? The only two places where I don't know how
to control options is prompt expansion on SIGWINCH and SIGCHLD. Are
there more?

> Someone might want to use emulate in a zle widget directly. If this is a
> plugin, and the author uses default prompt options, it mightn't be clear
> to them that this could break for other users.

What do you mean? Is it the same problem or a different one?

Maybe we are talking about different things. Let's assume I'm in
control of all my rc files and their complete transitive closure. I'm
writing all widgets by hand. Every line of zsh code that executes in
my shell is written by me. Given this assumption, I would like to
avoid prompt expansion with wrong options. Right now the only way I
know how to achieve this is to either give up perf-function options
(via local_options + whatever options I want in the function) or to
avoid triggering SIGWINCH and SIGCHLD (which implies never resizing my
terminal and not using background jobs).

> There are some cases in completion too where it'd be useful to restore
> the user's option settings for a particular command. Perhaps we could
> have an argument to emulate - user or global perhaps - for restoring the
> original options.

Would this help in avoiding prompt expansion with incorrect options?

> Making options sticky when PS1, PS2 etc are set might break someone's
> setup where they set their prompt before their options.

Good point.

Making options sticky also wouldn't avoid the issue where prompt is
expanded with incorrect special parameters (LC_ALL, etc.). Overriding
special parameters as locals in functions is convenient. It's a shame
that it has the side effect of introducing a race that breaks prompt.

Is there a downside to postponing the handling of SIGCHLD and SIGWINCH
until all functions return? Postponing SIGWINCH seems safe but
postponing SIGCHLD might blow up the job table. Is this a serious
concern?

Roman.


  reply	other threads:[~2021-11-28 21:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-28  9:59 Roman Perepelitsa
2021-11-28 19:50 ` Bart Schaefer
2021-11-28 20:31   ` Roman Perepelitsa
2021-11-28 21:10     ` Oliver Kiddle
2021-11-28 21:36       ` Roman Perepelitsa [this message]
2021-11-29  1:38     ` Bart Schaefer
2021-11-29 11:36       ` Roman Perepelitsa
2021-11-29 17:42         ` Roman Perepelitsa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAN=4vMr7J=Tieo1UxotKvT1HyMVFTmAbxYquSMGre6-h2RtcOA@mail.gmail.com' \
    --to=roman.perepelitsa@gmail.com \
    --cc=opk@zsh.org \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).