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