Vimspector – the Vim debugger rules all(puremourning.github.io)
puremourning.github.io
Vimspector – the Vim debugger rules all
https://puremourning.github.io/vimspector-web/
24 comments
Microsoft made LSP and it does DAP, both are really useful for coders.
In fact even GDB added DAP support recently: https://www.phoronix.com/news/GDB-Debug-Adapter-Protocol
In fact even GDB added DAP support recently: https://www.phoronix.com/news/GDB-Debug-Adapter-Protocol
> ...configuring it to debug Vim, as an example of a C program
It's a bit of a pity they decided to use it do debug vim itself in all the examples. Given the title and this quote, it took me at least 5 mintues of re-reading to convince myself with 97% certainty that it can, in fact, debug other programs.
It's a bit of a pity they decided to use it do debug vim itself in all the examples. Given the title and this quote, it took me at least 5 mintues of re-reading to convince myself with 97% certainty that it can, in fact, debug other programs.
Using it to debug emacs would've been such a great reverse hierarchy (I think that's the word I'm looking for)
Anyone fully competent in both this and GUD on emacs? Have any thoughts?
I feel like I'm wandering around too much in all of these debuggers and can't seem to use them to drill down effectively but I haven't really been able to conceptualize what I'd change.
It's like I want a higher level organizational abstraction. The number of moving pieces seems to exhaust my personal working memory for really challenging problems and I quickly get disorganized with all the watches and breakpoints. Maybe there's opportunities for an AI debugging assistant.
I feel like I'm wandering around too much in all of these debuggers and can't seem to use them to drill down effectively but I haven't really been able to conceptualize what I'd change.
It's like I want a higher level organizational abstraction. The number of moving pieces seems to exhaust my personal working memory for really challenging problems and I quickly get disorganized with all the watches and breakpoints. Maybe there's opportunities for an AI debugging assistant.
I have experimented with them a bit. I've used GUD a bit with PDB, GDB, and LLDB, and vimspector with GDB, but Intellij and Visual Studio offer a lot more functionality, are far better documented, much more user friendly, and far less brittle. I really think it makes sense to just use programs that are more optimal for debugging.
There are a few exceptions: Common Lisp has a best-in-class debugger in Emacs thanks to João Távora, and same for Racket thanks to Greg Hendershott. I wish I could say GNU guile has a good debugging support in GNU emacs, but that is sadly not the case.
There are a few exceptions: Common Lisp has a best-in-class debugger in Emacs thanks to João Távora, and same for Racket thanks to Greg Hendershott. I wish I could say GNU guile has a good debugging support in GNU emacs, but that is sadly not the case.
So, I sometimes read comments such as "I use vim/nvim for everything but for debugging I use VSCode/IntelliJ". I mean, how does that work out? Debugging is something that may come up anytime while coding, you just fire up an IDE and only use it for debugging? Then why not go the extra mile and use the already open IDE for writing code?
Because everything else about coding that is not debugging is arguably better in vim/nvim.
I'm one of those. A happy user of IDEs for a decade, but after trying and embracing vim/nvim all the IDEs now feel slow, bloated and clunky. Even with vim/nvim plugins.
I'm one of those. A happy user of IDEs for a decade, but after trying and embracing vim/nvim all the IDEs now feel slow, bloated and clunky. Even with vim/nvim plugins.
I'm one of those people. It depends on the use case. VSCode has a plugin to use a Neovim instance behind the scenes, complete with supporting (some) plugins and configurations. At work I exclusively use this, since it has debugging support and is more in line with my coworkers are using. At home, where I'm writing in a wider array of languages and often haven't bothered setting up a debugging environment for many projects, I use mainly Neovim.
For me, Vim's built in termdebug works just fine. But I still prefer to debug out of the editor, as I often need to combine multiple tools (strace, radare2, scripting scenarios to inject packets and coordinate multiple devices, etc) and the debuggers built into IDEs are quite limited in this regard.
If I cannot automate it then it is useless.
If I cannot automate it then it is useless.
Last summer there was an interview with John Carmack where he talked about the weirdness of developers in large organizations like Google clinging to Vim or other terminal based editors and how the game developers would embrace every tool that makes their life easier. That where I just gave up and switched to VSCode, because he's right. I have one exception, because I CANNOT figure how to get VSCode to handle our Puppet syntax.
It's weird, because I used to work as a .Net developer, using Visual Studio, but I completely forgot how efficient is it to just be able to set a break point.
It's weird, because I used to work as a .Net developer, using Visual Studio, but I completely forgot how efficient is it to just be able to set a break point.
> how the game developers would embrace every tool that makes their life easier
That's just not true. Plenty of game developers use old tools as well, with the exact same argument of "it makes my life easier"
There's not even a nugget of truth to this statement, it's just generalization nonsense.
That's just not true. Plenty of game developers use old tools as well, with the exact same argument of "it makes my life easier"
There's not even a nugget of truth to this statement, it's just generalization nonsense.
As convincing the good old appeal to authority may sound for some, it still remains only one thing - a fallacy. There is nothing making me more productive in VSCode and I can set break points in neovim just fine.
I do this regularly. It takes a second for the code to update from the file system as you switch windows, and it takes me very little time to save that second back with my vim chops. If intellij's vim emulation actually worked reliably and quickly I would just switch, but it doesn't. :-/
I just use CLI based debuggers. Sure they are hard to setup, but I appreciate the low level knowledge I acquire to set them up. Most engineers I have met don’t even understand how to build everything from the ground up, so when shit hits the fan, they are left scratching their head.
You can also use nvim-dap if you use Neovim
I started playing around with nvim-dap, but after struggling to get it working and learning how to use the UI, I think for me it's a step beyond what I find Neovim good for, and instead I'd rather stick to something like VSCode for debugging.
Fully agreed. And I'd even say that the keyboard is less ergonomic for debugging: highlighting the variables on a mouse hover is much faster than typing manually all the variables you wanna watch. Moreover, the latest vscode debugger "vscode-js-debug" wasn't working with the DAP plugin in neovim, and you have to fallback to an oldest debugger (maybe this has been fixed, it's been a year now)
Slightly unfortunate name (both for repo and submission title); I was hoping it had something to do with inspecting vim internals, e.g. for plugin authors.
nvim-dap and nvim-dap-ui ftw!
"Rules all" [laugh track]
Most debuggers have vastly more functionality than this.
Most debuggers have vastly more functionality than this.
Mind sharing some examples?
It depends on the use-case.
For vanilla use-cases, the debugger on Visual Studio or Jetbrains IDEs may have more features and better usability.
I think some even support reverse debugging or time travel (rr-like), memory watchpoints, etc.
Pause execution when some memory is read or written to = watchpoint.
For reverse engineering you've got OllyDbg clones like edb or x64dbg and others.
And there is the underworld of gdb custom scripts that is really interesting looking into. gdb tui too.
For vanilla use-cases, the debugger on Visual Studio or Jetbrains IDEs may have more features and better usability.
I think some even support reverse debugging or time travel (rr-like), memory watchpoints, etc.
Pause execution when some memory is read or written to = watchpoint.
For reverse engineering you've got OllyDbg clones like edb or x64dbg and others.
And there is the underworld of gdb custom scripts that is really interesting looking into. gdb tui too.
It is a UI around DAP: https://github.com/puremourning/vimspector#what-vimspector-i...