Vim-go: Source-level debugging in Vim

Created on 22 Nov 2014  路  9Comments  路  Source: fatih/vim-go

I don't know if this should be a concern for vim-go specifically or maybe a new project should be started, but there's a new debugger in town apparently, and someone from the IntelliJ Go plugin team has contacted him about integrating it: https://github.com/derekparker/delve/issues/22 . They are considering an HTTP API currently.

So, just a heads up in case anyone wants to do anything with this.

feature

Most helpful comment

First class support would be nice. I believe async jobs are available in vim 8 now.

As a work around you can create a snippet for runtime.Breakpoint().

All 9 comments

Implementing it into Vim's non-async ui would be a hard thing, but let's see if someone else jumps in to implement it. Thanks for noticing it.

I'll close this for now as I have limited time and I don't want to clutter the issues section with features that I'm going to not eventually tackle in near future. We can always open this again once the debugging stuff is more mature.

Just stumbled on this, worth mentioning that this might be another good fit for a neovim feature with the async job control. :)

I'll take a stab at trying to implement this in neovim soon.

Also related, Microsoft just launched VSCode with a Go plugin with partial delve support: https://github.com/Microsoft/vscode-go

thats actually exactly why I came on here. was looking to see if vim-go is going to support it any time soon.

@shazow @nhooyr I've also switched partly to neovim. I have now an init.vim file which I use both for Vim and Neovim. However my duties are more about vim rather than neovim. But the great thing is that we can introduce features into vim-go with the guards has("nvim") easily. And I really like neovim and think that the async behavior is a game changer.

I'm always open to contributions. My initial work was to provide async GoBuild, GoRun, etc... To do this we first need some helper functions and wrappers, so we can build on top of it (like the path.vim file).

I'm pretty excited about the possibilities. But also remember that every single feature is going to introduce maintenance cost, which eventually make it harder for me to work on vim-go. So I'm thinking even though when we introduce these features, I'm going to mark the explicitly as experimental until it's very stable and can be used without any problem.

Even if there isn't full integration, more simple integration like setting break points in vim /nvim that generate a file to load into delve would be useful.

First class support would be nice. I believe async jobs are available in vim 8 now.

As a work around you can create a snippet for runtime.Breakpoint().

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jongillham picture jongillham  路  3Comments

korjavin picture korjavin  路  4Comments

smontazeran picture smontazeran  路  4Comments

zhangjing picture zhangjing  路  3Comments

andrejvanderzee picture andrejvanderzee  路  3Comments