|Project Name||Stars||Downloads||Repos Using This||Packages Using This||Most Recent Commit||Total Releases||Latest Release||Open Issues||License||Language|
|Dap Mode||1,159||2 days ago||198||gpl-3.0||Emacs Lisp|
|Emacs :heart: Debug Adapter Protocol|
|Book||6||8 years ago||1|
|ember & cli|
|Hsearch||3||11 years ago||Emacs Lisp|
|An Emacs interface for searching Haskell code on Hoogle and Hayoo|
Emacs client/library for Debug Adapter Protocol is a wire protocol for communication between client and Debug Server. It’s similar to the LSP but provides integration with debug server.
The API considered unstable until 1.0 release is out. It is tested against Java, Python, Ruby, Elixir and LLDB (C/C++/Objective-C/Swift).
The main entry points are
dap-debug-edit-template. The first
one asks for a registered debug template and starts the configuration using
the default values for that particular configuration. The latter creates a
debug template which could be customized before running.
dap-debug-edit-template will prepare a template declaration inside a
temporary buffer. You should execute this code using
C-M-x for the changes to
apply. You should also copy this code into your Emacs configuration if you wish to
make it persistent.
dap-mode also provides a hydra with
dap-hydra. You can automatically trigger
the hydra when the program hits a breakpoint by using the following code.
(add-hook 'dap-stopped-hook (lambda (arg) (call-interactively #'dap-hydra)))
You can also use this tool with dockerized debug servers: configure it either with a
or drop an
.lsp-docker.yml configuration file (use lsp-docker for general reference).
Basically you have one function
dap-docker-register that performs all the heavy lifting (finding the original debug template,
patching it, registering a debug provider e.t.c). This function examines a configuration file or falls back to the default configuration
(which can be patched using the
.dir-locals approach, take a note that the default configuration doesn’t provide any sane defaults for debugging)
and then operates on the combination of the two. This mechanism is the same as in
Note: currently you cannot use this mode when using a network connection to connect to debuggers (this part is yet to be implemented).
Still want to talk to debuggers over network? In order to do so you have to look at the
dap-docker--dockerize-start-file-args, you have to somehow assign
dap-server-path before it is passed further into session creation.
If you want to stick to a configuration file, take a look at the example below:
lsp: server: # 'lsp-docker' fields mappings: - source: "/your/host/source/path" # used both by 'lsp-docker' and 'dap-docker' destination: "/your/local/path/inside/a/container" # used both by 'lsp-docker' and 'dap-docker' debug: type: docker # only docker is supported subtype: image # or 'container' name: <docker image or container that has the debugger in> # you can omit this field # in this case the 'lsp-docker' ('server' section) image name is used enabled: true # you can explicitly disable 'dap-docker' by using 'false' provider: <your default language debug provider, double quoted string> template: <your default language debug template, double quoted string> launch_command: <an explicit command if you want to override a default one provided by the debug provider> # e.g. if you have installed a debug server in a different directory, not used with 'container' subtype debuggers