Screen corruption with neovim

[theseanl]

Screenshot with mosh

Screenshot with ssh

I’m running mosh server built from master on Amazon Linux AMI. For a client, I’ve used iOS apps “blink” and “termius”. I can reproduce above results stably on both of the clients — note that how the start of a 3rd wrapped line is dedented.
Maybe it is a bug of my configuration, if so any help on the configuration would be appreciated.

[theseanl]

SCRIPTFILE.txt
Here is a script output recorded while reproducing the issue. Any pointer to debug would be greatly appreciated.

[djsavvy]

I’ve also been having similar screen corruption issues in neovim. At this point I’ve spent a couple of hours cumulatively trying to fix this, and I finally have a (hackish) workaround.

On my server’s .zshrc, I have the following line:

alias vim="TERM=st nvim" 

When using st for the value of $TERM, Neovim doesn’t mess up the indentation of soft-wrapped lines.

Despite this workaround, I’d really prefer if mosh natively solved this.

[dwoodwor-intel]

I've also been having this problem, but TERM=st (and TERM=xterm-basic) did not fix it for me. TERM=ansi did fix it, but was missing a few features that I use like 256-color support. I compared the ansi and xterm-basic terminfo and narrowed down the differences until I found the part that causes the neovim screen corruption: character set control sequences in sgr (%?%p9%t\E(0%e\E(B%;). I was able to make a new mosh profile as a workaround by removing these sequences and it seems to be working for me:

$ cat mosh.ti
mosh|less buggy mosh profile with character set control sequences removed from sgr,
        sgr=\E[0%?%p6%t;1%;%?%p5%t;2%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m,
        use=xterm-256color,
$ tic mosh.ti
$ TERM=mosh nvim

It would be nice if mosh was able to handle these sequences more gracefully if it's going to set TERM=xterm though.

[keithw]

Mosh supports C1 controls, but is locked to Unicode only -- it doesn't support ISO 2022 charset-switching sequences on purpose. (See #1127 (comment) for a longer rationale.) neovim should be using Unicode (ISO 10646) characters when the terminal charset is Unicode and NCURSES_NO_UTF8_ACS is set, rather than ISO 2022 locking shifts into an alternate charset.

[yyb196]

@keithw thanks for your explanation, but how can I found out which char/icon in my neovim config file or in my neovim plugin file incur this corruption.

[julienmarie]

So this means it wont get fixed ? Neovim is one of the most important terminal programs out there.

[ProducerMatt]

Just to show how nasty this corruption can get. Scenarios like this render it basically unusable. https://youtu.be/4ySMoZWfEgM

[bergheim]

I get the same kind of corruption @ProducerMatt. Both vim and emacs.

[hexacera]

This issue disappears when I disable lualine.nvim, and consistently reproduces when I re-enable lualine. Maybe some characters or escape sequences from lualine has been causing the issue?

Can the other commenters share whether you are using lualine (or some other *line plugins)?

Found a related issue in the lualine repo: Bug: when running mosh with neovim and lualine, terminal is broken #1199

[dwoodwor-intel]

I wasn't using a *line plugin back when I was using mosh and encountered this issue, so the problem isn't specific to those

[meinside]

I apologize for resurrecting this old issue and adding a seemingly unhelpful '+1', but I'm glad to know I'm not alone in experiencing this problem.

For years, I've been plagued by randomly broken characters in neovim, but I had no idea what was the cause, so it became a 'normal' part of my neovim experience. And today, just before finding this issue, I discovered that the problem only occurs with mosh connections, not with ssh connections or local terminals.

While I can work via ssh or locally for now, I'd be really happy it if it could be resolved.