unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Daniel Pettersson <daniel@dpettersson.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: "João Távora" <joaotavora@gmail.com>,
	philipk@posteo.net, dmitry@gutov.dev, john@yates-sheets.org,
	krister.schuchardt@gmail.com, adam@alphapapa.net,
	emacs-devel@gnu.org
Subject: Re: [ELPA] New package: dape
Date: Thu, 7 Dec 2023 00:55:46 +0100	[thread overview]
Message-ID: <CAM-j=qtQv1aNvJ3hOEKNnLeqeq=WpfP_M0qmdTcddr6=zi0aUg@mail.gmail.com> (raw)
In-Reply-To: <835y1b4673.fsf@gnu.org>

First off I got a bunch of request of making the interface for dape
more like GUD, which is to say that they requested an interface more
like the gdb-mi.el's interface. This is where gdb-mi.el enters the
picture.

First of I am not saying that it's worth the effort, but if this is
the consensus that the best thing for "dape" or whatever it should be
called is if it should be more like "GUD" it seams like it would be
preferable if it could reuse ui "components"  and it's bindings from
gdb-mi.el

On Wed, Dec 6, 2023 at 6:19 PM Eli Zaretskii <eliz@gnu.org> wrote:
> 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".

This speaks to my point really, if gdb-mi is THE ui for debugging
wouldn't it be great if you could use the sameish ui to debug python,
java, javascript, dart, godot etc.. I am not suggesting that gdb-mi.el
should be replaced by "dape" just that they share some UI and
keybindings.

I don't think it's fair to say that DAP is primarily modeled on "other
debuggers". My opinion is that DAP has been developed to get vs code
to support launching and debugging programs in a variety of
programming languages. To use words like modeled or designed gives it
to much credit. But the adapter implementations is very capable
of getting the job done. For some reasons unbeknownst to me there has
been no big leaps in debugging, we still set breakpoints, watch
variables and step through our code. All of this and more is supported
by DAP and gdb-mi.el has the interface and keybindings to support such
a workflow, it's just tightly coupled with gdb-mi.

Maybe it's fine as it is is and dape can incorporate improvements to
gdb-mi.el's interface and maybe vise versa.

I made an effort to get dape to feel like it's somewhat consistent
with gdb-mi.el and to gauge the progress I would greatly appreciate
some feedback, it would be great if Eli or any other person who has
experience with gdb-mi.el could help me out.

Daniel



  parent reply	other threads:[~2023-12-06 23:55 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-13 10:35 [ELPA] New package: dape Daniel Pettersson
2023-10-13 12:24 ` Philip Kaludercic
2023-10-14 12:28   ` Daniel Pettersson
2023-10-14 14:54     ` Philip Kaludercic
2023-10-15 13:50       ` James Thomas
2023-10-15 14:12         ` Philip Kaludercic
2023-10-15 17:24           ` John Yates
2023-10-18 21:54       ` Daniel Pettersson
2023-10-19  2:08         ` Adam Porter
2023-10-19 10:52           ` Krister Schuchardt
2023-10-19 11:06             ` Dmitry Gutov
2023-10-20 14:53               ` John Yates
2023-11-01 19:13                 ` Dmitry Gutov
2023-11-02 14:42                   ` João Távora
2023-11-04  9:51                     ` Daniel Pettersson
2023-11-04 10:00                       ` Philip Kaludercic
2023-11-23  6:10                         ` Philip Kaludercic
2023-12-05  8:41                           ` Philip Kaludercic
2023-12-05  9:18                             ` João Távora
2023-12-05 10:59                               ` Philip Kaludercic
2023-12-05 11:29                                 ` João Távora
2023-12-06  3:57                                   ` Richard Stallman
2023-12-06 10:09                                   ` Daniel Pettersson
2023-12-06 12:30                                     ` Eli Zaretskii
2023-12-06 12:56                                       ` João Távora
2023-12-06 13:08                                         ` Eli Zaretskii
2023-12-06 13:38                                           ` João Távora
2023-12-06 17:00                                             ` Eli Zaretskii
2023-12-06 23:03                                               ` João Távora
2023-12-06 23:55                                               ` Daniel Pettersson [this message]
2023-12-07  7:13                                                 ` Eli Zaretskii
2023-11-04 13:46                       ` Adam Porter
2023-11-04 14:01                         ` Eli Zaretskii
2023-11-04 14:24                           ` Philip Kaludercic
2023-11-04 15:06                             ` Adam Porter
2023-11-04 15:27                               ` Philip Kaludercic
2023-11-04 14:53                           ` Adam Porter
2023-11-04 15:14                             ` Eli Zaretskii
2023-11-04 19:15                               ` Adam Porter
2023-11-04 23:21                       ` João Távora
2023-11-07 10:19                         ` Daniel Pettersson
2023-11-07 10:40                           ` João Távora
2023-11-08  8:31                             ` Daniel Pettersson
2023-10-19 15:12         ` Philip Kaludercic
2023-10-19 17:50         ` Björn Bidar
2023-11-01 16:50         ` Philip Kaludercic
2023-10-15 13:55 ` Mauro Aranda
2023-10-17 20:39   ` Daniel Pettersson
2023-10-20  5:49 ` Milan Glacier

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to='CAM-j=qtQv1aNvJ3hOEKNnLeqeq=WpfP_M0qmdTcddr6=zi0aUg@mail.gmail.com' \
    --to=daniel@dpettersson.net \
    --cc=adam@alphapapa.net \
    --cc=dmitry@gutov.dev \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=joaotavora@gmail.com \
    --cc=john@yates-sheets.org \
    --cc=krister.schuchardt@gmail.com \
    --cc=philipk@posteo.net \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).