GNOME Bugzilla – Bug 771953
Inhibit "clear scrollback" escape sequence
Last modified: 2021-06-10 15:16:16 UTC
Especially with infinite scrollback, I think it sucks that an escape sequence (and in turn the "clear" or "reset" commands) can simply wipe it out. Although some folks like it. Should we perhaps introduce an API that disables the \e[3J sequence? See also: https://bugs.kde.org/show_bug.cgi?id=368005 https://gitlab.com/gnachman/iterm2/issues/5058
See https://bugzilla.redhat.com/show_bug.cgi?id=815790 for some small values of 'why' this was introduced. Personally I agree that a simple clear shouldn't clear the scrollback buffer, so shouldn't use E3. Either this should be taken up with the ncurses maintainer, or we should disable CSI 3J by default, and expose clearing the scrollback in the API so that we can bind it to some menu item in g-t.
So, apparently this originates from the Linux console to overcome this terrible hack: "[...] it then changes the foreground virtual terminal to another terminal and then back to the original terminal." Also it makes sense there because: - the terminal is not closed when the user logs out (which is a privacy concern that does not exist at graphical terminals); - the scrollback is quite small anyways so there's not much to lose. There's much less point for this in graphical terminals because: - it's automatically wiped out when you log out; - the scrollback can contain tons of precious data which you wouldn't want to see getting wiped out during normal operation; - this feature can easily be invoked from a menu entry or even a hotkey; - it's usually a cheap operation to close the terminal and open a new one instead.
See also https://bugs.kde.org/show_bug.cgi?id=384218.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/2342.