From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Adding support for xref jumping to headers/interfaces Date: Tue, 28 Nov 2023 02:18:19 +0200 Message-ID: References: <87il697r5g.fsf@catern.com> <87r0kw8nxu.fsf@catern.com> <3fe5a8cd-b355-d7eb-10ad-8846aef3387b@gutov.dev> <878r6mx1xc.fsf@betli.tmit.bme.hu> <90e4b9a7-3b51-587d-e317-b89e5d5464d9@gutov.dev> <87sf4scxax.fsf@betli.tmit.bme.hu> <77500777-aea2-14db-4aab-7a5dff43443b@gutov.dev> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19542"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: Felician Nemeth , Spencer Baugh , emacs-devel@gnu.org, Eshel Yaron , John Yates , Ergus , Filipp Gunbin To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 28 01:19:31 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 1r7lp3-0004rM-1y for ged-emacs-devel@m.gmane-mx.org; Tue, 28 Nov 2023 01:19:30 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r7lo6-0003Aj-Cw; Mon, 27 Nov 2023 19:18:30 -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 1r7lo5-0003AK-0x for emacs-devel@gnu.org; Mon, 27 Nov 2023 19:18:29 -0500 Original-Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r7lo2-0000Qi-HO for emacs-devel@gnu.org; Mon, 27 Nov 2023 19:18:28 -0500 Original-Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 929705C0266; Mon, 27 Nov 2023 19:18:25 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 27 Nov 2023 19:18:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1701130705; x=1701217105; bh=J+O7eD37XvbBcmZoX+ZIvdKe41G4BiaN/e0 josD0hXE=; b=NhjNToMc+Ro5nuBWpguMLRB6GZblBDPEZ1kuyKru2AvsLok18sg U+OT2lIpV8WpphBGWaF7yhtKXoTSvbceH8g2KO+Co2nujl0xSrpk6eNcAGP37ilC MoJRqqjN19oUS50A1NSgpQI0k2mDUKe4l/aVST09x53g0D680AOwHjzbU13A6IIS Wa+j8WgM5dDYxx/Sh/sC4kA+66b/MOGIH8NYQISh/x9JEa3d1AhhgLtjpS3g533I 475eDW2jJ/ZTQI2xNWMkPskOHoMwD0n3Da06MJRsZs8eILMA7GQr+zjPAuLw8stg msB9cqHn/73KtL7924P83PLU2fJGEaKWFmA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1701130705; x=1701217105; bh=J+O7eD37XvbBcmZoX+ZIvdKe41G4BiaN/e0 josD0hXE=; b=JOrJiAI81+LH2wAq5gF7JKISrGWBxX7Kxw9HSCNkw0f8j8DKLk/ QXrXY4QCUc0Bm8fbJeNcJ78xz2RbsQImr+jboIel+eFtZV2jE+7UzE7n6iY/mQyQ 4ZQ0webmdL7WLOJ+pKFtUQfAcJxk855L6yCZ8XVR686Vq4mIF//nMgXfN4Gd9stj Q3PIS+Cbt7m4+lcgXL5ULb/VchVVhkeElTJgkVoB4s3boNOfDlOuSAlz74lfBVaR szLy9BdOha8zwueaFfiRDv0XFlyDMihoSNd4meWzj3k9pbm8cnZzjQcsiedt4C97 +GqWw05B7QJPwEa/XTCUB8wqf2ndoKM/ZaA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeivddgvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhephfffheeljeffgeffueeghfekkedtfffgheejvdegjeettdduheeufffggfef jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Nov 2023 19:18:23 -0500 (EST) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=66.111.4.25; envelope-from=dmitry@gutov.dev; helo=out1-smtp.messagingengine.com X-Spam_score_int: -46 X-Spam_score: -4.7 X-Spam_bar: ---- X-Spam_report: (-4.7 / 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, NICE_REPLY_A=-1.857, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-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:313303 Archived-At: On 27/11/2023 17:19, João Távora wrote: >>> Alright, so since this is contentious (who else but you is pushing >>> this idea?) >> >> Indeed, I wonder if nobody else is interested in having the additional >> commands have pre-defined bindings, or having the same bindings across >> languages. > > Of course if you put it like that then EVERYBODY is interested in that. > Everybody likes consistency, but this consistency you're proposing > is a mirage. An naive Xref user would be very proud to use > "xref-find-declaration" in 3 different languages but then would > start to doubt xref that the things he and the backend author meant > by declaration are entirely different. It's not like things are very different now: a backend might fail to implement "references", or the new "kinds" thingy, leaving the most recent addition not working anyway. Or, again, different languages might have different notions for what a "definition" is. E.g. C vs. TeX. > Again, leave this to major modes, which is what we always do (or to backend > which in 95% of cases would live in the major mode when they are > language-specific). I wonder where you're getting this statistic from: advanced language analysis features don't usually live in major modes, not in the current state of the Emacs ecosystem. >>> what about we start with 0 in xref.el. We can always >>> add to 0, no problem, but taking away from some other number >>> isn't so easy. >> >> We could indeed start with 0, but then I already see the same set of >> extra commands supported in Eglot, Elisp, lsp-mode > > They only exist in Eglot and LSP-mode because these are LSP things, > it makes full sense they would exist in any Emacs/LSP interface. Before LSP, they would similarly make sense for eclim, or omnisharp, or rtags/irony-mode, and etc. And that would be the case after LSP, unless the current crop of popular languages is simply washed away. We might have taken the names from LSP where they're nicely categorized, but they correspond to existing navigation features in IDEs that's been there for years. > Elisp? What commands are you talking about, only if you force them. > I see no elisp-find-{declaration,type-definition,implementation} > or anything of the sort. > > The 7 Elisp cross-reference kinds you defined in your original > patch are > > "defalias" > "face" > "function" > "constructor" > "generic" > "variable" > "feature'" That's a good critique. But the list above is a different ontology than the declaration/implementation/type-definition "drawers" we were talking about. I wonder how much of it really language-specific. E.g., a C++/Java/Ruby program also has symbols like modules/namespaces/classes/methods/functions... Variables, too. Some have global ones, some allow one local variables. What makes the drawers called declaration/definition/implementation/type-definition different? I think that these ones, in many cases, apply several at once to the same symbol, and not just the same name, but the same entity in the code, such as for example a method -- one method can have a declaration and an implementation (which is these are the "definition" -- perhaps both -- is up to interpretation). Or a variable can have a definition (or declaration -- for variables they're usually the same) -- and a type definition. Point is, there is no way for the Xref backend to decide which of these you want to see when invoking "M-.", that's why there are separate actions for them in the protocol. Whereas for Elisp's defalias/face/function/constructor/generic/variable/feature, 95% of the time the choice is easy to detect from the usage context. Same for modules/classes/methods for Ruby or C++. That's actually the reason why I felt my implementation for Elisp's "kinds" was useless -- it's simply slower and more awkward to work with than the existing 'M-.' (which has the automatic "infer namespace" functionality since 2021 courtesy of Mattias). So we could also say that declaration/definition/implementation/type-definition are the names of "search actions" whereas namespace/class/face/function are "symbol namespaces". And to make interaction with "symbol namespaces" more useful, I'm guessing we would need something more - e.g. namespace-specific symbol completion. For xref-find-all-definitions (or whatever new name it has) to prompt for the namespace first and then fetch its specific identifier completion table (all functions or all faces, etc). And that, by the way, could also work in different languages, with very similar nomenclature (I think only "face" in the above list is really Elisp-specific). I concede that the "search actions" such as find-declaration/implementation (and especially type-definition) are less useful in Elisp than in OO languages where inheritance (or at least traits/mixins) are used more widely. Maybe just for the cl-generic code, which is a minority. OTOH, perhaps they would be more relevant in CL? >>>> and to allow frictionless extensions for special capabilities. >>> >>> As to frictionless extension, the macro I proposed already >>> xref-define-finder seems the easiest way by far. >> >> Sorry, I can't find it. >> >> But the definition of xref-find-declarations takes about 3 lines. There >> is not much potential for making it even shorter. > > It's very similar and analogous to: > > (defmacro eglot--code-action (name kind) > "Define NAME to execute KIND code action." > `(defun ,name (beg &optional end) > ,(format "Execute `%s' code actions between BEG and END." kind) > (interactive (eglot--code-action-bounds)) > (eglot-code-actions beg end ,kind t))) > > And allows us to control exactly the 'interactive' spec of such > commands to give us consistency among them. I'm wary of using macros as framework/library interface in Elisp because unless they are very stable, they can cause versioning problems when upgrading or reverting to an earlier version. You change a macro, but a dependent package is already installed and byte-compiled, and there won't be a recompilation until its next update. We might not even intend to change them much, but then you don't always anticipate a bugfix.