3 ms·
Out of interest, how do you go about debugging code when you live on the command line? In an editor you have nice features like a visualisation of the call stac
by soVeryTired 7y ago
Out of interest, how do you go about debugging code when you live on the command line? In an editor you have nice features like a visualisation of the call stack, and the ability to set watches and conditional breakpoints. Are there vim equivalents, or do you live without?
FWIW I'm using vim bindings in VS code.
- non-entity 7y agoI imagine you use something like GDB which has different commands to do that stuff. For example quick Google search reveals [this](http://www.it.uc3m.es/pbasanta/asng/course_notes/debugger_condbreak_en.html http://www.it.uc3m.es/pbasanta/asng/course_notes/debugger_co...) for conditional breakpoints (haven't used a command line debugger in forever tho)
- rvense 7y agoDepends on the environment, but a lot of print/exception-based debugging as you'd expect, or use REPLs when they're available. I do a lot of web work currently and occasionally use the debugger in Firefox. I have also used GDB in other contexts. I don't really feel like I'm too lacking in this department, but maybe the things I do aren't too complex.
- R0flcopt3r 7y agoI use this plugin for debugging. Works a treat! https://github.com/sakhnik/nvim-gdb https://github.com/sakhnik/nvim-gdb GDB is also extensible as hell, and I can’t imagine vs code has something gdb doesn’t.
- drbojingle 7y agoIt depends on what you're debugging. There are plugins for a variety of languages and if you're a web dev, none of that matters since debugging with the browsers dev tools is pretty comfortable.
- chooseaname 7y agoNot OP, but having a good debug log is invaluable. I prefer it to using an IDE debugger. It's rare I need to debug in an IDE, because I can read my logs and see what went wrong and where. Then all I need to do is read the code to find the faulty logic.
- deleted 7y ago[deleted]
- goatlover 7y agoSome language environments like Lisp or Smalltalk let you fix the code in the debugger, plus you have inspection tools available.
- Asooka 7y agoI just use either gdb's tui, or the new gdb integration in vim 8, along with a few custom pretty printers for types, but you'd have to write those no matter what debugger you used. One difference is that I do not debug in the same editor instance I write code in - it's possible, but I don't like having my editor switching state. It is possibly slightly suboptimal as far as debugger interfaces go, and perhaps using Emacs with its gdb integration would be better, but I haven't felt the need to do so yet. The backtrace, variable values, local variables, thread list, etc. etc. are all there, just not in floating windows, but behind commands you run to call them when you need them. Since it's all text, you can just copy and paste to a temp buffer if you want to take notes. I have never felt limited in my capabilities to debug per se, but a modern reinvention of DDD would be appreciated. Also since everything is text, entering and recording any information is dead simple. An aside, as another poster noted - Vim's editing keys are the first thing I'd give up for a better Vim. I've tried Vim mode in VS and it's not Vim. Yes, you move with hjkl, but the editing keys and the entire rest of the IDE are two entirely separate worlds. E.g. I can't record a macro that jumps to a symbol definition as part of its execution. In Vim the entire experience is integrated and there is no separation between "editing keys" and "navigation keys", etc. At its core, Vim is a parser for a sequence of keystrokes where each runs a command. Any command can be bound to any keystroke or sequence of keystrokes. The entire system is based on a few basic principles that apply equally across all keystrokes. Just embedding a Vim editing mode in your IDE is not at all the same as the real thing. It is still better, especially if you need to limit your finger movements due to RSI or other issues, but it doesn't recreate the reason for which I use Vim. To replace Vim, you'll need to do the inverse - rather than have the IDE as a shell and a Vim mode embedded in it, have a Vim interface as the shell and IDE functionality embedded in it.
- kerkeslager 7y agogdb for C, Firefox dev tools for JS, ipdb for Python. The Firefox dev tools are probably the weakest of these, but the other two handle everything you mention just fine.
- colordrops 7y agocgdb is nice too, adds syntax highlighting and vim-like keybindings.