Re: Help fix Zsh shell command prompt error or stranee

[Grant Taylor <gtaylor@xxxxxxxxxxxxxxxxxx>]

On 8/22/23 1:26 AM, Roman Perepelitsa wrote:
> I'm intrigued. When is %{...%} necessary?

My use case is a mixture of #2 and / or #3.

> These are the use-cases I know of, and I would venture a guess that 
> they apply to a small minority of users:
>
> 1. To work around bugs in the terminal. For example, if the terminal 
> displays "X" as a wide character, you would need to use "%2{X%}" 
> instead of the plain "X".
>
> 2. To embed special markers at the start and the end of the prompt 
> that are recognized by the terminal.
>
> 3. To use styling that isn't available through %-escapes. For example, 
> italic, or dim.

Maybe it's a 4th category, VT100 / ANSI / XTerm escape sequences that 
aren't supported through %-escapes.

 - Setting the tile
 - Setting the *default* foreground color
 - Setting the *default* background color.

N.B. to see the difference changing the /default/ color makes, try 
setting the color, clearing the screen, and running a colorized ls (or 
some other program that generates colored output).  I'll bet you dollars 
to donuts that the background and / or foreground color is different 
/after/ the /colorized/ output from the program.  --  Frequently, such 
programs use "\e[0m" (where "\e" is the escape character, 0x1B).

Conversely, "\e]10;#RRGGBB\e\\" (where "\\" is the backslash character, 
0x5C) will cause the default foreground color to be changed to the 
RRGGBB value.  Similarly "\e]11;##RRGGBB\e\\" will cause the default 
background color to be changed to the RRGGBB value.  Thus when "\e[0m" 
is used, the system used the RRGGBB value for the foreground and background.

There are many other formatting attributes that can be used:

 - bold
 - dim
 - reverse video
 - underline
 - italic
 - blinking
 - double-height
 - double-width

Some terminals support causing it to change the font size.
Some terminals support causing it to change the font used.
Some terminals support causing it to resize the window.
Some terminals support causing it to send data to the printer.
Some terminals support clearing the (off screen) scroll back buffer.
Some terminals support clearing the (on screen) scroll back buffer 
(similar to clearing the screen).
Some terminals support soft fonts.
Some terminals support graphics; XTerm supports SIXEL and ReGIS.

Almost all of these things require multiple (single width) bytes as 
control sequences.

There is no reason that these can't be used in part of the prompt.

Using the %{...%} means that ZLE (?) won't count the multiple (single 
width) bytes output to do fancy things with the terminal.

> Are there any other use cases for %{...%}?

I think so.

> Note that it's not necessary (and not a good idea anyway) to embed 
> special terminal commands into prompt. Things like setting the terminal 
> title, notifying the terminal about the current working directory, 
> etc. These are better done by writing to the TTY in the corresponding 
> hooks (precmd, chpwd, etc.).

Please elaborate as to why these things, which are fixed strings of 
text, shouldn't be embedded in the PROMPT / PS1 et al.

I completely get doing dynamic things that need to be computed in 
precmd.  But I don't yet see a reason why a static string can't be 
embedded in the prompt (PROMPT / PS1) directly.

I use preexec() to change the window title to show information on the 
command that is being run.

The PROMPT / PS1 then re-sets the window title back to a fixed string or 
a string that Zsh alters via other normal %-escapes; %d, %/, or %~. 
E.g. PROMPT / PS1 (et al.) can have something like the following

   "...\e]0;%~\e\a..."

Where:
 "..." is other similar static (from an environment variable content 
point of view) text
 "\a" is the "alert" a.k.a. "bell" character, 0x07.

Why do I need to do processing in the precmd() function when I can 
easily use static variables.

I believe I could make the PROMPT / PS1 variables be read-only in 
~/.zshrc and not need to change them while still having the fully 
dynamic prompt that I currently have.

   local -r PROMPT

> This is different from prompt markers that I mentioned above, which 
> must be embedded into the prompt.

I'm not seeing the "prompt markers" that you're talking about.  Please 
elaborate.

N.B. transient_rprompt is fun.  }:-)



--
Grant. . . .