From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] New package: dape Date: Wed, 06 Dec 2023 19:00:16 +0200 Message-ID: <835y1b4673.fsf@gnu.org> References: <46ea1ab1-e447-4c83-9c81-2f9bd149fe91@alphapapa.net> <6964ff20-921e-beff-43a0-9570ea79aa7d@gutov.dev> <87h6m1yh1x.fsf@posteo.net> <87ttpd2e53.fsf@posteo.net> <87bkb5jb1q.fsf@posteo.net> <8734wgj4p5.fsf@posteo.net> <83il5b4ioj.fsf@gnu.org> <83bkb34gx1.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37937"; mail-complaints-to="usenet@ciao.gmane.io" 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 To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 06 18:02:47 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rAvIN-0009gw-26 for ged-emacs-devel@m.gmane-mx.org; Wed, 06 Dec 2023 18:02:47 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rAvFs-00012Z-02; Wed, 06 Dec 2023 12:00:12 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rAvFo-00011m-SK for emacs-devel@gnu.org; Wed, 06 Dec 2023 12:00:09 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rAvFm-0007hL-W1; Wed, 06 Dec 2023 12:00:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=zxwKCtzsw7jztFReIKHnojKOED8ndFjLOYEiNAcdBZw=; b=EjVLwm6Dkt1uLS/xPlsQ gy/YVSfsQUYPZkPilkufWZncnrZ+4f5BbxXyF6+CdcIwuqDdUUeDZMzTxTnZrE3A4XLznpyU+GiM4 9ENnkTQd8jQlT2qPeDgHR4J5sCIvhIyg4kc80m4JsNjMZwJrehUGwsoT11+rbCKIOJ6Xpjk3REm0e 4bMweE8/fzLkIGtRTxAGsqa21/J3IwuCRccy9/nL8NDUGOnN+IepZyNpGiomqx0FTEN9FPYBn/Hpl Mo3Tr7JlAY5/9mrQPcDo2Twj8ScoIqxwiuJwE8xZEj3fqAYeCb82MVp+avJvLaXyie920k4BxDFuH C5MdO007NqINAg==; In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Wed, 6 Dec 2023 13:38:54 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:313564 Archived-At: > From: João Távora > 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?