5 ms·

Vimspector – the Vim debugger rules all

153 points by synergy20 3y ago

29athrowaway 3y ago
"Rules all" [laugh track] Most debuggers have vastly more functionality than this.
- TonyStr 3y ago
  Mind sharing some examples?
  - 29athrowaway 3y ago
    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.
imran-iq 3y ago
The actual title is "Vimspector - A multi-language debugging plugin for Vim". It is a UI around DAP: https://github.com/puremourning/vimspector#what-vimspector-is-not https://github.com/puremourning/vimspector#what-vimspector-i...
- synergy20 3y ago
  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 https://www.phoronix.com/news/GDB-Debug-Adapter-Protocol
  - westurner 3y ago
    gdb -i=dap https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=de7d7cb58e6209ed11c31f635545ee2ee6ded307 https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;...
MantisShrimp90 3y ago
You can also use nvim-dap if you use Neovim
mostthingsweb 3y ago
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.
aquova 3y ago
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.
- TheRoque 3y ago
  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)
lecozi 3y ago
nvim-dap and nvim-dap-ui ftw!
kristopolous 3y ago
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.
- BaculumMeumEst 3y ago
  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.
ducktective 3y ago
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?
- rochak 3y ago
  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.
- mrweasel 3y ago
  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.
  - delusional 3y ago
    > 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.
  - lycopodiopsida 3y ago
    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.
ezekiel68 3y ago
> ...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.
- askiiart 3y ago
  Using it to debug emacs would've been such a great reverse hierarchy (I think that's the word I'm looking for)

153 points by synergy20 3y ago

29athrowaway 3y ago

"Rules all" [laugh track] Most debuggers have vastly more functionality than this.

TonyStr 3y ago
Mind sharing some examples?
- 29athrowaway 3y ago
  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.

imran-iq 3y ago

The actual title is "Vimspector - A multi-language debugging plugin for Vim". It is a UI around DAP: https://github.com/puremourning/vimspector#what-vimspector-is-not https://github.com/puremourning/vimspector#what-vimspector-i...

synergy20 3y ago
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 https://www.phoronix.com/news/GDB-Debug-Adapter-Protocol
- westurner 3y ago
  gdb -i=dap https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=de7d7cb58e6209ed11c31f635545ee2ee6ded307 https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;...

MantisShrimp90 3y ago

You can also use nvim-dap if you use Neovim

mostthingsweb 3y ago

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.

aquova 3y ago

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.

TheRoque 3y ago
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)

lecozi 3y ago

nvim-dap and nvim-dap-ui ftw!

kristopolous 3y ago

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.

BaculumMeumEst 3y ago
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.

ducktective 3y ago

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?

rochak 3y ago
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.
mrweasel 3y ago
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.
- delusional 3y ago
  > 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.
- lycopodiopsida 3y ago
  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.

ezekiel68 3y ago

> ...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.

askiiart 3y ago
Using it to debug emacs would've been such a great reverse hierarchy (I think that's the word I'm looking for)