[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 #5 from Egmont Koblinger <egmont at gmail.com> ---
(In reply to RJVB from comment #4)

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

I don't understand what you mean here. Partly there's a confusion in
terminology, whether the word "scrollback" includes the normally onscreen
contents (I don't think it should, although I might have been sloppy
previously). The onscreen contents can randomly change at any time (and it does
with quite a few apps, e.g. fullscreen ones that don't switch to alternate
screen such as "top"), so I don't think it's feasible to speak about
automatically adding these to the scrollback. Anyway, it's unclear to me what
the user-visible behavior would be with your suggestion.

> [...] so there must be another way to "push the visible part of the
> scrollback up off the sreen" than by adding empty lines.

That's what happens now. The visible part is pushed up. The visible part
sometimes just happens to be 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.

This is indeed one possibility, which might solve _some_ of the problems, but
definitely not all. E.g. with the current E3-aware "clear" command the result
would still be silly. You'd get the scrollback wiped out first, but then the
currently visible bits (by the time of executing "clear") would be remembered
in 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?

I don't know if it's possible to bound a single key into executing a command. I
can't recall such a feature.

> Then you're not properly emulating an existing physical terminal anymore.

My knowledge about physical terminals is quite sparse, but I don't recall any
of them having a scrollback buffer at all. Please tell me if I'm wrong.

Since the only difference between xterm and konsole is what goes on to the
scrollback on "\e[2J", as far as correct emulation of physical terminals is
concerned, neither of them are wrong or right, they are just different.

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

The current situation is indeed far from perfect. If E3 isn't involved, then
xterm's behavior never adds blank lines, however, sometimes wipes out precious
data; whereas konsole never wipes out previous data, yet sometimes adds blank
lines. I think the latter one (konsole's) is better. However, introducing E3
completely changes the game, and suddenly xterm's behavior makes more sense to
me.

Of course this is tayloring the emulator's behavior to what apps do, and as
such, it's quite a nonsense approach. Ideally all emulators would copy xterm's
behavior, and apps such as "clear" or bash's Ctrl+L would make sure to scroll
out the contents. Konsole's and vte's workaround is a quite nasty one for the
sake of usability (data preservation).

This is a quite complex scenario, any modification probably fixes certain
things while breaks others. Thus you can't improve the situation if you omit E3
and the "clear" command from the picture.

Anyway, it seems to me that a noticeable improvement to this situation would
require heavy cooperation of some key players in the game, including xterm,
terminfo and bash; maybe even implementing a new escape sequence. As much as
I'd love this to happen, I don't see a reasonable chance.

That being said, I'm not a konsole developer, so I can't have a word in what it
implements. I'm just trying to show you the bigger picture.

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