[konsole] [Bug 384218] clear/^l shouldn't add empty lines to the scrollback buffer

[Egmont Koblinger]

https://bugs.kde.org/show_bug.cgi?id=384218

--- Comment #3 from Egmont Koblinger <egmont at gmail.com> ---
(In reply to RJVB from comment #2)

> Currently Konsole emulates well-known terminals, but it could
> very well define its own terminal type [...]

As far as I know, konsole has been there, it used to work with TERM=konsole or
something similar. I guess they had their reason to go for TERM=xterm (or a
variant thereof) instead.

gnome-terminal has also been there, it used to set TERM=gnome or maybe
TERM=vte. It also had its reason to revert.

Probably both approaches have their own downsides, but apparently both projects
decided that going with TERM=xterm sucks less.

> FWIW, clear sends this to an xterm: `ESC[HESC[2J`

This is the old fashioned one that does not clear the scrollback. The new
version is:

ESC[3J -> clears the scrollback
ESC[H  -> moves the cursor to the upper left corner
ESC[2J -> clears the onscreen contents

For the first one, I can't think of any other possible reasonable behavior than
either clearing the scrollback, or not doing anything. I'll get back to this.

For the middle one there's not much to discuss, changing its behavior in any
way would probably break tons of apps. Also it's pretty much irrelevant to this
bug.

For the last one, this is where konsole and VTE (gnome-terminal and friends)
differ from xterm and scroll out these lines to the scrollback buffer. I'll get
back to this too.

> The other possibility might be to support E3 (might also require shipping a
> dedicated terminfo file!), catch whatever specific `clear` sends to the tty
> as a result, and the provide a profile option whether or not the scrollback
> buffer should be cleared. The simple presence of that E3 command indicates
> that a clear was requested.

So... Let's first see the old behavior where \e[3J wasn't emitted or wasn't yet
supported by the terminal emulator, or assume that there's a profile setting
implemented where the user disables this feature. Then:

- The traditional way, xterm's approach wipes out the onscreen contents, but
the scrollback remains intact. That is, effectively, a screenful of lines will
go missing from the scrollback. From a usability point of view, this doesn't
make any sense to me.

- Hence here come konsole and vte which modify this and scroll out these lines.
The behavior is now sane, I get to see the proper history in the scrollback.

Now let's introduce the "clear scrollback" feature.

- The traditional way, xterm's now makes sense when you execute "clear". You
pretty much get a "clean start". (It still doesn't make too much sense with
let's say hitting Ctrl+L in bash which does an old-fashioned clear, without
clearing the scrollback.)

- konsole's and vte's behavior no longer make too much sense with the "clear"
command, at least a screenful of empty lines appear in the scrollback – this is
what your bugreport is about. (It still makes sense with e.g. bash's Ctrl+L.)

So we already see a damn complicated support matrix of all possible scenarios
with no straightforward way of getting all possibilities work as expected.

One idea that occurred to me but I don't find it a good one: If a config option
is introduced to enable/disable wiping out the scrollback (i.e. whether to
support \e[3J or not), this same option could also change the behavior of \e[2J
(current vs. xterm-compatible). This would "fix" the "clear" command, but would
probably cause even more breakage and confusion for bash's Ctrl+L. Also, it's
not the way terminal emulators should work. It shouldn't be the escape sequence
emitted by the app defining how the terminal emulation should be done, it's the
other way around. The terminal emulation behavior should determine what the app
in turn emits. Also ugly as hell and other unforeseen side effects are also
possible.

Another possible approach, although I'm really unsure if the relevant person
could be convinced to adapt terminfo to konsole's and vte's xterm-incompatible
behavior: Alter the sequence emitted by "clear" so that wiping out the
scrollback is the last step. (Doing this would indeed be simpler if konsole
used its own TERM.)

Yet another possibility is to drop \e[3J support, for reasons outlined in the
already mentioned https://bugzilla.gnome.org/show_bug.cgi?id=771953.

-- 
You are receiving this mail because:
You are the assignee for the bug.