From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: James Nguyen Newsgroups: gmane.emacs.bugs Subject: bug#30151: Debugger API Date: Fri, 19 Jan 2018 01:25:47 -0800 Message-ID: <1516353947.1372266.1240815736.7C68AE47@webmail.messagingengine.com> References: <1516251398.1364994.1239356432.7334F1AF@webmail.messagingengine.com> <83shb3ut4j.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1516353889 25026 195.159.176.226 (19 Jan 2018 09:24:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 19 Jan 2018 09:24:49 +0000 (UTC) Cc: 30151@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jan 19 10:24:44 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ecSuN-000539-AO for geb-bug-gnu-emacs@m.gmane.org; Fri, 19 Jan 2018 10:24:23 +0100 Original-Received: from localhost ([::1]:37586 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ecSwN-0004Vb-FH for geb-bug-gnu-emacs@m.gmane.org; Fri, 19 Jan 2018 04:26:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37063) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ecSw2-0004KO-GZ for bug-gnu-emacs@gnu.org; Fri, 19 Jan 2018 04:26:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ecSvz-00019X-0e for bug-gnu-emacs@gnu.org; Fri, 19 Jan 2018 04:26:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54377) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ecSvy-000199-T0 for bug-gnu-emacs@gnu.org; Fri, 19 Jan 2018 04:26:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ecSvy-0000ak-HA for bug-gnu-emacs@gnu.org; Fri, 19 Jan 2018 04:26:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: James Nguyen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 19 Jan 2018 09:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30151 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 30151-submit@debbugs.gnu.org id=B30151.15163539512255 (code B ref 30151); Fri, 19 Jan 2018 09:26:02 +0000 Original-Received: (at 30151) by debbugs.gnu.org; 19 Jan 2018 09:25:51 +0000 Original-Received: from localhost ([127.0.0.1]:34041 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ecSvn-0000aI-09 for submit@debbugs.gnu.org; Fri, 19 Jan 2018 04:25:51 -0500 Original-Received: from out1-smtp.messagingengine.com ([66.111.4.25]:58125) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ecSvk-0000aA-D0 for 30151@debbugs.gnu.org; Fri, 19 Jan 2018 04:25:49 -0500 Original-Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 094D420DC8; Fri, 19 Jan 2018 04:25:48 -0500 (EST) Original-Received: from web4 ([10.202.2.214]) by compute7.internal (MEProxy); Fri, 19 Jan 2018 04:25:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jojojames.com; h=cc:content-transfer-encoding:content-type:date:from :in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=XpoJj2AqzBGCd+5mR nnfUKjEEphGs20JZffW3DXFuGc=; b=ZKIacTTjbCXAqJDGrm1ILqZQvdCbCmCMA v834TEzcKRHKQqeA/9qGggn9i1LcVYoUPRrj0W1qqqzd+03M/+BhY3H/g4F6gwpZ Q13sT/pWd2Tyn0oDpgoimVmCJTz8EYgqJKpevCinguHmzs7mzNBvVFb5gipXJs3I OnghFoBxG3Z33GmE0HRcmFxyNFliXTOhg0gJZpG9e+3L8fgZB1ZCWYWDCkLeMFh6 p9Gvw508X6t5uppPGsMrr0mkPI2mkURYghw18c/paGpOpElCkytMV0BMCvskFxu4 7lFqE75TpHnqQ2ZyxP5ChS+5rq5CEVtXVjBqLfLD5fTA1YGNy1jaA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=XpoJj2 AqzBGCd+5mRnnfUKjEEphGs20JZffW3DXFuGc=; b=VeRGg/1x9HOYgAYg83Deav IZ62JXxNWY/S53KwtHgVCVlF/gzNf4PB7KcwHfFwOFFQ5turN6kp+pSR738vMCrI eEjiSDLx3VITMFlwQMyrI/n7Uc7x1Z3+aj8QKIBidNZ+WZuc8/fgEhtSJ3JCRpBb mmSQzVNK3MkSXQBvxsaBoTWCwa8vHlXENOzKp5wl/fVAiGUH/NAAbOkv5tHdxDHR 2yGLvRW3KblEYR4LIBMy/grKJNMwFgCexk0EkIyMR3eVk2JJcNisVu82LSDjsJeR GqyVh7iNhwi8VgF87UadS9EF2wdF/vR23Due94LJ4Wyn6wPwRmfuccBLf5zpiTkg == X-ME-Sender: Original-Received: by mailuser.nyi.internal (Postfix, from userid 99) id DA885BA1AC; Fri, 19 Jan 2018 04:25:47 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface - ajax-75de3051 In-Reply-To: <83shb3ut4j.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:142290 Archived-At: > Emacs provides an interface to _debuggers_, not to languages. Thanks for the correction, I've been using the two terms interchangeably. > IOW, unlike VS, which is a single debugging engine, Emacs supports > several debugging engines. The closest thing to VSCode's Debugging > API we have is therefore gdb-mi.el -- if you are willing to limit > yourself to those languages currently supported by GDB. I think the 'limited to languages supported by GDB' might be somewhat limiting. > So I'm not sure I understand your idea well enough to answer your > questions in a useful way, at least not if I want to be sure I gave a > complete answer that you can use to decide how to go about this > project. I think what Microsoft has done with their debugger is very interesting in that most of the UI seems to be a single interface and what interacts (debugger adapters) with the debugger can do what it wants as long as it can communicate down to that same interface/UI. It reminds me of their approach with their language server protocol. > Can you elaborate on your idea given the above > considerations? This topic came out of a few things I've tried in the past. First I tried using GDB on OSX but it seems GDB can't be used on OSX anymore due to some system limitation. So I looked for LLDB gud integration. I found one but setting breakpoints only sets them in the debugger and not visually (i.e. red breakpoints in the fringe) like in gdb-mi? or realgud. I was able to hack up the visual breakpoints but stopped when it seemed to be too messy (straying from the well-trodden path). Next, I tried pdb (I believe that's the python debugger) but it had the same minor problem of not drawing breakpoints in the side panel. It seemed like only gdb-mi~ debugger/languages supported that kind of feature. Taking a look at realgud, the 'visual breakpoint' 'feature' is available. So from there, from a user-standpoint, I just went with realgud for python debugging. Fast forward to now, I'm trying to add a debugger integration as I use new languages, I'm back into looking at whether or not to use realgud or gud-def or roll my own. Some that come to mind that probably don't use gdb are Typescript, Clojurescript, Elixir/Erlang so it might be a mismatch with gud. I don't really know. At the moment, I'm interested in Typescript/Clojurescript support, probably interfacing with Chrome. And/or a working LLDB integration. Maybe there's just a gap in functionality between gud and gud-mi interface (sorry if I'm butchering the terms). Ideally, it'd be nice to have something simple that asks me: 1. Where to draw breakpoints in the buffer. 2. What locals exist and displaying them in some kind of 'locals' buffer. 3. Maybe an extra window that will display extraneous information (similar to jdibug's stacktrace buffer) 4. I'm missing some other common functionalities between debuggers. I think some/all of ^ is very similar to gdb-many-windows but I've only ever seen that for *just* gdb. > I cannot tell why packages you mentioned that support debugging roll > their own; perhaps the respective package developers could chime in > and explain. Yes! That would be clarifying. I hope those developers read this email chain. Thanks. -- James Nguyen james@jojojames.com On Thu, Jan 18, 2018, at 6:41 AM, Eli Zaretskii wrote: > > From: James Nguyen > > Date: Wed, 17 Jan 2018 20:56:38 -0800 > > > > I've been meaning to look at how to implement a debugger for Emacs for various languages. > > > > There seems to be various options to go with (realgud, gud/gud-mi?, NIH roll my own) and it seems the community chooses different paths (including not writing one at all). > > > > Some debuggers that come to mind are: edebug, gud-gdb, realgud, cider, indium, jdibug with a varied feature set. > > > > I'm curious if it makes sense (or is doable) to have something similar to flycheck/flymake but for debugging (or like VSCode's https://code.visualstudio.com/docs/extensionAPI/api-debugging) so that there's a common interface to writing a debugger. > > Emacs provides an interface to _debuggers_, not to languages. For > example, you can debug any language supported by GDB using gdb-mi.el, > but will have to use "M-x pdb" (defined in gud.el) for Perl debugging. > > IOW, unlike VS, which is a single debugging engine, Emacs supports > several debugging engines. The closest thing to VSCode's Debugging > API we have is therefore gdb-mi.el -- if you are willing to limit > yourself to those languages currently supported by GDB. > > So I'm not sure I understand your idea well enough to answer your > questions in a useful way, at least not if I want to be sure I gave a > complete answer that you can use to decide how to go about this > project. Can you elaborate on your idea given the above > considerations? > > > gud-def looks to be the closest thing but it seems somewhat low level given it doesn't draw breakpoints on screen (random example) or provide something like a 'locals' view. > > > > If gud-def is the recommended approach, I wonder why the other debuggers (list mentioned above) don't leverage it. > > gud-def (and gud.el in general) is supposed to be the extensible > debugging interface, yes. However, the capabilities it can provide > depend critically on what the is supported by the underlying debugger. > E.g., displaying breakpoints requires that the debugger could be > queried about the location(s) of each breakpoint, and that it returns > the results of the query in a way that Emacs can unequivocally parse. > > I cannot tell why packages you mentioned that support debugging roll > their own; perhaps the respective package developers could chime in > and explain. > > Thanks.