Feature Request Move scroll buffer instead of clearing on CTRL+L and on clear #3960

https://superuser.com/a/1110683

@j4james commented on GitHub (Sep 21, 2019):

As far as I know, clearing the scrollback buffer has been the expected behaviour of the clear command for several years now. From the man page:

clear clears your screen if this is possible, including its scrollback buffer (if the extended “E3” capability is defined).

There are more details in the man page documenting the history of the change if you're interested.

And if you don't like this behaviour, you may be able to update your terminfo to remove the E3 capability, which I think should get you the old behaviour. There's an answer on superuser.com describing how to do this for CentOS, which may also work for WSL (I haven't tried it myself).

@j4james commented on GitHub (Sep 21, 2019): As far as I know, clearing the scrollback buffer has been the expected behaviour of the `clear` command for several years now. From the man page: > **clear** clears your screen if this is possible, including its scrollback buffer (if the extended “E3” capability is defined). There are more details in the man page documenting the history of the change if you're interested. And if you don't like this behaviour, you may be able to update your terminfo to remove the E3 capability, which I think should get you the old behaviour. There's an answer on superuser.com describing how to do this for CentOS, which may also work for WSL (I haven't tried it myself). https://superuser.com/a/1110683

claunia commented

@bbhopesh commented on GitHub (Sep 21, 2019):

By old behavior, you mean the behavior of clearing scroll back buffer instead of just moving it?

I am actually looking for behavior where scroll buffer is not cleared and I still have capability to scroll back and see older commands.

@bbhopesh commented on GitHub (Sep 21, 2019): By old behavior, you mean the behavior of clearing scroll back buffer instead of just moving it? I am actually looking for behavior where scroll buffer is not cleared and I still have capability to scroll back and see older commands.

claunia commented

@egmontkob commented on GitHub (Sep 21, 2019):

On modern Linux systems, clear and Ctrl+L do different things. clear instructs the terminal emulator to clear the history, and most terminals do so. bash's Ctrl+L keyboard shortcut doesn't, it preserves the scrollback buffer, just like clear -x.

About clearing the current screen (but not the scrollback):

The traditional way of implementing onscreen clear (without clearing the scrollback), e.g. the way xterm does it, is simply to erase the onscreen lines. This results in the last screenful of your work getting wiped out: e.g. execute seq 1000, then press Ctrl+L, scroll back, the last number is 977 or so.

Some terminals (e.g. VTE, and Konsole up until recently) think this is not what the user wants to have, and instead push these lines up into the scrollback buffer. [There is even a difference of 1 between the number of lines VTE scrolls vs. Konsole scrolled out. VTE scrolls one more, you often end up with a blank line. Konsole, however, wiped out the partial line before the cursor if your output didn't end in a newline.] [A terminal could even easily implement an adaptive scrollout, based on the cursor's location, or the actual onscreen nonempty vs. empty lines.]

clear (in ncurses) about a year ago fixed its behavior to clear the onscreen contents first, followed by the scrollback. Up until a year ago it performed these two steps in the opposite order, which resulted in one page of data remaining in the scrollback in VTE and recent Konsole.

See VTE 506438 for boring details, most of which are no longer relevant due to this recent fix in clear; as well as Konsole 384218 for their counterpart, and also how they reverted to the traditional behavior unaware of the recent clear fix which made it pointless.

About clearing (or not) the scrollback:

As of the aforementioned clear fix, the entire scrollback is properly cleaned both on xterm-like and VTE-like emulators.

However, nothing stops a terminal from offering a config option to deliberately refuse to clear the scrollback, just as filed at VTE 771953 (not yet implemented). Not sure how much it's worth it. One could argue that user can just alias clear to clear -x, or hack around in terminfo as per an aforementioned answer, and that's probably good enough.

