FluentFelicity · 2022-06-21 23:29
I thought I'd ask since I'm curious.
This type of question always goes alongside the discussion of eglot versus lsp-mode, and is asked at least every few months in this sub. In that discussion, some prefer eglot because it feels more unobtrusive and faithful to Emacs built-ins compared to lsp-mode—so eglot is a legitimate alternative to lsp-mode.
Debugging is a different story. Really, the only viable debugging tools (that aren't for elisp) in Emacs are dap-mode and gud and its rewrite, realgud. Though the debugging adapter protocol (dap) can be reimplemented for eglot, [it would take a lot of effort, so it likely won't manifest anytime soon](https://github.com/emacs-lsp/dap-mode/issues/2#issuecomment-544180841). Consequently: if you want to use dap, then you have to use lsp-mode.
But how is gud/realgud? It's almost never spoken of these days due to the popularity of lsp-mode/dap-mode. Of course, the tools are very different, but does anyone still think gud/realgud can be treated as a genuine alternative to dap-mode (barring preferences in UI)? Do they still have a place?
speckledlemon · 2022-06-22 04:21
I use realgud mostly for C++ and Python, some C, and rarely F77.
I skimmed the docs for `dap-mode`, and it seemed like I need to set up configurations? I remember doing that with IntelliJ and PyCharm and found it really irritating. I like just being able to trivially fire up `gdb` or `pdb` on the command line. The docs for `dap-mode` are threadbare. I know at least David Wilson has gone through some examples and I've seen at least one really good blog post on using it for C++ or Python, but haven't bothered to experiment since my time spent in the debugger is low compared to writing and editing. I am also used to CLI debuggers, `pdb` in particular, and don't miss the extra stuff you see in JetBrains- or MATLAB-style debuggers.
There are some problems with realgud that maybe just need configuration. Interacting with it is noticeably slower than the CLI. The realgud interaction pane (basically comint) has annoying movement behavior when executing each command. Sometimes the extra space it makes on the left for breakpoint and line markers hangs around in buffers even after the debug session has ended.
As a result, I mostly just debug from a regular terminal outside Emacs and only use realgud for large or special C++ sessions.
Hooxen · 2022-06-22 04:47
do you find that realgud is a no brainer improvement over gud worth installing it vs gud being built in already (if i’m not mistaken)?
janoc · 2022-06-22 07:12
I think compared to gud yes. Compared to other debugging solutions available for GDB/PDB, not so much.
`dap-mode` I didn't bother with for exactly the same reasons as /u/speckledlemon above - having to create a configuration for each binary I want to debug is a just a royal PITA. It is the same stupidity that they elected to do in VSCode where one needs a JSON config to launch/debug an executable and it sucks.
Even original Visual Studio allows one to just hit a button and start the debugger with the default executable without having to set up anything unless one wants to.
Debugger needs to be able to start quickly, with no major setup for the common use cases, otherwise it gets in the way. I find it much easier to just start a command line debugger (e.g. `cgdb` CLI gdb frontend or `pdbpp` for Python) than messing with `gud/realgud/dap-mode` in Emacs.
AureumLeonis · 2022-06-23 06:14
You don't need to write configurations, at least for Java. You can simply do `dap-java-debug-class` or the like.