[vim/vim] Opening new buffer behaviour change? (#6008)

[Paul Thomson]

Instructions: Replace the template text and remove irrelevant text (including this line)

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
Detailed steps to reproduce the behavior:

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

Screenshots

Environment (please complete the following information):

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

Additional context
Add any other context about the problem here.

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

[Paul Thomson]

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.

[Christian Brabandt]

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^=/usr/local/share/vim/vim82
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 or on 8.1.0600:

Something else must be necessary to reproduce the issue.

[Paul Thomson]

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

[Christian Brabandt]

Ping @airblade

> Am 02.05.2020 um 09:04 schrieb Paul Thomson <notifi...@github.com>:
>
> 

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

> You are receiving this because you commented.

[Andy Stewart]

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?

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

[Paul Thomson]

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?)

[Christian Brabandt]

so now it works?

[lylez00]

“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 <notifi...@github.com>
Sent: Monday, May 04, 2020 10:40 PM
To: vim/vim <v...@noreply.github.com>
Cc: Subscribed <subsc...@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 GitHub<https://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 unsubscribe<https://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>.

[Paul Thomson]

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!

[Paul Thomson]

Closed #6008.