Vim openes files distorted when launchd from a keybinding

[sprnza]

➜  ~ awesome --version 
awesome v4.2-225-g31b8623f (Human after all)
 • Compiled against Lua 5.3.4 (running with Lua 5.3)
 • D-Bus support: ✔
 • execinfo support: ✔
 • xcb-randr version: 1.5
 • LGI version: 0.9.2

How to reproduce

1. Set up a keybinding to open a text file:

    awful.key({ "Mod1", "Control" }, "e",     function () awful.spawn("st vim /path/to/a/file/test")          end,
             {description = "Launch vim", group = "custom"}),

2. Fire the keybinding
3. See the file being distorted. Screenshots one two (left client is opened by the keybinding, right one is opened using the same command from a terminal)
4. The file is being fixed once the client is being resized (using float + mouse or by another client opened)

[psychon]

Perhaps I am missing the obvious, but what is the distortion? The only (obvious) difference that I see is that the scroll positions are different.

Could you try running AwesomeWM with --no-argb and see if that fixes this?

[sprnza]

Each screenshot is displaying the same issue with different scroll position. See left client on screenshot one - there are plenty of lines missing, right client displays the same file just fine. On the second screenshot the same, but with 33% scroll added. Sorry for not making the description straight.

[sprnza]

--no-argb doesn't fix. I've checked I get the same issue with the default rc.lua, btw.

[sprnza]

Oops, it's my vimrc issue. Sorry.

[actionless]

and what was the issue may i ask?

[sprnza]

I've conducted a bunch of tests and found out that awesomewm causes vim to misbehave. If I enable filetype plugin on OR syntax on the issue accures every single time. I think it's still awesomewm-related.

[psychon]

Well, okay... then another round of random guesses: Are you ignoring size hints in your config (setting size_hints_honor to false)? Does the problem also appear when size hints are not ignored? Does this also happen with the default config? (Well, with your keybinding added)

[psychon]

Oh and: Does adding a sleep 100m to .vimrc make a difference? I am asking because of:

If I enable filetype plugin on OR syntax on the issue accures every single time

I guess that enabling this makes vim startup a little bit slower and that this makes a difference here. Hence the question if emulating this "slowness" with a sleep has the same effect.

[sprnza]

I don't use size_hints_honor and yes, this also happen with the default config but less frequent though.

[sprnza]

Nope sleep 100m doesn't make any difference. Even 5000m doesn't fix the issue.

[sprnza]

Hence the question if emulating this "slowness" with a sleep has the same effect.

sorry, just read your comment carefully. Yes adding the delay causes the same issue when the command is run from terminal.

Upd: nope, actually the issue happens even I run the command just from a terminal without sleep 100m added. So it's clearly non-awesomewm-related.

[psychon]

So it's clearly non-awesomewm-related.

Well, how you spawn the program should not make much of a difference. The only theory that I have so far is that awesome resizes the terminal shortly after it makes it window visible and that this confuses either vim or st. Somehow. Non-tiling WMs most likely do not do any resizing on their own, so this kind of problem might "lay dormant" for a long time before anyone notices it. Oh, which reminds me: Trying out a different terminal emulator could also help. However, even if that makes the problem go away, this does not really tell us if the bug is in vim or st. Races are just annoying to debug.

However, so far I have no idea how to really debug this and I am just hoping to randomly figure out some of the "ingredients" of this problem.

[sprnza]

Thanks for the reply! I've already tried urxvt and xterm and the issue is there.

[sprnza]

Actually I never get the issue reproduced if I have floating mode enabled. Plus when I launch vim in tiling mode I do see its status line appears in the middle of the window.

[sprnza]

Here a gif describing what I'm talking about -> https://goo.gl/iBHTRC

[sprnza]

This screenshot kinda proves that vim is being confused because of AwesomeWM changes window size while it's busy launching. Underlying window contains the same file and its content height is limited to the window was opened in float mode.

[sprnza]

To workaround I launch vim delayed using this script:

#!/bin/bash
case $1 in
vim)
    sleep 0.1
    shift
    vim $@
;;
esac

[psychon]

Underlying window contains the same file and its content height is limited to the window was opened in float mode.

So the file has actually more lines than what is shown here? By the way, what is your vim version (perhaps this matters?)?

(Why the case in that script? But whatever...)

I can resize urxvt with resize -s 20 20.

