Help fix Zsh shell command prompt error or stranee

Help fix Zsh shell command prompt error or stranee

[Budi]

Why do Zsh shell command prompt err or behave so messy, when user
input the entry with its buffer length is more than the current max
terminal column ?

Re: Help fix Zsh shell command prompt error or stranee

[Grant Taylor]

On 8/18/23 7:35 PM, Budi wrote:
> Why do Zsh shell command prompt err or behave so messy, when user
> input the entry with its buffer length is more than the current max
> terminal column ?

What I usually see is the case with what -- I think -- you are 
describing, it is because there are non-printing control characters in 
the prompt which get counted.  Thus ZLE's count of characters on the 
line doesn't match what is visually on the line.  Doing anything that 
(un)wraps the line at that point is ... at best ... a mess.

Proper use of %{ and %} sequences to keep ZLE from counting the 
non-printing / control characters helps a lot.



Grant. . . .

Re: Help fix Zsh shell command prompt error or stranee

[Bart Schaefer]

On Fri, Aug 18, 2023 at 5:35 PM Budi <budikusasi@gmail.com> wrote:
>
> Why do Zsh shell command prompt err or behave so messy

It'd help if you showed us the value of your $PS1 (or $PROMPT) variable.

Re: Help fix Zsh shell command prompt error or stranee

[Roman Perepelitsa]

On Sun, Aug 20, 2023 at 1:15 AM Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>
> Proper use of %{ and %} sequences to keep ZLE from counting the
> non-printing / control characters helps a lot.

In the vast majority of cases one can replace %{...%} with a
first-class %-sequence. For example, instead of %{\033[31m%} one can
use %F{red}.

Roman.

Re: Help fix Zsh shell command prompt error or stranee

[Budi]

PS1=$(echo -e "$DIRSB\e[41;1;37m%~\e[44;1;33m\n%%\e[m ")


DIRSB variable is none or sort of
$(echo -e "${\e[41;1;37mWORD\e[m\n\r}")

(just in tool https://github.com/abdulbadii/smart-directories-navigation)

On 8/20/23, Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote:
> On Sun, Aug 20, 2023 at 1:15 AM Grant Taylor <gtaylor@tnetconsulting.net>
> wrote:
>>
>> Proper use of %{ and %} sequences to keep ZLE from counting the
>> non-printing / control characters helps a lot.
>
> In the vast majority of cases one can replace %{...%} with a
> first-class %-sequence. For example, instead of %{\033[31m%} one can
> use %F{red}.
>
> Roman.
>
>

Re: Help fix Zsh shell command prompt error or stranee

[Grant Taylor]

On 8/20/23 1:30 AM, Roman Perepelitsa wrote:
> In the vast majority of cases one can replace %{...%} with a
> first-class %-sequence.

I question the "vast" quantifier.

> For example, instead of %{\033[31m%} one canuse %F{red}.

Zsh has many SIMPLE PROMPT ESCAPES and CONDITIONAL SUBSTRINGS IN PROMPTS 
-- see zshmisc and / or zshall manual pages.  But they all seem to be 
specific to what appears on the prompt line(s).

This starts falling apart when you print terminal control characters / 
escape sequences used to alter the terminal window title or re-define 
the default terminal background / foreground colors and / or resize / 
reposition the terminal window itself.

N.B. there is very much so a difference in re-defining the terminal's 
current default vs specifying colors in the actual output.

Zsh has the most feature rich prompt support that I remember seeing. 
But even that doesn't cover all the things that I do.  Hence why Zsh 
includes the %{...$} and even the %G to alter how Zsh does or doesn't 
count characters output to the terminal.



Grant. . . .

Re: Help fix Zsh shell command prompt error or stranee

[Bart Schaefer]

On Sun, Aug 20, 2023 at 3:50 AM Budi <budikusasi@gmail.com> wrote:
>
> PS1=$(echo -e "$DIRSB\e[41;1;37m%~\e[44;1;33m\n%%\e[m ")
>
> DIRSB variable is none or sort of
> $(echo -e "${\e[41;1;37mWORD\e[m\n\r}")

I'm not going to try to work all of that out, but briefly, you need to
put a %{ in front of each \e and a %} following each m

And as Roman said, you can probably replace each %{...%} grouping that
creates, with one of the built-in macros like %F{red}...%f for
clarity.

Re: Help fix Zsh shell command prompt error or stranee

[Roman Perepelitsa]

On Tue, Aug 22, 2023 at 1:37 AM Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>
> On 8/20/23 1:30 AM, Roman Perepelitsa wrote:
> > In the vast majority of cases one can replace %{...%} with a
> > first-class %-sequence.
>
> I question the "vast" quantifier.

I'm intrigued. When is %{...%} necessary?

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.

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

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.). This is different from
prompt markers that I mentioned above, which must be embedded into the
prompt.


Roman.

Re: Help fix Zsh shell command prompt error or stranee

[Grant Taylor]

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