zle - poor terminal echo on input line shortening

zle - poor terminal echo on input line shortening

[Per Bothner]

[I am not on the zsh-workers list, so please cc me on any responses.]

Consider typing an input line like 'echo foobar' and then deleting the last 3
characters (by backspacing).  That logically and visually yields "echo foo".
However, if you copy the line from some terminals (e.g. gnome-terminal), and paste
(into say emacs) you get "echo foo   " with extra spaces.  That is because zle
sends "\b \b" in response to the backspace.  Some terminals keep track of the
maximum number of characters written to a line so they can distinguish explicit
space from "non-written" padding.

Both bash/readline and fish get this right because they instead send "\b\e[K".

This also show up in different colors/styling on the DomTerm terminal emulator
(https://domterm.org) because it sets a special css style for the actual input line.

Of course this is a very minor issue ...
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: zle - poor terminal echo on input line shortening

[Bart Schaefer]

On Sun, Apr 7, 2019 at 4:47 PM Per Bothner <per@bothner.com> wrote:
>
> However, if you copy the line from some terminals (e.g. gnome-terminal), and paste
> (into say emacs) you get "echo foo   " with extra spaces.  That is because zle
> sends "\b \b" in response to the backspace.

ZLE is in most cases sending what the terminfo (termcap, curses)
library says will update the screen in the least number of transmitted
bytes.  In fact I don't think ZLE even explicitly defines that
sequence anywhere; if you delete 3 characters in the middle of a line
it'll still draw spaces on top of 3 characters at the end when
"repainting" everything to the right of the deletion.

> Both bash/readline and fish get this right because they instead send "\b\e[K".

Readline/fish don't have the $RPOMPT that (if present) would be erased
by "\e[K", among other things.