@egmontkob commented on GitHub (Sep 21, 2019): On modern Linux systems, `clear` and `Ctrl+L` do different things. `clear` instructs the terminal emulator to clear the history, and most terminals do so. `bash`'s `Ctrl+L` keyboard shortcut doesn't, it preserves the scrollback buffer, just like `clear -x`. --- About clearing the current screen (but not the scrollback): The traditional way of implementing onscreen clear (without clearing the scrollback), e.g. the way xterm does it, is simply to erase the onscreen lines. This results in the last screenful of your work getting wiped out: e.g. execute `seq 1000`, then press `Ctrl+L`, scroll back, the last number is 977 or so. Some terminals (e.g. VTE, and Konsole up until recently) think this is not what the user wants to have, and instead push these lines up into the scrollback buffer. [There is even a difference of 1 between the number of lines VTE scrolls vs. Konsole scrolled out. VTE scrolls one more, you often end up with a blank line. Konsole, however, wiped out the partial line before the cursor if your output didn't end in a newline.] [A terminal could even easily implement an adaptive scrollout, based on the cursor's location, or the actual onscreen nonempty vs. empty lines.] `clear` (in ncurses) about a year ago fixed its behavior to clear the onscreen contents first, followed by the scrollback. Up until a year ago it performed these two steps in the opposite order, which resulted in one page of data remaining in the scrollback in VTE and recent Konsole. See [VTE 506438](https://bugzilla.gnome.org/show_bug.cgi?id=506438) for boring details, most of which are no longer relevant due to this recent fix in `clear`; as well as [Konsole 384218](https://bugs.kde.org/show_bug.cgi?id=384218) for their counterpart, and also how they reverted to the traditional behavior unaware of the recent `clear` fix which made it pointless. --- About clearing (or not) the scrollback: As of the aforementioned `clear` fix, the entire scrollback is properly cleaned both on xterm-like and VTE-like emulators. However, nothing stops a terminal from offering a config option to deliberately refuse to clear the scrollback, just as filed at [VTE 771953](https://bugzilla.gnome.org/show_bug.cgi?id=771953) (not yet implemented). Not sure how much it's worth it. One could argue that user can just alias `clear` to `clear -x`, or hack around in terminfo as per an aforementioned answer, and that's probably good enough.

claunia commented

@j4james commented on GitHub (Sep 21, 2019):

One could argue that user can just alias clear to clear -x

I hadn't noticed that -x option - this seems like the perfect solution to me. I definitely wouldn't be in favour of adding a terminal option to break the E3 functionality - that sounds like a recipe for disaster.

@j4james commented on GitHub (Sep 21, 2019): > One could argue that user can just alias `clear` to `clear -x` I hadn't noticed that `-x` option - this seems like the perfect solution to me. I definitely wouldn't be in favour of adding a terminal option to break the E3 functionality - that sounds like a recipe for disaster.

claunia commented

@bbhopesh commented on GitHub (Sep 21, 2019):

I am coming here from gnome world(Ubuntu 18.0, Fedora Workstation). In gnome-terminal, CTRL+L and clear behave almost identically if not exactly. -x flag is a useful workaround for now but I am more used to CTRL+L and I will find it extremely useful if I could configure what CTRL+L does on Windows terminal.

@bbhopesh commented on GitHub (Sep 21, 2019): I am coming here from gnome world(Ubuntu 18.0, Fedora Workstation). In gnome-terminal, CTRL+L and clear behave almost identically if not exactly. `-x` flag is a useful workaround for now but I am more used to CTRL+L and I will find it extremely useful if I could configure what CTRL+L does on Windows terminal.

claunia commented

@DHowett-MSFT commented on GitHub (Sep 21, 2019):

What ^L does is up to your shell, not up to the terminal. Sorry!

@DHowett-MSFT commented on GitHub (Sep 21, 2019): What <kbd>^L</kbd> does is up to your shell, not up to the terminal. Sorry!

claunia commented

@egmontkob commented on GitHub (Sep 21, 2019):

Well, ^L emits the standard clear escape sequence, most likely ^[[H^[[2J, out of which the second half matters here. And as I've stated before, there's some room for terminals to behave differently here, like xterm clearing in-place the onscreen contents vs. VTE scrolling them out.

I think both of them are equally valid, since probably no terminal emulation standard knows about a scrollback buffer. Anything that happens to the scrollback is unspecified territory.

IMO in an ideal world all terminals and applications would agree on the behavior, decide whose responsibility it is to scroll out, and then consistently implement scrolling out the contents, since losing the last page of data is hardly likely what the user wants. Unfortunately there's no common agreement whether this should be the responsibility of the terminal or the application, hence the confusion and the hacks like vte's. So you can also change Windows Terminal's behavior to some extent and remain standards-complying.

@egmontkob commented on GitHub (Sep 21, 2019): Well, <kbd>^L</kbd> emits the standard clear escape sequence, most likely `^[[H^[[2J`, out of which the second half matters here. And as I've stated before, there's some room for terminals to behave differently here, like xterm clearing in-place the onscreen contents vs. VTE scrolling them out. I think both of them are equally valid, since probably no terminal emulation standard knows about a scrollback buffer. Anything that happens to the scrollback is unspecified territory. IMO in an ideal world all terminals and applications would agree on the behavior, decide whose responsibility it is to scroll out, and then consistently implement scrolling out the contents, since losing the last page of data is hardly likely what the user wants. Unfortunately there's no common agreement whether this should be the responsibility of the terminal or the application, hence the confusion and the hacks like vte's. So you can also change Windows Terminal's behavior to some extent and remain standards-complying.

claunia commented

@DHowett-MSFT commented on GitHub (Sep 21, 2019):

That’s fair, actually. I think that conhost implements scroll-off for ED 2, but perhaps somewhere in our translation later we are mishandling that. Standardization would be great 😄

@DHowett-MSFT commented on GitHub (Sep 21, 2019): That’s fair, actually. I think that conhost implements scroll-off for ED 2, but perhaps somewhere in our translation later we are mishandling that. Standardization would be great 😄

claunia commented

@bbhopesh commented on GitHub (Sep 21, 2019):

I didn't spend enough time to understand how ctrl+l or clear work but it looks like when a virtual terminal is running, it handles ctrl+l and when it is not physical terminal handles it e.g. when I am using tmux on Windows terminal, ctrl+l is handled by tmux. It moves tmux's scroll buffer instead of clearing it. However, when tmux is not running, windows terminal handles it and clears the scroll buffer.

@bbhopesh commented on GitHub (Sep 21, 2019): I didn't spend enough time to understand how ctrl+l or clear work but it looks like when a virtual terminal is running, it handles ctrl+l and when it is not physical terminal handles it e.g. when I am using tmux on Windows terminal, ctrl+l is handled by tmux. It moves tmux's scroll buffer instead of clearing it. However, when tmux is not running, windows terminal handles it and clears the scroll buffer.

claunia commented

@getify commented on GitHub (Nov 8, 2019):

iterm2 (mac) has "cmd+r" for the kind of clear that is just scrolling the contents off screen (but not clearing the buffer). I find this a useful form of clearing.

It would be nice if there was a "command" for "clearByScroll" or something like that, so that we could assign our own keyboard shortcut for it.

@getify commented on GitHub (Nov 8, 2019): iterm2 (mac) has "cmd+r" for the kind of clear that is just scrolling the contents off screen (but not clearing the buffer). I find this a useful form of clearing. It would be nice if there was a "command" for "clearByScroll" or something like that, so that we could assign our own keyboard shortcut for it.

claunia commented

@getify commented on GitHub (May 11, 2020):

It's not clear what the outcome is of this issue?

@getify commented on GitHub (May 11, 2020): It's not clear what the outcome is of this issue?

claunia commented

@DHowett-MSFT commented on GitHub (May 11, 2020):

There was a pull request that fixed it, and there was a fix, and that fix was committed, and that's the absolute most current status of this issue.

@DHowett-MSFT commented on GitHub (May 11, 2020): There was a pull request that fixed it, and there was a fix, and that fix was committed, and that's the absolute most current status of this issue.

claunia commented