https://bugs.kde.org/show_bug.cgi?id=384218
--- Comment #5 from Egmont Koblinger <egm...@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 watching all bug changes.
