You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 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.
@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.
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.
sway version 1.0
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.pngThat 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.pngWith 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.
The text was updated successfully, but these errors were encountered: