Open theseanl opened 5 years ago
SCRIPTFILE.txt
Here is a script
output recorded while reproducing the issue. Any pointer to debug would be greatly appreciated.
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.
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.
Mosh supports C1 controls, but is locked to Unicode only -- it doesn't support ISO 2022 charset-switching sequences on purpose. (See https://github.com/mobile-shell/mosh/issues/1127#issuecomment-767296122 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.
@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.
So this means it wont get fixed ? Neovim is one of the most important terminal programs out there.
Just to show how nasty this corruption can get. Scenarios like this render it basically unusable. https://youtu.be/4ySMoZWfEgM
I get the same kind of corruption @ProducerMatt. Both vim and emacs.
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
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
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.
Screenshot with mosh
![61B30CA7-3ECE-4109-9DF5-8D4EE80107A9](https://user-images.githubusercontent.com/22858651/58320458-a27e8a80-7e56-11e9-8bc8-c59887240a5c.png)Screenshot with ssh
![5F6707CB-D192-436D-8711-A800515ED0E4](https://user-images.githubusercontent.com/22858651/58320460-a27e8a80-7e56-11e9-9841-b0648c964f26.png)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.