Running (neo)vim directly in a terminal emulator gives "geometry problems" sometimes...

[camoz]

• Sway version: sway version 1.0
• Tested on: Thinkpad X200, Samsung Chromebook Plus
• Default config for termite, sakura, xterm
• Default config for neovim
• Config for vim: Only set number in ~/.vimrc

Sorry for the fuzzy title and description, I have trouble reproducing this reliably and also don't know exactly which components are at fault.

When I run termite -e 'vim /tmp/somefile.txt, I get in about 5 of 10 cases this (initial view): https://linx.li/vegwycqu.png
That is, line numbers don't start at 1 but at 5. Also, I can put my cursor in line 6 in the screenshot and then go 58 characters to the right (like if I were on line 2 of the file, which contains 58 characters). Running :redraw or :redraw! doesn't fix this. Running some vim commands like :ls fixes the top of the buffer, but not the bottom: https://linx.li/28omlm0u.png
With sakura (sakura -e /tmp/somefile.txt) that happens in almost 10 of 10 cases.
With xterm (xterm -x /tmp/somefile.txt) it happens in about 2 of 10 cases.

I experience something similar with neovim. Sometimes it works fine: https://linx.li/u28nam51.png
But sometimes I get this: https://linx.li/dswyusk8.png

Setting the window to floating mode immediately fixes the broken display of the file: https://linx.li/eb2sf5ge.png
Same goes for neovim.

Running (neo)vim from an open shell ($ vim /tmp/somefile.txt) works fine.

What I found useful for testing this:
for i in $(seq 20); do termite -e 'vim /tmp/somefile.txt'; done

Removing set number from ~/.vimrc fixes the issue for vim, but not for neovim.

How can I tell if this is a sway issue?
Unfortunately, for now I'm not able to test with different compositors / WMs under X11.

[RedSoxFan]

I can replicate this almost consistently with termite -e "vim $HOME/.vimrc -u /dev/null --cmd 'set number'". It doesn't seem to matter whether it is xwayland or xdg-shell and also appears to have the same behavior in other terminals. The behavior does not occur in i3 or rootston so it seems to be sway specific.

If you look at a wayland debug log, the area before the gap is the size of the first commit. I think this may be a damaging issue, but haven't been able to get any changes to have any effect.

Screenshot

[nnnn20430]

@RedSoxFan I can replicate that only on VTE based terminals like termite and terminator.
Does not replicate on xterm (x11) or konsole (wayland) for me.

[kchibisov]

@RedSoxFan

This is not a sway bug, the bug is in vim/neovim, since they can't handle multiple resizes on startup properly. While testing this bug in alacritty, we've noticed that lots of Wayland native terminals have additional resizes during startup on sway(we didn't test anything else besides it though), which can lead in broken neovim/vim in some cases. So I guess sway can't do anything about it, since clients(terminals) should either wait for window to be mapped or "start with a proper size"?

The known way to work around this issue is to use specials flags (e.g. -wf in xterm) or launch vim with a bit of delay like this alacritty -e bash -c "sleep 0.1 && nvim". Though the faster your vim/neovim starts the better.

However the issue should be fixed in vim/neovim.

Anyway if you still feel like its a sway issue, the problem is in multiple resizes on startup in some clients.

For more info:
neovim (the issue about this behavior in neovim): neovim/neovim#11330
alacritty: alacritty/alacritty#2817

[emersion]

Possibly related: #2176