[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ELPA] New package: dape
From: |
Daniel Pettersson |
Subject: |
Re: [ELPA] New package: dape |
Date: |
Thu, 7 Dec 2023 00:55:46 +0100 |
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
- Re: [ELPA] New package: dape, (continued)
- Re: [ELPA] New package: dape, Philip Kaludercic, 2023/12/05
- Re: [ELPA] New package: dape, João Távora, 2023/12/05
- Re: [ELPA] New package: dape, Richard Stallman, 2023/12/05
- Re: [ELPA] New package: dape, Daniel Pettersson, 2023/12/06
- Re: [ELPA] New package: dape, Eli Zaretskii, 2023/12/06
- Re: [ELPA] New package: dape, João Távora, 2023/12/06
- Re: [ELPA] New package: dape, Eli Zaretskii, 2023/12/06
- Re: [ELPA] New package: dape, João Távora, 2023/12/06
- Re: [ELPA] New package: dape, Eli Zaretskii, 2023/12/06
- Re: [ELPA] New package: dape, João Távora, 2023/12/06
- Re: [ELPA] New package: dape,
Daniel Pettersson <=
- Re: [ELPA] New package: dape, Eli Zaretskii, 2023/12/07