bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#30151: Debugger API


From: Eli Zaretskii
Subject: bug#30151: Debugger API
Date: Thu, 18 Jan 2018 16:41:16 +0200

> From: James Nguyen <james@jojojames.com>
> Date: Wed, 17 Jan 2018 20:56:38 -0800
> 
> I've been meaning to look at how to implement a debugger for Emacs for 
> various languages.
> 
> There seems to be various options to go with (realgud, gud/gud-mi?, NIH roll 
> my own) and it seems the community chooses different paths (including not 
> writing one at all).
> 
> Some debuggers that come to mind are: edebug, gud-gdb, realgud, cider, 
> indium, jdibug with a varied feature set.
> 
> I'm curious if it makes sense (or is doable) to have something similar to 
> flycheck/flymake but for debugging (or like VSCode's 
> https://code.visualstudio.com/docs/extensionAPI/api-debugging) so that 
> there's a common interface to writing a debugger.

Emacs provides an interface to _debuggers_, not to languages.  For
example, you can debug any language supported by GDB using gdb-mi.el,
but will have to use "M-x pdb" (defined in gud.el) for Perl debugging.

IOW, unlike VS, which is a single debugging engine, Emacs supports
several debugging engines.  The closest thing to VSCode's Debugging
API we have is therefore gdb-mi.el -- if you are willing to limit
yourself to those languages currently supported by GDB.

So I'm not sure I understand your idea well enough to answer your
questions in a useful way, at least not if I want to be sure I gave a
complete answer that you can use to decide how to go about this
project.  Can you elaborate on your idea given the above
considerations?

> gud-def looks to be the closest thing but it seems somewhat low level given 
> it doesn't draw breakpoints on screen (random example) or provide something 
> like a 'locals' view.
> 
> If gud-def is the recommended approach, I wonder why the other debuggers 
> (list mentioned above) don't leverage it.

gud-def (and gud.el in general) is supposed to be the extensible
debugging interface, yes.  However, the capabilities it can provide
depend critically on what the is supported by the underlying debugger.
E.g., displaying breakpoints requires that the debugger could be
queried about the location(s) of each breakpoint, and that it returns
the results of the query in a way that Emacs can unequivocally parse.

I cannot tell why packages you mentioned that support debugging roll
their own; perhaps the respective package developers could chime in
and explain.

Thanks.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]