Ctrl+L clears screen, not scrolling up to scrollback buffer

[orangelynx]

Having tried many terminal emulators, wsltty is by far my favourite so far (does everything right pretty much out of the box).

What it doesn't seem to do right however is the behaviour of Ctrl+L. For me, this shortcut clears the scrollback buffer (partly or fully), meaning that if I start wsltty, do df -ah or ll in the startup ZSH, and then do ctrl+L, I cannot scroll back up to see the old output (like I did clear).

How do I know it's not ZSH or bash to blame? Well, I don't know for sure, but using the stock Debian WSL terminal, it works as it should.

[mintty]

Works here. First, Ctrl+L does nothing at the terminal. It causes the shell to do an equivalent of the clear command, using terminfo as a reference for what precisely to send to the terminal. What's your setting of $TERM in mintty and stock terminal? Do you use any intermediate layer, like tmux?

[orangelynx]

mintty WSL and Debian stock shell both have xterm-256color for $TERM. I sometimes use tmux, but this is on the plain shell.

In the above gif, I do df -ah on a new window, ctrl+l and try to scroll back up. it works only in the debian stock shell. If I fill the scrollback with multiple df -ah and do ctrl-l it truncates the scrollback for mintty.

Btw, for clarity, as I understand it, ctrl+L is supposed to be equivalent to clear -x, not plain clear, which WILL clear the scrollback buffer.

[mintty]

Not sure about your description. After one df -ah my screen isn't even full once, so there is no scrollback buffer. If I run it twice, then ^L, I can scroll back to the scrolled-out part. What's the value of Scrollback lines in your Option menu, section "Window"?

[orangelynx]

So perhaps my understanding is wrong, but I expect the currently visible part to not get deleted when I ctrl+L, even when it's not technically part of the scrollback buffer yet. The stock shell keeps all output of all df calls, whether part of the "visible" screen (?) buffer or part of the non-visible scrollback buffer.

I set 10000 lines of scrollback, it's not different with 100 lines though.

I get that gif is a bit confusing, I can make another if it's still not clear.

[mintty]

Now I've seen what you mean. So that's an "auto-scroll-out before clear" feature but it's not in the traditional of terminal behaviour. The prototypes for mintty are DEC terminals and xterm, the Unix workhorse, with which mintty is compatible in this respect, sorry.

[mintty]

Also, traditionally, the "scrollback buffer" is the past part of output that has scrolled out from the visible screen, so the visible part is not strictly part of the scrollback buffer (although you could redefine the desired meaning of the word).

[orangelynx]

related: https://github.com/microsoft/terminal/issues/2832

[Biswa96]

Just FYI, if you are familiar with using X11 apps in WSL then you can run xterm program (or any bigger terminal emulator) and compare its behavior with mintty.

[orangelynx]

@Biswa96 thanks. I'm working from homeoffice on my private PC running windows now, but i used remote desktop to test the behaviour of the terminals on different linux machines at work. On XFCE and Ubuntu, the stock terminals have the scrollback feature, also tilix does. xterm does behave the same as wsltty, however. While I understand that the project goal is to be consistent to xterm, I think it's a pitty nevertheless, since many other emulators do have the feature and wsltty does alot right out-of-the-box.

[mintty]

If clear would send the actual clear sequence first (ESC[2J), then move the cursor home, this would be an easy endeavour. Unfortunately, clear first moves the cursor home, so there is no unique reference as to which part of the screen should be scrolled out in that case. I just checked vte which scrolls out even empty lines from the lower part of the screen - I think that is not desirable. So clear criteria need to be agreed as a design task.

[mintty]

It turns out that an implementation of the requested behaviour had already been available in the code, just not enabled because it's not compatible with xterm. I'll enable it for the next release, maybe guarded by an option (to be decided).

[mintty]

Released 3.4.7.