• Does this work with st?
• Does resize -s 20 20 ; vim [whatever] reproduce this problem in a floating terminal?
• Does resize -s 20 20 ; vim [whatever] reproduce this problem in a non-floating terminal?

(In the first case: I guess the resize is already done by the time vim starts, so I would not expect this to reproduce the problem. In the second case: I would expect that awesome "quickly" resizes the terminal back to its previous size, so this might reproduce this)

[sprnza]

➜  ~ vim --version
VIM - Vi IMproved 8.1

case because it's just a snippet of a bigger script.

Actually I've written "st vim..." in the first post just to show that I've tried several terminal emulators without any luck, but I've forgotten to mention it. I use urxvt and everything I wrote above is true for st, xterm and urxvt.

Sorry, I did not get the tests you've requested, could you please elaborate? You don't want me to just start these commands from a terminal? Or what?

[psychon]

Uhm. I just ran urxvt -e vim /etc/fstab in a terminal: So, I guess I can reproduce this problem.... I also tested what I suggested above and it does not reproduce the problem.

Now, I just need an idea on how to reproduce without using awesome so that one can report the bug to vim.

[Veratil]

I've attempted to reproduce and I cannot. I've changed my .vimrc from syntax enable to syntax on even (though they aren't different afaict), and tried adding the filetype plugin on.

I've tried launching from:

• keybind
• run prompt
• terminal

awesome v4.2-322-g08f92af9 (Human after all)
 • Compiled against Lua 5.3.4 (running with Lua 5.3)
 • D-Bus support: ✔
 • execinfo support: ✔
 • xcb-randr version: 1.5
 • LGI version: 0.9.1

Also I'm using xterm and vim v8.0 (on Fedora 26).

If this is a problem with vim then it's between v8 and v8.1 most likely.

[sprnza]

@Veratil Could you try to do a several attemtps in a row (10-20)? Sometimes it doesn't occur for some reason.

[Veratil]

@sprnza I've held down my keybind to just spawn as many as I can within a two-three second period, it doesn't happen on my end. :slightly_frowning_face:

[blueyed]

I guess :redraw! fixes it always?

Something you might want to try in vimrc (as a workaround and to see if it helps):

au VimEnter * redraw!

btw: with the Vim version the patch level is also relevant (i.e. the X after 8.1, see :version).

Does it also happen with Neovim?

[elenapan]

I am also affected by this. Using Termite and Neovim. It happens when I execute a command that opens up a new terminal window to edit something in vim. termite --exec "vim <some file>"

Manually doing a :redraw! or using au VimEnter * redraw! does not change anything. While removing filetype plugin on decreased the frequency of this happening on most files, I could still reproduce it 99% on the file init.vim (Neovim's .vimrc) when the plugin YouCompleteMe was loaded and Awesome's layout was either tiled or maximized.

I could not reproduce it on i3 (only tested with Xephyr though). I could not reproduce it with st on Awesome.

Resizing the terminal window in any way fixes it for the current vim instance. It looks like Vim or the terminal gets the wrong window size on startup. And by "wrong" I mean the size it would get if the client/layout was floating.

However, I have switched to deoplete for auto complete and ever since everything seems to work fine.

[ofekluis]

Just wanted to confirm that I had the same problem usually when executing vim directly with the terminal using "urxvt -e vim" in awesomewm (happened also with termite), and making a private command with sleep 0.1 before launching vim, fixes it! So thanks for that workaround =) It is surely related to the initial resizing of the window in awesomewm and probably other tiling wm, since if you let the window resize i.e. minimize other open windows so it could take up more space for example the rendering fixes itself due to the second resize. "au VimEnter * redraw!" Does not seem to work however.

[sim590]

I have this issue with vim and making a script with sleep 0.1 before executing vim works around.

[actionless]

i've started having this issue recently (last few days/weeks), i guess after the latest vim update

[marcusGH]

I also got this problem with the vim version:

VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Sep 23 2020 12:06:05)
Included patches: 1-1728

and Gnome terminal version:

# GNOME Terminal 3.28.2 using VTE 0.52.2 +GNUTLS -PCRE2

Making a script with sleep 0.1 also fixed the problem for me.

I used the following delayLaunch.sh bash script:

#!/usr/bin/env bash
sleep 0.1
$*

and changed my editor in rc.lua to "/path/to/delayLaunch.sh vim ". This allowed me to make hotkeys like editor_cmd .. " /path/to/rc.lua" without experiencing the above bug.