Why does zsh clear to end-of-screen after prompt?

Why does zsh clear to end-of-screen after prompt?

[John Hawkinson]

When I reposition the cursor to the top left corner of the screen (or anywhere), as with ESC [ H, when zsh prints a prompt it clears from the prompt to the end of the screen, oblitering any text on the screen already, which defeats the point of my cursor positioning.

Why does this happen, and why is it desirable?
I can workaround it by setting TERM=dumb, but that has other annoying side effects.
It does not appear to tbe the result of a precmd, and I still see it invoking zsh --no-rcs.

To reproduce:

   seq 1 10; export TERM=xterm-color; echo "\e[H foo\n"

Most of the ten lines output of seq is overwritten and nothing is seen.
By contrast:

  seq 1 10; export TERM=dumb; echo "\e[H foo\n"

prints the ten lines and moves the cursor to the top above them, as expected.

How can I get cursor positining to work without forgoing, e.g., line editing?


I feel like I'm missing something obvious.

--
jhawk@alum.mit.edu
John Hawkinson

Re: Why does zsh clear to end-of-screen after prompt?

[Bart Schaefer]

On Fri, Aug 25, 2023 at 12:53 PM John Hawkinson <jhawk@alum.mit.edu> wrote:
>
> When I reposition the cursor to the top left corner of the screen (or anywhere), as with ESC [ H, when zsh prints a prompt it clears from the prompt to the end of the screen, oblitering any text on the screen already, which defeats the point of my cursor positioning.

This happens because ZLE is a mult-line editor and also because
completion uses the space under the editor area to display lists etc.
If the screen were not cleared, text being edited could mingle with
the screen contents already present.

The clear-to-end-of-screen is actually printed BEFORE the prompt is
output, to make sure the prompt itself doesn't commingle with
anything, and the prompt always expects to be started in the leftmost
column or editing will be confused.

> How can I get cursor positining to work without forgoing, e.g., line editing?

You can try something like this:

PS1=$'%{\e[H%}'$PS1$'%{\e[K%}'

However, this only works because the cursor positioning is part of the
prompt string.  If you try to move the cursor with a command like in
your "echo" example, zle is still going to erase the whole screen at
and below the line where the cursor is positioned when the command
finishes.

There are also games to be played with save_cursor and restore_cursor,
e.g., a command that wants to control the screen appearance could move
to a position, save_cursor, and then move to the end of the screen, if
the prompt were then programmed to start with a restore_cursor -- but
you still have to be careful about that "start in the leftmost column"
and deal with avoiding the restore if the last command didn't save.

Re: Why does zsh clear to end-of-screen after prompt?

[John Hawkinson]

Bart Schaefer <schaefer@brasslantern.com> wrote on Fri, 25 Aug 2023
at 20:18:01 EDT in <CAH+w=7ZQaJgvk=wLX5mVEC4XR3AP1kxZU+t6O88PZFAZ6p6w9Q@mail.gmail.com>:

> This happens because ZLE is a mult-line editor and also because
> completion uses the space under the editor area to display lists etc.
> If the screen were not cleared, text being edited could mingle with
> the screen contents already present.

Ugh. I suppose it would be too much to ask that it not do this in the (for me) 90+% case where neither completion nor multi-line editing have been used?

Or only to clear as many lines as have been used, rather than to end-of-screen?

Or a knob to just not clear it and let the user deal with the fallout?

I was optimistic that

   setopt SINGLE_LINE_ZLE 

would solve this, but it does not.

Oddly

  setopt noZLE

does so, but it's a worse user experience than TERM=dumb.
At least with TERM=dumb I get up/down arrow, even if the editing is not quite right and overlaps the prompt in weird ways.


> > How can I get cursor positining to work without forgoing, e.g., line editing?
> 
> You can try something like this:
> 
> PS1=$'%{\e[H%}'$PS1$'%{\e[K%}'

Bah. I mean, yeah, that works, but it feels fairly not-great.

In case it wasn't apparent, the use case is I had a small ad hoc script that produced ~20 lines of key/value output and sometimes the values change and I'd like to keep them in the same position on the screen and just overwrite themselves when they change if I rerun the script with up-arrow/RET.

I guess another way is this:

OPS1="$PS1"	       # save it for idempotency later
PS1=$'%{\e[40H%}'$OPS1
echo '\e[H'; seq 1 20

which, for an 80x48 window, gives 8 lines for editing and commands that don't do any positioning, and leaves the top 40 lines for stuff that's prefixed by CSI H homing to the top-left. Maybe this is an acceptable balance, I dunno.

> There are also games to be played with save_cursor and restore_cursor,
> e.g., a command that wants to control the screen appearance could move
> to a position, save_cursor, and then move to the end of the screen, if
> the prompt were then programmed to start with a restore_cursor -- but
> you still have to be careful about that "start in the leftmost column"
> and deal with avoiding the restore if the last command didn't save.

Yeah, this feels even more...antithetical to the simplicity I was desiring.
Honestly it feels like just using bash for this particular one-off is the easiest way out :(

It seems to me, also, that the documentation could use some improvement on this point, but perhaps it is so obscure that it is going to be hard to find a good place to insert a straightforward discussion of this concern. If this thread doesn't reach any better resolution I'll do some thinking about ways to improve that.

Thanks, Bart.

--
jhawk@alum.mit.edu
John Hawkinson

Re: Why does zsh clear to end-of-screen after prompt?

[Bart Schaefer]

On Fri, Aug 25, 2023 at 5:59 PM John Hawkinson <jhawk@alum.mit.edu> wrote:
>
> Ugh. I suppose it would be too much to ask that it not do this in the (for me) 90+% case where neither completion nor multi-line editing have been used?

Maybe you're actually an audience for https://github.com/psprint/n-commodore ...

> In case it wasn't apparent, the use case is I had a small ad hoc script that produced ~20 lines of key/value output and sometimes the values change and I'd like to keep them in the same position on the screen and just overwrite themselves when they change if I rerun the script with up-arrow/RET.

If it's OK for the output to be at the top of the screen and the
prompt toward the bottom:

preexec() { print -n $'\e[H' }

You can make this conditional, e.g., only do it if repeating the same
command again, or make a widget that sets the desired starting
position of the output so this only happens if you use that widget
instead of accept-line, etc.

Re: Why does zsh clear to end-of-screen after prompt?

[Roman Perepelitsa]

On Sat, Aug 26, 2023 at 3:00 AM John Hawkinson <jhawk@alum.mit.edu> wrote:
>
> In case it wasn't apparent, the use case is I had a small ad hoc
> script that produced ~20 lines of key/value output and sometimes
> the values change and I'd like to keep them in the same position on
> the screen and just overwrite themselves when they change if I
> rerun the script with up-arrow/RET.

An alternative solution is to embed the info in PROMPT. In order to
avoid wasting 20 lines of the TTY real estate on each command, you can
automatically contract the prompt before executing each command. Thus,
if you run `pwd` twice in a row, your TTY might look like this:

    me@box ~ % pwd
    /home/me
    me@box ~ % pwd
    /home/me

    foo=bar
    baz=qux
    me@box ~ % █

In this approach the extra info ("foo=bar", etc.) is always displayed
right above the current prompt. This is basically Transient Prompt
from Powerlevel10k
(https://raw.githubusercontent.com/romkatv/powerlevel10k-media/master/transient-prompt.gif)
but with a fatter prompt.

Roman.

Re: Why does zsh clear to end-of-screen after prompt?

[Grant Taylor]

On 8/27/23 3:34 AM, Roman Perepelitsa wrote:
> An alternative solution is to embed the info in PROMPT. In order to
> avoid wasting 20 lines of the TTY real estate on each command, you can
> automatically contract the prompt before executing each command. Thus,
> if you run `pwd` twice in a row, your TTY might look like this:
> 
>      me@box ~ % pwd
>      /home/me
>      me@box ~ % pwd
>      /home/me
> 
>      foo=bar
>      baz=qux
>      me@box ~ % █
> 
> In this approach the extra info ("foo=bar", etc.) is always displayed
> right above the current prompt. This is basically Transient Prompt
> from Powerlevel10k
> (https://raw.githubusercontent.com/romkatv/powerlevel10k-media/master/transient-prompt.gif)
> but with a fatter prompt.

This looks like it might do something I've been contemplating doing. 
Having a prompt that is multiple lines but not taking up that screen 
real estate in history.

I need to reverse engineer this and adapt it to what I want to do.

I'd simply like a multi-line prompt that includes:
  - A separation line from the rest of the screen, blank or repeating 
sequence is fine.
  - A line that includes path and similar things.
  - The actual command entry line.

I already have transient RPROMPT.

Time to read & understand what is happening.  :-)



Grant. . . .

Re: Why does zsh clear to end-of-screen after prompt?

[Roman Perepelitsa]

On Sun, Aug 27, 2023 at 5:37 PM Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>
> I need to reverse engineer this and adapt it to what I want to do.

This will help:
https://github.com/romkatv/powerlevel10k/issues/888#issuecomment-657969840

Roman.

Re: Why does zsh clear to end-of-screen after prompt?

[Grant Taylor]

Hi Roman,

On 8/27/23 11:02 AM, Roman Perepelitsa wrote:
> This will help:
> https://github.com/romkatv/powerlevel10k/issues/888#issuecomment-657969840

Thank you very much.

I'll read and work to understand that to see how I can apply what I'd 
like to do to my prompt.  :-)



-- 
Grant. . . .

Re: Why does zsh clear to end-of-screen after prompt?

[Bart Schaefer]

On Fri, Aug 25, 2023 at 5:59 PM John Hawkinson <jhawk@alum.mit.edu> wrote:
>
> Bart Schaefer <schaefer@brasslantern.com> wrote on Fri, 25 Aug 2023
> at 20:18:01 EDT in <CAH+w=7ZQaJgvk=wLX5mVEC4XR3AP1kxZU+t6O88PZFAZ6p6w9Q@mail.gmail.com>:
>
> > This happens because ZLE is a mult-line editor and also because
> > completion uses the space under the editor area to display lists etc.
> > If the screen were not cleared, text being edited could mingle with
> > the screen contents already present.
>
> Ugh. I suppose it would be too much to ask that it not do this in the (for me) 90+% case where neither completion nor multi-line editing have been used?

How about this, then?  I'd completely forgotten about "zle -T" ...

no_clr_eos () {
  emulate -L zsh
  if [[ $1 == cd ]]
  then
    REPLY=""
  elif [[ -n $2 ]]
  then
    REPLY=$(echotc "$@")
  else
    REPLY=$termcap[$1]
  fi
}
zmodload zsh/termcap
precmd() { zle -T tc no_clr_eos }
zle-line-init () { zle -Tr tc }
zle -N zle-line-init

No promises on how this affects performance.  Optionally add:

zle-line-finish() {
 CURSOR=$#BUFFER
 zle -R
 echotc cd
}
zle -N zle-line-finish

Conversion to add-zsh-hook / add-zle-hook-widget left as an exercise.