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

[RJVB]

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

--- Comment #4 from RJVB <rjvbertin at gmail.com> ---
Egmont Koblinger wrote on 20170901::20:08:49 re: "[konsole] [Bug 384218]
clear/^l shouldn't add empty lines to the scrollback buffer"


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

Hmm, indeed, the lines that were visible never get added to the scrollback
buffer. That never bothered me for "clear" but it did for swapping with the
alternate screen (e.g. running vi).

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

There is another approach: add each line to the scrollback when it first
appears, and don't remove them during a 'clear' unless the scrollback buffer is
to be cleared too. Evidently you'd have to change something in the scrollback
offset mechanism but I'd hope that should be trivial.
Come to think of it, lines are probably already added as soon as they're
output, so there must be another way to "push the visible part of the
scrollback up off the sreen" than by adding empty lines.
At the very least it should be trivial to avoid adding more empty lines than
necessary. If the terminal shows 10 lines when the clear command is entered,
the scrollback needs only be moved up (flushed) over 10 lines. If that number
is 0 (= the prompt already at the top of the screen), then 0 lines need to be
flushed.

I think that's actually what irks me most. I use Ctrl-L instead of clear (see
below) and it happens that I hit it multiple times, unconsciously. I know
there's no need for me to do that, but it shouldn't have the side-effect it
currently has.

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

I've been using *csh shells since before bash was born the 1st time; Ctrl-L is
aliased to the clear command. Should be possible in bash too, no?

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

Then you're not properly emulating an existing physical terminal anymore. I
don't see how you can this without dedicated terminfo entry, be it in the
on-disk database or via some sort of initial handshake (like baked-in monitor
colour profiles).
Either way, I'd see this as "the user indicates how a given escape sequence
emitted by the app is interpreted by the terminal".

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

E3 isn't involved in the issue that irks me so I don't see how dropping support
for it would change anything?

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