Opening new buffer behaviour change?

[pauldthomson]

Describe the bug Using vim-go, sometime between Vim versions 8.1.0500 and 8.1.0600, :GoDef functionality broke. I know this is a plugin and not necessarily a Vim thing, but I pinned down the change to jumping between those versions of Vim.

The command above is used to jump to the definition of a symbol in a Go file. If the definition is in another file, the file is opened in a new buffer and that buffer is switched to.

The problem I started seeing is that only when jumping to the definition requires opening a new buffer, the new buffer is opened but Vim hangs and doesn't jump to it. If I hit ctrl+c then it jumps to the newly opened file. If the file was already open in another buffer, then everything works as expected. So this only happens when a file is being newly opened in a new buffer.

I guess I'm wondering if anything rings a bell to anyone about anything that may have changed in Vim between 8.1.0500 and 8.1.0600 around the behaviour of opening files in buffers?

To Reproduce

1. Install vim-go
2. Clone this repo: https://github.com/schemahero/schemahero
3. Open this file at this line
4. Run :GoInstallBinaries (sorry, I know this might require some Go setup)
5. On the line referenced above, move the cursor over r.getPlanPod()
6. Run :GoDef

Expected behavior The file containing the definition is loaded in a new buffer, and vim jumps to the definition in that file

Environment (please complete the following information):

• Vim version: 8.1.0600
• OS: macOS 10.14.6
• Terminal: iTerm2

[pauldthomson]

I noticed the same behaviour in a Java project using coc.nvim and coc-java.

It's always when Vim's gd command will have to open another file in a new buffer. Buffer is opened but not jumped to.

[chrisbra]

can someone bisect the offending commit?

[lacygoill]

I can't reproduce. I followed the instructions given in the OP, and with this minimal vimrc:

set rtp-=~/.vim
set rtp-=~/.vim/after
set rtp^=$HOME/Vcs/vim/runtime
set rtp^=/run/user/1000/tmp/vim-go
filetype plugin on

It takes a few seconds for :GoDef to jump to the definition, but Vim doesn't hang; be it on 8.1.0500, 8.1.0600 or master:

Something else must be necessary to reproduce the issue.

[pauldthomson]

Ok through deleting plugins one by one the offender seems to be vim-gitgutter, although not really sure how yet...

[chrisbra]

Ping @airblade

Am 02.05.2020 um 09:04 schrieb Paul Thomson notifications@github.com:

 Ok through deleting plugins one by one the offender seems to be vim-gitgutter.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[airblade]

I tried to follow the repro steps but had some kind of problem installing the Go dependencies.

I scanned through the git log for the commit range you gave but nothing jumped out at me. If you were able to bisect the offending commit, that would really help.

Also, what commit is your copy of vim-gitgutter at?

When you enter a new buffer, vim-gitgutter (a) sets up some maps; (b) asynchronously figures out the file's path relative to the repo root; then (c) asynchronously runs a diff. If the buffer already exists, only (c) happens.

Another approach to debugging this would be to profile what's happening. Hopefully that would indicate where things are getting held up.

[pauldthomson]

vim-plug.log Attached the profile log. I'm no expert in reading this but gitgutter#diff#run_diff() seems to be the culprit. Here's a second example where I let it sit for longer before hitting ctrl-c: vim-plug-2.log

There seems to be a while loop that calls gitgutter#utility#repo_path and that looks like it was called 1163 and 2781 in the first 2 examples respectively, with gitgutter#utility#getbufvar() right behind it.

Here's an example from when the target file was already loaded in a buffer: vim-plug-3.log

Also, what commit is your copy of vim-gitgutter at? Current HEAD of master, b356cc9

So I had all that ^ written up and decided to do one more remove/reinstall of the plugin, and now it works 🤦

I'm gonna leave the profile logs here so I don't look crazy 😛 , but I guess sorry for wasting your time (orrrr, hooray, nothing to fix?)

[chrisbra]

so now it works?

[LyleZiegelmiller]

“so now it works?” Yes.

As per my last comment: Is anyone relying on the editor lurching into a random location and size on the screen simply because the user both:

1. Snapped the editor to the right-hand side of the screen with Windows Key + right arrow
2. Split the editor pane vertically ?

I will say no more about it. 😊

Lyle

From: Christian Brabandt notifications@github.com Sent: Monday, May 04, 2020 10:40 PM To: vim/vim vim@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [vim/vim] Opening new buffer behaviour change? (#6008)

so now it works?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fvim%2Fvim%2Fissues%2F6008%23issuecomment-623865448&data=02%7C01%7C%7Cb5ff23ed8e8c49076a0208d7f0b6ba47%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637242539900011730&sdata=1eBT6kbqmYFmnywcY9XoTntCZ%2BbE4epidt3J%2FfPDnco%3D&reserved=0, or unsubscribehttps://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACHJRXZYUFA7SQITJATYGSLRP6RCLANCNFSM4MTNBGPA&data=02%7C01%7C%7Cb5ff23ed8e8c49076a0208d7f0b6ba47%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637242539900011730&sdata=YI5xhy35WX1k6VmwQ8ywL2QM7aINeWf3aF2BHmHDyFg%3D&reserved=0.

[pauldthomson]

so now it works?

Yep. Not sure why now, I had removed/re-added the plugin several times to confirm it was the culprit and on 2 machines and it was reproducible. But the last one sorted it.

Will close the issue. Thanks and sorry!