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 15:08:42 +0200 Message-ID: <83bkb34gx1.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> 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="14894"; 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 14:09:37 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 1rArej-0003gI-Gh for ged-emacs-devel@m.gmane-mx.org; Wed, 06 Dec 2023 14:09:37 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rArdr-00020r-EC; Wed, 06 Dec 2023 08:08:43 -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 1rArdk-0001ys-Vw for emacs-devel@gnu.org; Wed, 06 Dec 2023 08:08:38 -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 1rArdi-000589-By; Wed, 06 Dec 2023 08:08:35 -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=GvUbhkEtulPthp9fxm/GnXJnML7MLsWV/GpmAYcOKDE=; b=N5rW9k+WtCY8mqUyPPps HdlGhhAUIHJIcmSKhlvZ3UFQICJxPT3lqxJgxO4oRhkgLX+KBmYJWH9jIzdB8W0PhMjd3II/WVmuh SOZOk+aOzYD1iK6buuRa8OnriFMyKXaWXPQtb4qIFZlb7T49AUby+TBo4dlHQ8IL/l7p4dDI2aZPt b3vb3EwH39Q6xeR99jiZO+u0Wvk3G2Jt4I/q6xxlEdpVhjfge8kRGWy/o76ll9NWb6vvViuwFr6H1 qUH5FeKp23gfSVzyt8psOZAO+RbfWu0kH3Y1tjR1yWNLh2ZHxBGjHfQFtXTUlZ6/QiQw/6ud+qemO zMvPCZ4cYgPPRQ==; In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Wed, 6 Dec 2023 12:56:12 +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:313558 Archived-At: > From: João Távora > 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? > But that doesn't help when reusing the UI of gdb-mi.el to talk to non-gdb DAP debuggers. Like what? > And that > interface reuse (which would be a great thing if it were particle and clean, 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.