Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Independent stacks for each vim window when using GoDef #1431

Open
font opened this issue Sep 7, 2017 · 7 comments
Open

Independent stacks for each vim window when using GoDef #1431

font opened this issue Sep 7, 2017 · 7 comments

Comments

@font
Copy link

font commented Sep 7, 2017

Behavior

When using the go to definition :GoDef feature to navigate the source code with multiple vim windows open, each window will operate on the same :GoDefStack. This means that if you navigated to one area of the code in one window, all the other windows opened in the same vim process will see the same GoDef stack and subsequently push and pop on the same stack. This becomes a bit confusing as you move back and forth between windows pushing and popping as needed.

Steps to reproduce:

There are all sorts of combinations of this behavior that are cumbersome but here is a trivial example to reproduce it using version 1.14:

  1. Open a Go file for editing inside of a project that you can GoDef in.
  2. Split the window however you'd like (vertical or horizontal) so that you have 2 windows operating on the same buffer for that Go file.
  3. Then go to a spot in the code where you can use GoDef e.g. function, type, etc. and execute :GoDef or your equivalent hot-key.
  4. Move to the other window and run :GoDefStack and observe how you're using the same stack as the first window.
  5. Now go ahead and pop by using :GoDefPop or your equivalent hot-key and observe how you'll go back to the spot that you previously ran :GoDef from in the first window. This is confusing because you never navigated anywhere in this window.
  6. Move back to the first window and try to pop there using :GoDefPop or your equivalent hot-key. Observe how you don't go anywhere because you've already popped in the other window. So you're sort of stuck without a trail back home. :( Now you have to :GoDefStack to try and figure out where you started from to get back home in this window.

While in this trivial example it's not too big a deal, as the levels of the stack grow and you fork to new areas of the code, this begins to get really hairy. Instead, the GoDef feature would be greatly enhanced if we had independent stacks for each vim window.

Configuration

  • vim version: 8.0
  • vim-go version: 1.14
@arp242
Copy link
Contributor

arp242 commented Sep 8, 2017

Thanks for your detailed report!

I'm not sure what should happen if you open :GoDef in a new window or tab (as I do by default)? Using a window-local stack wouldn't really work for that. Then again, keeping a stack when opening stuff in a new window/tab is perhaps not all that useful in the first place?

I'm not sure how people are using this feature, and if changing the stack to be window-local would break other people's workflow. Could add a setting, I suppose, but meh; it's the sort of thing that should ideally work well out of the box for everyone.

Comments and insights welcome!

@font
Copy link
Author

font commented Sep 9, 2017

I'm not sure I understand your workflow. Could you elaborate on your use of :GoDef in a new window or tab by default and how that wouldn't really work for window local stacks?

I'm used to the cscope and ctags way of doing things so that seems the most natural to me and vim-go breaks that flow. Doesn't everybody feel the same way? ;)

@arp242
Copy link
Contributor

arp242 commented Sep 11, 2017

In my vimrc I have:

autocmd FileType go nmap gd <Plug>(go-def-tab)

So when I press gd it will open the definition in a brand new tab, instead of a new buffer in the current window.

Currently the global :GoDefStack works as expected with this; but it will no longer if we use a window-local :GoDefStack.

I think this is okay, since I don't expect that many people who use tabs like this use the DefStack (as it's kind of the same), but I'm not 100% sure, as I don't know how people are using Vim... You can never be sure as one man's bugfix can be another man's bug ;-)

@fatih
Copy link
Owner

fatih commented Sep 11, 2017

Now that we have this feature, I"m really thinking to get rid of it. There is already a native stack, and it's called jumplist. Whever you jump somewhere, you can see the list via :jumps, you can clear it via :clearjumps, you can jump back via CTRL-O, etc..

It's all native and integrated into Vim. I don't think it's worth spending time here, because it's just not worth implementing something which is already there and integrated into Vim. We should just remove this feature and announce it.

@font
Copy link
Author

font commented Sep 26, 2017

I'm good with that. So does this mean instead of using go_stack to maintain the stack we'll result back to using jumplist instead and remap ctrl-] and ctrl-t to behave similarly to ctrl-I and ctrl-O?

@bhcleek
Copy link
Collaborator

bhcleek commented Oct 8, 2017

Yes, @font, that's exactly what @fatih is suggesting.

@font
Copy link
Author

font commented Nov 4, 2017

Is jumplist what we really want in this case? It seems like it could be a bit overkill and used to jump back and forth between each position (file name, column number, line number) where positions include searching, substitute and marks. That seems a bit excessive because I'm really only talking about jumping between different go definitions via GoDef.

It seems all that we really need is the use of vim's tags stack used by tagsrch similar to what's used when working with C code (ctags or cscope) and the common ctrl-] and ctrl-t bindings. That is, a workflow that entails :GoDef and popping back to the last spot through the use of the familiar tag key bindings ctrl-] and ctrl-t. The ctrl-] is already done with :GoDef but what seems to be missing is a ctrl-t to pop back to your last spot where each window has its own stack.

Perhaps using a ctags compatible go tag generator such as https://github.com/jstemmer/gotags would work, but I'd prefer to have it all integrated into this awesome plugin.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants