micro shows previous mangled text when scrolling up after resizing the terminal

[AmerM137]

This is an issue I opened on the windows terminal repo. It sounds like it may be an issue with micro, and not the terminal. Please see issue and reply from DHowett here https://github.com/microsoft/terminal/issues/16409.

It looks like micro may not be using the "Xterm Alternate Screen Buffer" on Windows. It's fairly easy to reproduce, all it takes is resizing the terminal once and the previous buffer start showing up. See below for steps.

Windows Terminal version

1.18.3181.0

Windows build number

10.0.19045.3693

Specifications for micro & other editors

micro text editor 2.0.13 -- commit hash 68d88b57 nano for windows 7.2-22.1 -- https://github.com/okibcn/nano-for-windows

Steps to reproduce

Windows Terminal settings: Scrollbar visibility == Hidden, History size == 9001 Launch windows terminal, launch micro text editor. Write a few lines, resize terminal (larger->smaller or smaller->larger). Resizing unlocks ability to scroll up using keyboard bindings or using mouse select. Previous buffer shows with characters jumbled up / misaligned.

Same issue using windows terminal with nano editor. Same issue using wezterm with both micro and nano. Same issue using alacritty with both micro and nano. Tested with nvim. No issue with nvim on all terminal emulators (cannot scroll back after resizing). This should be actual behavior for all editors.

Expected Behavior

Text should be redrawn normally and inability to scroll back should be maintained.

Actual Behavior

Resizing "unlocks" scrolling again, causing previous ghost text/buffers to show up. Particularly annoying when trying to drag-select with the mouse near the top of the file. Very confusing when seeing the previous buffers, especially when the text is all misaligned.

[JoeKar]

I assume that this should be initiated by zyedidia/tcell, which initiates a Windows terminal different from Linux terminals... screen.go#L231 ...for which it usually sets the EnterCA, to enter the alternate mode (without scroll back support).

I'm unsure if the "Windows Terminal" now needs a different handling or special sort of smcup/rmcup.

At the end this shouldn't be a problem of micro in the first place, but maybe one of its dependencies.

[AmerM137]

@JoeKar what do you suggest the next step should be? I am not familiar with go/tcell enough to contribute a fix. I also wanted to add that sometimes, after resizing micro, if you exit, some of the text file remains visible on the screen at the bottom.

[JoeKar]

Someone needs to take a deeper dive into tcell again, if it really needs a patch for the current Windows terminal (approach). Unfortunately I've some lack in time too and Windows isn't my primary OS.

Maybe someone else can take a look into that.

Update: Looks like the NewConsoleScreen() is more or less designed for the "Windows Console host" (conhost.exe) and maybe cmd.exe, but the "Windows Terminal" wants to be more like the Linux terminals...at least according to this. So most probably the NewTerminfoScreen() is then the way to go, but how can we check if it's executed in one or the other? Because it was explicitly switched into that direction preventing problems caused by defined $TERM in conhost sessions.

We could re-use the xterm (forced) option flag to force tcell to use the NewTerminfoScreen() instead of NewConsoleScreen() under windows, but this needs a tcell change as well.

@dmaluka: What do you think, is it worth the try to add this kind of forced terminal functionality into tcell derived from micro's the xterm option?

[dmaluka]

If it works well, why not. But I know nothing about windows terminals.

[DHowett]

Hey there! I'm the maintainer for the Windows Console subsystem and the Terminal. I followed @AmerM137 over here from microsoft/terminal#16409.

I just wanted to follow up and say that tcell can rely on the xterm alternate screen buffer being supported even in conhost on all versions of Windows at or above 10.0.14393.0 (released in 2016), as long as ENABLE_VIRTUAL_TERMINAL_PROCESSING is enabled! :smile:

I know that it's been annoying trying to detect whether your code is running inside Windows Terminal... which is why I try to show up and tell people when things work in conhost as well.

[JoeKar]

@DHowett Thank you for taking the time to give some insights/hints for a better understanding. It will help a lot to hopefully solve this in micro's fork of tcell and maybe even upstream.

When I understood your statement right, then this doesn't apply to the "old" cmd, am I right...it's just the behavior of conhost and Windows Terminal? Sorry, if this is a stupid question, but I rarely use Windows (more or less as host for VirtualBox at work) and didn't go into Windows' details since years now.

I will see if I find some time to support here and if I can acquire the notebook of my wife again. :smile:

Update:

• https://github.com/zyedidia/tcell/blob/969958742a553232cbae8fcc291907a98e57b860/console_win.go#L222
  • ENABLE_VIRTUAL_TERMINAL_PROCESSING set as modeVtOutput in case s.truecolor is set, which isn't by default
• https://github.com/zyedidia/tcell/blob/969958742a553232cbae8fcc291907a98e57b860/console_win.go#L217
  • doesn't set ENABLE_VIRTUAL_TERMINAL_INPUT respective modeVtInput yet

So even in case we would somehow trigger smcup or the respective xterm pendant to enable the alternate screen buffer it would fail due to the not enabled input/output modes necessary for conhost/Windows Terminal to work properly. Especially the dependency to the true color setting needs to be discussed.

[DHowett]

When I understood your statement right, then this doesn't apply to the "old" cmd, am I right...it's just the behavior of conhost and Windows Terminal? Sorry, if this is a stupid question, but I rarely use Windows (more or less as host for VirtualBox at work) and didn't go into Windows' details since years now.

Not a stupid question at all! Windows has made this very confusing.

conhost is the built-in terminal emulator for Windows, and it's what you're actually seeing when you run cmd. It's just like xterm, except that it opens automatically when you run a text-only application.

So when I say that conhost supports the alternate screen buffer, that means that whether your code is running below cmd or powershell or bash.exe (the Cygwin one) you'll have access to the same VT features. :smile:

(I haven't had time to digest your update, sorry this response doesn't include it! However: I would guess that tcell only enables VIRTUAL_TERMINAL_PROCESSING when true color is requested because that was the first or most visible feature that required VT on Windows. In my opinion, all applications should use VIRTUAL_TERMINAL_PROCESSING mode first and only fall back to the legacy ways if they need to!)

[JoeKar]

@AmerM137 It took a while till I found some minutes to spend, but it looks quite promising now.

@DHowett Thanks again for your support.

[AmerM137]

Thank you @JoeKar for looking into it! And thank you to @DHowett for following me here and helping clarify things! I am pumped to see this fixed in the next release.

[gdamore]

FYI, as of yesterday, we use VTE by default on Windows, except for ConEmu (which is too busted when in VTE mode.)

Honestly at this point I cannot recommend ConEmu on Windows ... the main benefit it provided is gone now that we have a good Windows Terminal. (Also there are other options, like Alacritty, which are also good.)

If for some reason you wanted to change the default, you could put TCELL_VTMODE=[enable,disable] in your environment (pick either enable or disable). This will change the "default" behavior. (We still fall back to legacy console mode if the console doesn't support the VtOutput mode.)