zsh-workers
 help / Atom feed
* zle - poor terminal echo on input line shortening
@ 2019-04-07 23:46 Per Bothner
  2019-04-08 15:09 ` Bart Schaefer
  0 siblings, 1 reply; 2+ messages in thread
From: Per Bothner @ 2019-04-07 23:46 UTC (permalink / raw)
  To: zsh-workers

[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/

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: zle - poor terminal echo on input line shortening
  2019-04-07 23:46 zle - poor terminal echo on input line shortening Per Bothner
@ 2019-04-08 15:09 ` Bart Schaefer
  0 siblings, 0 replies; 2+ messages in thread
From: Bart Schaefer @ 2019-04-08 15:09 UTC (permalink / raw)
  To: zsh-workers

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.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, back to index

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-07 23:46 zle - poor terminal echo on input line shortening Per Bothner
2019-04-08 15:09 ` Bart Schaefer

zsh-workers

Archives are clonable: git clone --mirror http://inbox.vuxu.org/zsh-workers

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.workers


AGPL code for this site: git clone https://public-inbox.org/ public-inbox