all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: James Nguyen <james@jojojames.com>
Cc: 30151@debbugs.gnu.org
Subject: bug#30151: Debugger API
Date: Thu, 18 Jan 2018 16:41:16 +0200	[thread overview]
Message-ID: <83shb3ut4j.fsf@gnu.org> (raw)
In-Reply-To: <1516251398.1364994.1239356432.7334F1AF@webmail.messagingengine.com> (message from James Nguyen on Wed, 17 Jan 2018 20:56:38 -0800)

> 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	other threads:[~2018-01-18 14:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-18  4:56 bug#30151: Debugger API James Nguyen
2018-01-18 14:41 ` Eli Zaretskii [this message]
2018-01-19  9:25   ` James Nguyen
2018-01-19 10:19     ` Eli Zaretskii
2018-01-21 19:16       ` James Nguyen
2019-09-28 22:56 ` Stefan Kangas
2019-09-28 23:53   ` james
2019-09-29  0:13     ` Stefan Kangas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83shb3ut4j.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=30151@debbugs.gnu.org \
    --cc=james@jojojames.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.