From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] New package: dape Date: Wed, 6 Dec 2023 13:38:54 +0000 Message-ID: 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: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19165"; 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: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 06 14:40:17 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 1rAs8O-0004jJ-DF for ged-emacs-devel@m.gmane-mx.org; Wed, 06 Dec 2023 14:40:16 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rAs7N-0000AT-AJ; Wed, 06 Dec 2023 08:39:13 -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 1rAs7L-00008v-Rd for emacs-devel@gnu.org; Wed, 06 Dec 2023 08:39:11 -0500 Original-Received: from mail-lf1-x12a.google.com ([2a00:1450:4864:20::12a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rAs7J-0002oH-UI; Wed, 06 Dec 2023 08:39:11 -0500 Original-Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-50bffb64178so3246303e87.2; Wed, 06 Dec 2023 05:39:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701869947; x=1702474747; darn=gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=+F1RN9XBOZPhlJWep260knQcMB/kGv154ZHliKmI8K4=; b=VmJqZG+8iwLUrY5WLyJMKTbX3lxsfo6mJ1WV5+WcFjCE5ll2bVuVO+PEJSxwsmXAnu 7c7QQje+BoKTT98G2eQJYRizwgmrkeAjT6Pm0m8ZqVv5F4crntK4oJSSoS29biM2CFgb lfKsAzZUZB47jz9sgWz9VGpc9e3DdX2cRD8FIsRuMyBe73bNS2sgFFpSWIooBhfxHOdp QRPt2t/oVZJTBZ06GL3IX8JJYADIA6CpdvY/6eL+Fil3Lyyr8Px0KboceDDQaJB9dcGa 2eOWt6835EnLIKULfdyRouNdo3ZAQ6k9Qtz341xAkoXETBTHZ+woauAREs30LdaL8eZu 3uvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701869947; x=1702474747; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+F1RN9XBOZPhlJWep260knQcMB/kGv154ZHliKmI8K4=; b=KvtrQiuRq149O5F7uKLqMtY9cgsSXVTIXG8fNczEt5SJhnKMdvr4DTolbdic1yWH/T 1FCCnTsz6r/aOh2NnhRiHSPiBaJZM53YgdTR3Pfohy3eVciaiNiAsz26hGOwbnyRexXE EGmDnB1UBlrTqqWX7os80RybJoNTl9GEHmRfnW31p4aKyo5bV7l49EhhVnB3CFQGtrUt K2Vf9eBsNn2nleYc5t6P1oo3MJBzXBcXk4IiqqOHQUB0ctD3lqLiSMsVqs2UIaklrbEZ eBbrmcuUVdr795/egKEX/f6kD9RYKNrZxs1xN//A7iGP55JP9JfabAkBjzibmtQXxdOZ Ec/A== X-Gm-Message-State: AOJu0YyX+t/C4v5X3TTMYE8ByPs6sECOlBeuj0PidKOpOT+UMC01KstB dMJXTG8vMAn8esu3c+9UBjsqGPPb+7flOQcyNqq4tJ9hqHs= X-Google-Smtp-Source: AGHT+IF2Q2RayNgCbO6N+x5SpYsC0xZmgcxY2kxymnKi6EX0R8lOEQkqQUtHiK+9j3ltNP9nav6FQVdJdsz17bVgpYo= X-Received: by 2002:a05:6512:15a5:b0:50b:f803:460b with SMTP id bp37-20020a05651215a500b0050bf803460bmr639865lfb.11.1701869946633; Wed, 06 Dec 2023 05:39:06 -0800 (PST) In-Reply-To: <83bkb34gx1.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::12a; envelope-from=joaotavora@gmail.com; helo=mail-lf1-x12a.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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:313559 Archived-At: On Wed, Dec 6, 2023 at 1:08=E2=80=AFPM Eli Zaretskii wrote: > > > From: Jo=C3=A3o T=C3=A1vora > > Date: Wed, 6 Dec 2023 12:56:12 +0000 > > Cc: Daniel Pettersson , > > "Philip K." , > > Dmitry Gutov , John Yates , > > Krister Schuchardt , > > Adam Porter , emacs-devel > > > > 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-g= db 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/a= dapters/ > > And that > > interface reuse (which would be a great thing if it were particle and c= lean, 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=C3=A3o