Terminal: Feature Request Move scroll buffer instead of clearing on CTRL+L and on clear

[bbhopesh]

Description of the new feature/enhancement

On WSL, Typing clear or pressing CTRL+L clears the scroll buffer history while most Linux terminals(both real ones like gnome-terminal, and virtual ones like tmux) move the scroll history instead of clearing it. Can we use same semantics for Windows Terminal?

[j4james]

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

[bbhopesh]

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.

[egmontkob]

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.

[j4james]

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.

[bbhopesh]

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.

[DHowett-MSFT]

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

[egmontkob]

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.

[DHowett-MSFT]

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 😄

[bbhopesh]

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.

[getify]

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]

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

[DHowett-MSFT]

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.

[zadjii-msft]

I implemented support for passing through the ^[[2J sequence (which is emitted when the user presses ctrl+L or runs clear) in #5683. It'll be available in a future Windows Terminal release (when the bot comes through and says it is 😝)

EDIT: damn Dustin beat me

[msftbot[bot]]

:tada:This issue was addressed in #5683, which has now been successfully released as Windows Terminal Release Candidate v0.11.1333.0 (1.0rc2).:tada:

Handy links:

• Release Notes
• Store Download

[KaKi87]

Hello,
I'm currently running v0.11.1333.0, and, while clear and cls works, Ctrl+L doesn't.
Any ideas why ?
Thanks

[DHowett]

That depends very heavily on what she’ll you are using. It is your shell’s job to handle Ctrl+L.

What shell are you using?

[KaKi87]

As recommended in #5458, I emptied my settings file, so that defaults can be regenerated.
And, the default shell in the default configuration is set to PowerShell 6.
So, in PowerShell 6, Ctrl + L doesn't work.
Thanks