neovim errors when using mintty

[rex-ludorum]

I've run into some bugs when using neovim on mintty (msys2 on Windows 10). The first is that my terminal is "cleared" after running and exiting neovim:

The previous terminal commands are erased and the prompt starts on the next line after them. In contrast, vim and other full-screen CLI apps work as expected after exiting and don't clear my terminal output. This behavior is also the same on my Windows 11 machine.

Another bug is that I enabled underlining in neovim, but it only underlines the portion of the line with text, rather than the whole line.

However, this only occurs on my Windows 10 machine. On my Windows 11 machine with the same setup, the underline works as expected.

[mintty]

Is that a cygwin build or a native version of neovim? Sounds like some interference with ConPTY support for native Windows applications, which got reportedly improved in Windows 11.

[Biswa96]

Could you provide exact steps to reproduce the issue? Please explain it like teaching a toddler 👶

Also, does this issue happen with Windows Terminal? It is possible to use msys2/mingw-w64 environment in Windows Terminal using the steps from here https://www.msys2.org/docs/terminals/

[rex-ludorum]

@mintty I think it's a native version of neovim given that I installed it on msys2. @Biswa96 I ran neovim on msys2 in Windows Terminal, and neither of the issues happen there. It seems like mintty is the only culprit so far.

To reproduce these issues, first install msys2 if you don't have it already via the instructions here: https://www.msys2.org/
Then, run the msys2 under the UCRT64 environment (this is the one that I used to get the errors, but you can try the other environments as well). If you don't have neovim, install it via pacman -S mingw-w64-ucrt-x86_64-neovim in the shell. If you are using a different environment from UCRT64, the corresponding neovim version can be found in this list: https://packages.msys2.org/base/mingw-w64-neovim (note that only CLANG64 and MINGW64 are supported aside from UCRT64 currently). Msys2 uses mintty by default, so we don't need to worry about that. Now that we have neovim, we can try reproducing the clearing bug. Press <Enter> a few times in the terminal. Start neovim with nvim and then exit with :q. The blank commands you created with <Enter> should have disappeared. To reproduce the underlining bug, create a .vimrc file in your current directory with the following contents:

set cursorline
hi clear CursorLine
hi CursorLine cterm=underline

Run neovim with this configuration via MYVIMRC=.vimrc nvim VIMINIT='source .vimrc' nvim. Type out some characters in the line and only the part of the line with text should be highlighted, rather than the entire line in the terminal.

[mintty]

I get no underlining at all. Maybe there's some plugin missing?

[mintty]

Also nvim does not show line numbers, nor the vertical shadow line, nor blue background in the bottom line.
Maybe it's a different version? What does type nvim say for you?

[rex-ludorum]

Sorry about the confusion. Those screenshots were made using my full neovim configuration. When I use the minimal configuration supplied above, this is what it looks like:

