Re: [ELPA] New package: dape

[Eli Zaretskii <eliz@gnu.org>]

> From: João Távora <joaotavora@gmail.com>
> Date: Wed, 6 Dec 2023 13:38:54 +0000
> Cc: daniel@dpettersson.net, philipk@posteo.net, dmitry@gutov.dev, 
> 	john@yates-sheets.org, krister.schuchardt@gmail.com, adam@alphapapa.net, 
> 	emacs-devel@gnu.org
> 
> As to "why we would want"... No idea... But imagine that dape.el ends
> up supporting a much nicer UI than gdb-mi.el?

If the gdb-mi UI needs improvement, I'd rather we improve it instead
of ditching it.  GDB/MI is _the_ official GDB way for GUI front-ends,
and will remain so for the years to come.  It will take the DAP
interface some time to get there, and even when it does, GDB/MI will
always integrate better with GDB, since it is being developed by the
GDB project, unlike DAP which is primarily modeled on "other
debuggers".

> 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.

Only if we fail to keep gdb-mi up to the job.

> > > 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/

I know the list.  I was asking which of them we'd need to support, and
why?

> > 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.

What gdb-mi has is code that parses the GDB/MI output and shows the
results.  Factoring out the display part out of that will leave you
with mostly trivial stuff.  For example, the display part of showing
the threads in a program is gdb-table-add-row and a couple of simple
subroutines, whereas the function that handles threads display is
built around code specific to GDB/MI output and structures into which
that output is parsed, and relies on thread info provided by GDB; see
gdb-thread-list-handler-custom.

> As you know, Eglot uses this approach: it tries to add as little UI
> as possible and reuse existing things in Emacs.

Eglot started from LSP and provides only features supported by LSP.
gdb-mi started from GDB/MI and supports only that protocol.  A better
analogy for this discussion is how easy will it be to move Eglot to a
completely different protocol, and on top of that a protocol that is
not based on JSON but on some other structured output.

Moreover, where Eglot plugs itself into Emacs editing features, a
debugging package has no features to plug itself into, because
debugging is very different from editing programs.

> 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.

Which UIs are we talking about here?