Mosh, tmux, nvim rendering/redrawing issues

[markolonius]

When using mosh, tmux, nvim there are rendering issues that appear when switching tmux windows as seen in this video

This does not happen with ssh. Seems to happen when using a linter or similar with nvim LSP that draws floating windows possibly? (such as when I install python-lsp-ruff or python-lsp-black). I tried looking at similar issues however they are all years old and seem to have been issues fixed in subsequent releases. Not sure if it is a tmux issue or mosh issue, however posting here since it only happens when using mosh. I've tried plain default tmux confit and issue still persists. I've attached my current tmux config.

Using iTerm2 latest. mosh 1.4.0 tmux 3.2a TERM outside of tmux is xterm-256color, inside tmux both xterm-256color and tmux-256color give same rendering issue LANG=en_US.UTF-8 is set everywhere this is all in a docker container

[xyproto]

I have a similar issue when using the Orbiton editor.

One way of reproducing the issue (requires git, make and go 1.20 or later on the server):

mosh --ssh 'ssh -p22 -C' user@somewhere.com # use a valid port, username and hostname
git clone https://github.com/xyproto/orbiton
cd orbiton
make
./o README.md

This does not draw the text of the README.md file on the screen in the same way as it does over just ssh or locally.

Pressingctrl-l, return, ctrl-l and return again redraws the text.

• TERM is set to xterm-256color both locally and on the (Arch Linux) server.
• LANG is set to nb_NO.UTF-8 on the server.
• The terminal emulator I am using right now is iTerm2.

[jay-ouellette]

I have this issue as well. Mosh is not redrawing the screen correctly after switching tmux sessions that are running nvim. When I use ssh instead of mosh and attach to the same tmux server, there are no drawing issue when switching tmux sessions.

MacOS 13.5.2 Alacritty 0.11.0 Mosh 1.4.0

Connected to

MacOS 13.4.1 via ethernet (on same switch) Tmux 3.3a Nvim v0.8.3

[julienmarie]

Same issue.

[vamsee007]

I have the same issue with Mosh + Tmux + NeoVim

The primary concern is Mosh doesn't support some hieroglyphs and Nerd Fonts, due to which the redrawing/scrolling leaves some garbage characters on the screen..

Try disabling the Dev Icons or any Nerd Font based icons in your Neovim config, this helped me to avoid those glitches

However, SSH + Tmux + Neovim works fine as the character rendering is supported.

For more info https://github.com/mobile-shell/mosh/issues/1041

[gilbertfrancois]

I can confirm this issue. Using mosh, tmux and nvim messes up the screen. When using ssh instead of mosh, the problem does not occur.

Ubuntu 22.04, mosh 1.4.0, tmux 3.3a, nvim 0.9.5

[kftang]

I have the same issue as well.

Using CentOS 7.9, mosh 1.4.0, tmux 3.3a, nvim 0.9.5

[mellery451]

same issue iterm2 --> mosh --> tmux 3.4 --> neovim 0.10 ..and the panes become unusable after just a few minutes with visual artifacts left all over the place. remove mosh from the chain (replace with ssh) and it's all good.

[iveney]

same - using Mosh it messed up the tmux pane. Even if not using mosh, using nvim will cause my whole screen to be green...

switching to ssh does not have this problem.

nvim: 0.10.0 Host OS: Linux n2 6.1.0-21-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.90-1 (2024-05-03) x86_64 GNU/Linux Local OS: macOS Sonoma 14.5 Terminal: iTerm 3.5.0

[OceanXS]

same issue -when using helix editor

[Drag0nFly]

Seeing this as well–

iTerm2 3.5.0 -> mosh 1.4.0 -> -> fish 3.7.1 -> alpine 2.26

Any time an email with a high-ascii or emoji is displayed, rendering is messed up. Also seeing a similar behaviour in the shell when escaping characters (i.e, mv long filename with spaces and adding \ in front of space, paranthesis, etc.) which causes the characters in the command line to be misplaced (display is not "in sync" with the actual commandline). This also occurs with MATE Terminal on Linux, so not iTerm2 specfic.

Really hoping this can be fixed, as it is quite a nuisance when one relies on mosh for remote sessions.

[keithw]

As has been explained in several other issues, Mosh just uses the libc wcwidth API to know the width of each character. At least until/unless Mosh decides to vendor this itself, you'll have to take this up with your libc vendors. (Apple unfortunately is pretty bad at keeping their Unicode support in macOS up-to-date, but if you're an Apple customer, better for them to hear it from you than from a third-party piece of software that just uses their API.)

[Drag0nFly]

Ok, thanks for the quick reply. It's also an issue with Linux/glibc unfortunately, so not Apple specific. It was just what I tested with from work.

[xyproto]

@keithw What is indicating that this is a width-related issue? Orbiton (a small text editor I made) has issues in connection with redrawing when running under mosh, and the problem can temporarily go away after refreshing/redrawing several times.