I get underlining sporadically and in strange places. Moreover, when I scroll up, I rarely get underlining at all (in my c file, it happened generally on #include directives and comments).

type nvim gives nvim is /ucrt64/bin/nvim for me, and nvim --version gives

NVIM v0.9.4
Build type: Release
LuaJIT 2.1.1696795921

   system vimrc file: "$VIM\sysinit.vim"
  fall-back for $VIM: "/ucrt64/share/nvim"

Run :checkhealth for more info

Keep in mind that neovim does have some filetype-specific plugins in /ucrt64/share/nvim/runtime/ftplugin/, but the c.vim plugin doesn't appear to have any underlining related settings, nor do most of them to my knowledge. Disabling them does not fix the underlining behavior for me.

[mintty]

Update nvim from 0.9.2 to 0.9.4 - no underlining here.
Maybe a glitch caused by your specific file contents? Please upload it here.

[rex-ludorum]

client-c.txt
Note that I renamed the extension to .txt in order to send it. Make sure to rename it to .c in case that changes any formatting.

[mintty]

Still no underline. Also still a mismatch of configuration as I don't see line numbers and indentation is 8 unlike in your screenshot. So maybe there's some configuration to be aligned for a complete retest scenario.
Also you could try to minimize or modify your configuration environment to boil down the issue. Does it only occur in the UCRT64 deployment?

[rex-ludorum]

Sorry, I think I missed another environment variable when trying to set up the example. Try
MYVIMRC=.vimrc VIMINIT='source $MYVIMRC' nvim

Compare your results to my later screenshot in the follow-up comment, which also has 8-space indentations and no line numbers.

I tried it in the MINGW64 environment, and I still get the underlining errors.

[mintty]

Or simply VIMINIT="source .vimrfc" ..., anyway:
Yes, I see for example a line " }" being underlined completely, which I assume you don't expect.
Using the mintty log feature I extracted the control sequences emitted by nvim. These are quite unusual and weird, so a precise analysis would need a moment, but I can say already that the same rendering is seen in xterm, so it's most likely not a mintty issue.

[mintty]

I've extracted a significant part of terminal output from the log. Controls are not as weird as I thought, but nvim sets underline mode at the end of a line, then proceeds with the next line, indenting spaces and a brace, as can be seen in the attached log (output with cat to check), and its diagnostic display with cat -v below.
Maybe nvim thinks the terminal would not underline spaces? Or whatever, it's an nvim bug, please report there.
nvim-underline-glitch.log.txt

^[[4;8H^[[40X^[[93m^[[40Creturn^[[m ^[[95m1^[[m;^[[K^[[4m^M
                                }^[[K^[[24m^M
                                temp_buf += bytes_sent;^[[K^M
                                bytes_send_remaining -= bytes_sent;^[[K^M
                        }^[[K^M
                }^[[K^M
                close(sockfd);^[[K^M
        }^[[K^M
^[[K^M
        ^[[93mreturn^[[m ^[[95m0^[[m;^[[K^M
}^[[K^M

[rex-ludorum]

Just for my understanding, what makes Windows Terminal and cmd different from mintty/xterm in this case? I haven't tried xterm, but out of the remaining three, mintty was the only one to have this bug. This was the reason I thought it would be a bug on mintty's end. In fact, I actually did create an issue (neovim/neovim#25609) in the neovim repo before this, but it was closed and they directed me here.

Aside from the underlining bug, what about the terminal clearing bug? Were you able to reproduce that?

[mintty]

About underlining, I seem to have misinterpreted the issue; I was not aware that the current cursor line is supposed to get underlined completely. So let's take a fresh look:

Case 1: moving the cursor down, only one word (e.g. "while") is underlined. Output looks like this.

^[[4m^M
^[[16X^[[93m^[[16Cwhile^[[m (bytes_read > ^[[95m0^[[m) {^[[K^[[24m^M

• Observation 1a: Apparently nvim assume the underline attribute set in the previous line to apply to character positions (the indentation white space) erased with CSI X (the ECH control) - but that assumption is wrong. However confusing, the terminfo manual page claims it would act like outputting space characters but yet this is wrong, checked by the original DEC terminal manuals. Terminal capability bce is described to carry on colours to the erased characters but the underline attribute is not a colour.
• Observation 1b: After the "while" there is an SGR 0 sequence which clears all attributes. As there is an explicit clear underline sequence (SGR 24) at the end of the line, nvim seems to assume that underline attribute would still persist but this is wrong.

Case 2: move cursor up

^[[4m^[[m^[[11;1H                }^[[K^[[24m^M

Observation: the whole line is embedded in SGR 4 (underline) and SGR 24 (clear underline) which seems to be nvim's assumption for the line, but right after the SGR 4 all attributes are already cleared again with SGR 0.

Case 3: exit nvim
Observation: nvim sends a cursor home sequence (CSI H) and the a bunch of clear to end-of-line (CSI K) and newline explicitly, so it clears the screen deliberately.

[Fishervjacob]

Aside from the underlining bug, what about the terminal clearing bug? Were you able to reproduce that?

I have this same bug! We're not alone in this crazy world anymore 😭

Additionally, I have issues using CTRL-i, CTRL-o in neovim.
Have you seen any issues using these commands? I suspect they are related to the clearing terminal bug.
The issues there, if clicking CTRL-i, CTRL-o, ...., the first and second time the files don't properly render and show the previous file and current file at the same time, but the third and fourth render properly, and then it cycles through that.

Steps to reproduce the Terminal Clearing bug and the CTLR-i, CTRL-o bug:

Have Windows 10
Install NeoVim_v0.9.5 w/ the msi installer.
Install Cygwin with only non-default option selected being Vim (using MinTTy when trying to reproduce bug).

[mintty]

Please provide a new and precise description.
Maybe it's not quite the same or a fresh description sheds more light on the issue. I had demonstrated above that the original issue is not a mintty bug.

[Fishervjacob]

Let's focus on the "Terminal Clearing" right now and perhaps discuss the "Ctrl-i/Ctrl-o" issue later since the former is what was originally discussed in the issue.

I'm sorry too if your answer above explains this behavior but I would like to understand more about what is going on.

Better description of "Terminal Clearing":
In Mintty (from Cygwin), if the terminal has some history, after opening/closing nvim, that history will be erased but the prompt will be in the correct position as if the history were there:

This behavior is not seen in CMD or Powershell:

Does your description above talk about this issue here?

Case 3: exit nvim
Observation: nvim sends a cursor home sequence (CSI H) and the a bunch of clear to end-of-line (CSI K) and newline explicitly, so it clears the screen deliberately.

If so then I'm curious, why does the "(CSI H)" and "(CSI K)" that nvim sends not clear the terminal for CMD/Powershell but does clear Mintty?
Is there a configuration to stop it from clearing Mintty?

[mintty]

Please do the following:
Start mintty -l log.txt to log output to a fresh logfile.
Run stuff, then sleep 2; nvim; echo after nvim; sleep 2 and observe: When is the screen cleared? Right after nvim (echo) or after the sleep? Or even before nvim?
Then exit mintty and upload the logfile here.

[Fishervjacob]

Here is the log.txt generated.
It appears that the history is cleared right after nvim exits. Between steps nvim; and echo after nvim;.
It could be that it is cleared before nvim enters but that's very hard to see since nvim takes up the whole terminal when it opens.

log.txt

[mintty]

The screen is cleared by a screenful of clear-to-end-of-line sequences (ESC[K). I assume your vim version is a Windows build, so it uses the Windows console API, which is transformed into ANSI sequences by the ConPTY layer. That layer is not involved if you run native Windows applications in native Windows console terminals. Also it is reported to be buggy in Windows 10.
There is advice to replace it with a newer version: https://github.com//issues/971#issuecomment-1807165683
Another solution would be to run a cygwin build of vim of course.

[cdecompilador]

I'm only suffering from the ctrl-i ctrl-o issue on both windows 10 and windows 11, did you find a solution to this @Fishervjacob?

[Fishervjacob]

I'm only suffering from the ctrl-i ctrl-o issue on both windows 10 and windows 11, did you find a solution to this @Fishervjacob?

I did but my solution was switching to Alacritty. I was not able to find a solution within mintty :(

[mintty]

Please run mintty -P on just to check (ConPTY is enabled by newer versions of MSYS2 but not on older versions or you might have disabled it).
Also, as I suggested before, an MSYS-built vim version will help as a solution.

[avvo-na]

About underlining, I seem to have misinterpreted the issue; I was not aware that the current cursor line is supposed to get underlined completely. So let's take a fresh look:

Just dropping in to say I also have this bug. Unfortunately there is no Cygwin package for neovim, and I'm not daring enough to try to get that built as Windows is not my forte. If anyone reads this and is interested in building neovim for Cygwin/MSYS look here for some more info. However those binaries are over 5 years old :/