dap-mode VS tide

GDB with gdb -i dap allows you to debug any language that GDB can debug from within Emacs' dap-mode: https://github.com/emacs-lsp/dap-mode

lsp's brother. One search away. https://github.com/emacs-lsp/dap-mode

Debug template for go subtest was just added: https://github.com/emacs-lsp/dap-mode/pull/704/

Debugging (kind of an IDE feature) is a little harder. Out of the box, Emacs can at least debug emacs-lisp (with built-in features) and C (via gdb integration). Beyond that, take a look at dap-mode for other language options. Similarly, take a look at lsp-mode or eglot for code completion, more advanced linting, etc.

At least for web development I believe eglot is strictly worse. It does not support running multiple servers (e.g. tsserver and eslint-ls) (https://github.com/joaotavora/eglot/issues/976) which is supported by lsp-mode and neovim's built-in lsp client. Also, it does not have any equivalent to dap-mode which is lsp-mode only. Although worth noting dap-mode is currently useless for js (https://github.com/emacs-lsp/dap-mode/issues/369).

Hi, as it seems EGlot will receive the blessing of inclusion into vanilla Emacs. That makes me wonder how I am supposed to use dap-mode at it swaps in lsp-mode as a dependency.

We will use dap-mode with the dap-gdb-lldb option here. Under the hood, it uses the debug adapter from the Native Debug VSCode extension. Configuring it is described on the dap-mode webpages. After we have configured dap-mode, we could in theory reuse the launch.json configurations from the VSCode related articles above. That will require that you also use lsp-mode, as dap-launch depends on the lsp-workspace-root function and will not resolve when lsp-mode is not used. I don't use lsp-mode with C (company-clang and company-c-headers provide what I need), so the next logical solution would be to create a debug template ourselves:

Hmm it does seem like Emacs is growing support for the Debug Adapter Protocol (DAP), the LSP-alike convention that allows language developers to build language-specific debuggers that tie into the VSCode UI: https://github.com/emacs-lsp/dap-mode

So, what do you need: - Language server for Python (lsp and lsp-ui) Use lsp-mode it's more reach with features at the moment https://emacs-lsp.github.io/lsp-mode/page/installation/ - Real-time program debugging (dap-mode) https://github.com/emacs-lsp/dap-mode

Seems like too much work and the issue has been closed and not reopened since 2018 sadly. It looks like it won't be happening any time soon. https://github.com/emacs-lsp/dap-mode/issues/2

How does it compare with Tide? https://github.com/ananthakumaran/tide

I got to try my hands on Typescript in Emacs using tide, and I loved the autocompletion enabled by type-inference. But even besides type-inference, there's even the autocompletion for previously defined local variables that exists in other language tools including anaconda for python, which I don't see in my setup of SLIME/emacs.

You should try tide for TypeScript projects.

off topic: I've found tide-mode[0] to be pretty good to use with typescript on Emacs

[0] https://github.com/ananthakumaran/tide

Is there a way to autogen doxygen doc for C/C++? At least templates with the parameters types and return type? I do this with tide in Emacs with Typescript for example and it's pretty useful.

Anyone got any experience with this package? I have got it running but the default key binding to jump to a definition is not working at all. Stated here (https://github.com/ananthakumaran/tide) M-. should work but that seems to be already bound to something else.

Then I started with TypeScript and I was both amazed and saddened by it. For regular TS files, .ts it was amazing. The spacemacs typescript-mode was even better than rjsx-mode, all the types are shown perfectly in the bottom bar, autocomplete, auto-import... Everything. And thanks to tide. The sad part is: there is no tsx-mode, to write our .tsx files, we have to use web-mode. Don't get me wrong, this is a great mode, but React + Typescript were not the goals back then.