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 23:03:57 +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> <835y1b4673.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="20667"; 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 Thu Dec 07 00:05:06 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 1rB0wz-00054v-89 for ged-emacs-devel@m.gmane-mx.org; Thu, 07 Dec 2023 00:05:05 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rB0wF-0007uP-My; Wed, 06 Dec 2023 18:04:19 -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 1rB0wD-0007uD-Ar for emacs-devel@gnu.org; Wed, 06 Dec 2023 18:04:17 -0500 Original-Received: from mail-lf1-x12c.google.com ([2a00:1450:4864:20::12c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rB0wA-00072Q-GM; Wed, 06 Dec 2023 18:04:16 -0500 Original-Received: by mail-lf1-x12c.google.com with SMTP id 2adb3069b0e04-50bf8843a6fso62787e87.0; Wed, 06 Dec 2023 15:04:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701903852; x=1702508652; 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=5YCMgMQtcYSvb3U9eqwRKuWoh5HKZ84kMdiAmSWA7us=; b=cVn60bJGozF7eJwuJczEjrCREqksYeGH+eOu/RVD6wdrwi8eU1LhQ5nuvjD8XIqjOf NYBMgZXXFNME/fsLTWPFnNaxn7erBEjI+6PW34Wq+FNASj9uozvb54b/xLRM+ENPDPr8 oP/0fBBDYo6nPfe4GTMnjUpNgxljmt7Z+GwbX1slpHiT5Fj9+rgeqgVLpPyFkxP9B3hc cvyQ6mzKaXMPy/pT3QVxS+nMS7mqCwUiCkWxeb/DBMBBVVYbCQ/iFSMoL2jsG24HsYPm I6JQKL6ZRBxRj9g3vcScDA8Wyb2GcrzEkDHC2EviQBO1SDh94MInUcIkZS49cZLf0vBo chrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701903852; x=1702508652; 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=5YCMgMQtcYSvb3U9eqwRKuWoh5HKZ84kMdiAmSWA7us=; b=hGGzDIStUPGtizC3jX5N8WwgI5Kbhz1+Nq3I4iifzgK4PuBHp2wVNkXXwd0p0B+5Sq m9zSz2N/IJ9L6x2Ag6miYXvjVNyOODGB3+E4BtpAtW7JnoS7/4ZJ8CYUvKGuNIPBuerE 2MLgORV+AycARPD1saVF9vAwFGgo3KOnMAVUoxKNCQX09bXP2JUjgcDbWrZL3SWiV9lv CiOnoUgZb/HtpIQaV8ogBk+Q87oSlco/wNEYKtg0KAy54vVYtWRTNtcnhWNDmpGzjLeh QSIJYEjmIP/7TuvFL2lCxpv82jbmSWtQQqfMOvjFZYW0hN2UwhXBEl0CPbrT0MWCMmnp UOSQ== X-Gm-Message-State: AOJu0Yx56IIjSvId2yB6c6ng/kiQWmIJ3M6PIwcJRFj4oQeGfZVupRaY YBzGuvSWvwTGpEy8LOrsHUnfs5dDi/cNTKhJQMGQrzZvfzE= X-Google-Smtp-Source: AGHT+IEmGR0kJw/LyoXLd510gy3rr7Exk7JSsCgF4CzG0Sa2jp0iigJO48ZndHvJMUmme5x1ey9N3E0bRuChrNc2DcE= X-Received: by 2002:a05:6512:688:b0:50b:fcd3:95d1 with SMTP id t8-20020a056512068800b0050bfcd395d1mr1176781lfe.19.1701903851314; Wed, 06 Dec 2023 15:04:11 -0800 (PST) In-Reply-To: <835y1b4673.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::12c; envelope-from=joaotavora@gmail.com; helo=mail-lf1-x12c.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:313574 Archived-At: On Wed, Dec 6, 2023 at 5:00=E2=80=AFPM Eli Zaretskii wrote: > > 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. Who proposed "ditching"? If a much nicer general free software UI appears that supports GDB perfectly, does everything gdb-mi.el's does and more, and yet also supports DAP, it seems nonsensical to me not to want gdb-mi.el (and why not edebug.el) to use it. > > > > But that doesn't help when reusing the UI of gdb-mi.el to talk to n= on-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/implemento= rs/adapters/ > > I know the list. I was asking which of them we'd need to support, and > why? All of them. DAP is like LSP. Eglot supports all LSP servers and Dape supports all DAP debuggers. > 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. No, that's not a good analogy at all. Noone is advocating for making GDB/MI support DAP. If anything, I (and others?) suggested that some existing debugger interaction code could be lifted from existing debugger UI's in Emacs (gdb-mi.el, gud.el, edebug.el, etc) to be reusable by all these debuggers, along with Dape. Much like Flymake, Xref, Eldoc, Imenu etc UI can be used by many other extensions, along with Eglot. Tangentially, despite not being a good analogy at all, it wouldn't be very hard to move Eglot to that other imaginary LSP not based on JSON at all. Eglot deals with plists as the representation of structured output. jsonrpc.el knows JSON things, Eglot barely. > 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. That's a self-fulfilling prophecy: it has none of these because things like breakpoint management in Emacs are not generalized in a way that allows plugging in. It's as if ElDoc had stayed heavily Elisp-centric and async-incapable. Then there would be no good place for Eglot to plug itself in for at-point documentation purposes. But we changed ElDoc for the better and now both Elisp and Eglot take advantage of that UI. > > 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? Breakpoint setting and management, thread display, stepping, data examination, debugger-specific window management, etc. Synchronizing these things between Elisp presentation and backend debugger objects don't seem a trivial thing to me, but then again I've never had to implement them. If they are trivial to you, that's great I guess. I'll take simpler over complicated any day. Anyway, I'd just like to state here that I just entered this conversation to clarify something about DAP support in GDB. In particular, and detecting some defensive tones here, I'd like to state that I have 0 intention to undermine gdb-mi.el, gud.el or GDB (my favourite debugger, though not thru Emacs) in any way. I won't speak for Daniel, but I would guess he also doesn't have this intention. Finally, I have no indication that it's actually worth the trouble to do the lifting I suggested, or that it's worth looking into right away. I merely suggested it should be taken into consideration and not hastily written off. This is just good software architecture practice in my book, a book I won't impinge on the gdb-mi.el maintainers or anyone that doesn't want to read it. I've had a look at dape.el and it looks very well programmed except perhaps for the part where it doesn't use jsonrpc.el and thus can't benefit from its primitives. But that is not the programmer's fault, since DAP is similar but not quite JSONRPC and I not have yet published the changes in scratch/jsonrpc-things that would make such use possible. And that is the part that I'm working to enhance. I haven't given much thought to its UI. Jo=C3=A3o