Hacker News Reader

Comment by godelski | Hacker News Reader

Does anyone know a good debugger plugin for vim? I've tried a few and found them not great. This is seriously the only thing I currently want more from vim. I keep an IDE around just for this purpose. (A debugger with support for C++ and python. Don't care if two plugins)

View on HN

Personally, Ive never tried to make Vim my IDE on Linux. Just Vim as my editor, make as my "builder" and gdb as my debugger. Effectively, bash was my IDE.

I know on the older spectrum of the audience here, but that is an effective workflow for me. But, as a nearly 40 yr old, the command-line is very natural to me. I actually get irritated when I have reach for a mouse to complete an action.

I agree. Vim with ctags and gdb is a pretty performant workflow. I just turned 40. So maybe it is context. I do like vscode though. Its pretty snappy and has good keyboard shortcuts so I don't have to touch the rodent.

You know how in GDB you can see the lines you are working on? Really I just want that to have color, like I do in vim. We don't like in 1970 anymore. We have color. The other thing I want is that while editing I can add break point.

Maybe I'm too young (28), but how I read your and the parent's comment is "My workflow has been working fine, why improve it?" which sounds weird to me. There's always room for improvement.

Have you tried ConqueGDB? It lets you start the GDB from within your vim session and uses your vim buffers to show the current file. I recently started using it and didn't really get into familiarizing with it yet, but it seems to integrate the gdb quite well. I am uncertain whether or not you can set breakpoints within the code though.

IME, if you haven't already then I'd suggest biting the bullet and learning GDB. It's not as nice to step through code but far more powerful than the features typically exposed by an IDE, or at best are only exposed by GDB's command line interface anyway. Reverse debugging and scriptability (the command interface is a DSL) are the big ones. Like vim, GDB is an incredibly powerful tools that deserves the time to learn well.

"Give me 15 minutes and I'll change your opinion on GDB" was one of the most life changing videos I've watched. It's on youtube or text version here: https://undo.io/resources/cppcon-2015-greg-law-give-me-15-mi...

I'm fine with GDB. But I would like it in vim. You know how in GDB you can get the line by line representation? Just that but with my colorschemes and so I can set breakpoints while in vim. GDB isn't an issue, it is that GDB is old, doesn't support colors, and doesn't integrate with my editor.

I assume you're using cmake? For C/C++, cquery does completion (which I got working, but honestly didn't like and turned off. There are these two plugins for cmake:

https://github.com/ilyachur/cmake4vim

https://github.com/vhdirk/vim-cmake

It would be fairly quick to put something in your vimrc to pop open a small split on the side, run a build command, and show an output. You could also probably pop open a terminal (new vim has the :term command) and maybe script that? If not cmake, it shouldn't be too difficult to replace cmake with something else. I've always found I can get better results from vim that more exactly what I want, but I've got to kind of want it and be willing to write some script to do it. The results are better, but there's more up-front investment.

I'm more looking for a debugger rather than a compiler. Like GDB. I wouldn't call cmake or make debuggers.

I have seen a few gdb plugins but at least my experience is that they are extremely wanting.

Why not just run `:term` followed by full gdb? Doesn't seem like it's worth implementing a whole other interface.

That doesn't enable the same marking of break points and other features you typically get from IDEs. In GDB you can see multiple lines and split your screen, so I wouldn't use :term (I'll split with tmux). But other things that IDE debuggers have are like a file list (nerd tree) and display works better (off to the side). GDB technically has all these things, but it isn't formatted nicely. I use vim to be fast and efficient (and vim plugins for IDEs SUCK, plus are bloated).

Do people just not use debuggers around here?

Fair enough; I do like the visual breakpoint interface. Honestly, that's one thing MSVC does really well: the debugger. Just curious to see why that didn't work for you. I'm assuming it's viable to implement this, I guess no one yet has.

It looks like there is a debugger in the newest vim. A little playing around with it shows some nice features. Still not quite what I want, but better than nothing.

Not within Vim, but I'd recommend running "gdb --tui" in your terminal (not inside Vim), and then flipping it into "vi mode": https://sourceware.org/gdb/onlinedocs/gdb/Readline-vi-Mode.h...

Alternatively, running "M-x gdb"[1] within Emacs configured with Evil[1] for Vim keybindings[2]. Running a separate program is a pain, and it won't have config from your .vimrc, but the tight integration between GDB and Emacs is really nice.

[1] https://www.gnu.org/software/emacs/manual/html_node/emacs/GD...

[2] https://github.com/emacs-evil/evil

I use tui (well I just hit `<C-x>a`) but there's more I want, like color (because we aren't living in 1970!). Maybe this vi more does the other part I want, which is code exploration and allow me to select lines for break points instead of typing as much. But I'm not sure what `M-C-j` is (I'm sure this is a dumb question). Both of these things are pretty standard in modern gui debuggers. The other thing I kinda want but isn't necessary is my display variables to be in a different pane and to have a nerdtree like file structure.

Frankly a lot of times I know where I need to investigate my in my code. But it is annoying to switch to vim, find the file and line number, go back to gdb then do `b my/file/structure/is/long:1825`. That gets hectic in large projects.

edit: My current setup I used vim+zsh+tmux. So I don't mind having gdb in a new pane that isn't a vim pane, but I just want colors and some of the basic features. I don't need everything that the IDEs do, just the basics.

gdb has colored output since v8.3, including syntax hightlighting.

Regarding vim, have you tried the termdebug plugin that ships with vim?

    :help termdebug-starting

> But I'm not sure what `M-C-j` is

Meta-Control-j

Basically hold down the 'Alt' and 'Control' keys and then press 'j'.

If you don't want to have to toggle it every time you launch gdb, then you can create a ~/.inputrc file with the following contents:

    $if gdb
      set editing-mode vi
    $endif

If you want vi bindings in every program that uses GNU Readline (Bash, etc.), then you can leave off the $if/$endif part.

For colors - GDB 8.3 added source code syntax highlighting, but it was just released this year and may not be the version on your Linux distribution.

Vim >= 8.1 has a built-in debugger interface called termdebug: https://www.dannyadam.com/blog/2019/05/debugging-in-vim/

I haven't used it, but it might meet your needs.

If neovim is an option to you, nvim-gdb is excellent. It also supports pdb for python debugging.

https://github.com/sakhnik/nvim-gdb

Reply on news.ycombinator.com