Re: [ELPA] New package: dape

[João Távora]

On Wed, Dec 6, 2023 at 1:08 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: João Távora <joaotavora@gmail.com>
> > Date: Wed, 6 Dec 2023 12:56:12 +0000
> > Cc: Daniel Pettersson <daniel@dpettersson.net>,
> >  "Philip K." <philipk@posteo.net>,
> >  Dmitry Gutov <dmitry@gutov.dev>, John Yates <john@yates-sheets.org>,
> >  Krister Schuchardt <krister.schuchardt@gmail.com>,
> >  Adam Porter <adam@alphapapa.net>, emacs-devel <emacs-devel@gnu.org>
> >
> > I think what you're missing is that the support is the other way round. I'm 
> > recent versions of GDB you
> > can talk to it via DAP.
>
> Why would we want to do that in Emacs, when we already have gdb-mi?

Noone proposed that, AFAIU.  But that's what DAP support in GDB is
and that's what you asked about.

As to "why we would want"... No idea... But imagine that dape.el ends
up supporting a much nicer UI than gdb-mi.el?  More responsive,
robust, great keybindings, etc.  Than I imagine some people would
want to talk to GDB using that UI instead of gdb-mi.el's.

> > But that doesn't help when reusing the UI of gdb-mi.el to talk to non-gdb 
> > DAP debuggers.
>
> Like what?

Like a lot of non-GDB debuggers these days talk DAP.  Here's a
big list: 
https://microsoft.github.io/debug-adapter-protocol/implementors/adapters/

> > And that
> > interface reuse (which would be a great thing if it were particle and 
> > clean, granted) is what Daniel is
> > presumably trying to achieve.
>
> gdb-mi is explicitly meant to be used with the GDB/MI interface, not
> with anything else.  It makes little sense with other interpreters.
> The only part that could be theoretically extracted is the setup of
> several debugging-related windows, but doing that from scratch should
> be a very simple task, and there's nothing in gdb-mi that AFAICT is
> unique in those few portions.  Moreover, I won't be surprised if some
> UI decisions in gdb-mi were not made specifically to cater to G|DB and
> its MI protocol.
>
> IOW, I don't see why someone would want to reuse gdb-mi's code if we
> only need to reuse the few UI parts of it.  It sounds like more
> trouble than worth it.

I don't know gdb-mi.el very well, but if it has code for displaying
and interacting with lists of threads, local variables, registers,
breakpoints, displaying assembly, then IMO it could well make sense
to lift that interface to something that both gdb-mi.el and dape.el
could use.  That's less code for us to maintain and potential
improvements to that liften code would benefit both extensions.

As you know, Eglot uses this approach: it tries to add as little UI
as possible and reuse existing things in Emacs.  Frequently I end up
doing work to generalize these existing components in
backward-compatible fashion for that effect.   Which is not always,
because sometimes it's not an easy job.

I personally wouldn't write it off as "more trouble than it's
worth", without a more or less thorough analysis of the similarities
and differences between these UIs.  Cost-benefit analysis are
usually hard questions to answer.

João