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: Mon, 27 Nov 2023 17:45:07 +0200 Message-ID: <2fe6c4f0-dffc-ce00-758e-0c431a803d4d@gutov.dev> 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> <9ac758b8-5fb2-9b3d-7947-96777694e3e0@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="22444"; 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 Mon Nov 27 16:46:33 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 1r7dod-0005Zm-PV for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Nov 2023 16:46:33 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r7dnl-0001OE-Ji; Mon, 27 Nov 2023 10:45:37 -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 1r7dnS-0001KR-9m for emacs-devel@gnu.org; Mon, 27 Nov 2023 10:45:20 -0500 Original-Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r7dnO-00062L-DD for emacs-devel@gnu.org; Mon, 27 Nov 2023 10:45:16 -0500 Original-Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 4E9135C02B2; Mon, 27 Nov 2023 10:45:12 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 27 Nov 2023 10:45:12 -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= 1701099912; x=1701186312; bh=47wFQBTjaFtTdJVMyaeQzoZjFaGbfztFJvo RQAK8lgg=; b=PAePY+pzi2LGEZl0KLP68YAbAiJ6ZADuCfGFCRMcRW6zReF9FPi SDc/wiKhXNOyvAQ7v7Xv+feSoY8cA9X80L8/Svph+YZ6S4GsFvGpnHkL1TiSEdWJ pBOGYr79A7gAgO8nbhd5BLN+8++0WBZa/YmHTrnmoniiWVpkJVxaztvTtACHq+rs LdYCVlYTYLA41mvxd/ha8dc+AwHAPYp/3fbmzdkna+lljPXsTNbNrA6p65H1jMYF /Xym7uzcgis5NmksR8XuJYSCuMCMM3evGgdfJtS54Py70HTg6TsyKjytBQtn4nip +nFTanTrDu9SC2n7Lc0W1yG6tRLVcF9TPOg== 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= 1701099912; x=1701186312; bh=47wFQBTjaFtTdJVMyaeQzoZjFaGbfztFJvo RQAK8lgg=; b=XwDtq18XAAd+cnsY3P8XHOcf94CNYe+fpezgsf9rlvri6B7W6pV S/Koq+lIITYPYwBnjDHUu8ee86HriJJKd90/xUnzuQfDzueslzwES2Xf8KVDdHjP O7HyiyczibGdbYtSNKezt57ULU8MWpEEktesdqXEwJPXMVBXSvvr0wWAbz5iCfq6 1Zbl9ovSMIr0vKlR6zvoU5N4ErIPO7d/A94Ir0hcAIKoUIHkrKUUym9cXUGdruBT 50IqaH9dgzNr3ySwEOcWTCQip27dgOptcSoPRAI7fChzSgMNBn8pOPFqqk2AQ5Nz R+YAKlwF++u5Lo4dZ35ZTzmk0K+jaP10Q9Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeiuddgkeduucetufdoteggodetrfdotf 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 10:45:09 -0500 (EST) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=66.111.4.26; envelope-from=dmitry@gutov.dev; helo=out2-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:313277 Archived-At: On 27/11/2023 17:03, João Távora wrote: > On Mon, Nov 27, 2023 at 2:35 PM Dmitry Gutov wrote: > >> But one of the latest emails mentioned a separate Xref backend for c/c++ >> -- should I assume that every such backend would define its own set of >> *-find-* commands suitable for its languages? > > Of course, a cross-referencing backend should know what kind of > cross-references it can find. Eglot knows how to find 3 or 4 different > kinds, language server permitting of course. That didn't answer the above question. To signal "what kind of cross-references it can find", it would define xref-backend-definition-kinds with corresponding return value. > Eglot will never know how > to find "documentation", and I believe the Elisp backend should > never purport to know how to find "declaration", since that's a very > fuzzy concept in Lisp with no accepted meaning. As is > "typeDefinition", doesn't make much sense in dinamically typed > languages (but "declaration" is worse). Dynamic languages have type checkers and inferencers implemented all the time. E.g. There's nothing stopping someone from analyzing a stack of definitions in Elisp, seeing that a variable is either defined with a cl-struct's constructor, or accessed with a cl-struct's accessor, and assuming that struct's definition as its type definition. Same for EIEIO and its counterparts in Common Lisp. In Ruby and Python, we have optional type annotations as well, provided by libraries (Ruby) and the core language (Python). >> Would such backends each come with an automatically-enabled keymap? Or >> would the user have to set up key bindings for every such command, for >> every special backend like that? > > The major modes could do that, for example. They could do it by > linking the backend-created "one key/command" keymap into a special > prefix created by xref.el, doing so by calling a load-time xref.el helper. Okay, so we would create and occupy a new common prefix. But without any commands in it? How do you suggest we advocate for that around here? > So maybe some backends would have d for "documentation" and others would > have d for definitions, so what? Maybe that's precisely what a user working > on a documentation heavy system expects "d" to do. And if these two backends > happen to be enabled simultaneously, even this conflict could be > resolved, by adjusting the keymap during the linking process. That's easily solvable in other ways. First of all, xref-find-definitions is bound already, and I'm sure text-related backends have its own "things" found by it, ones that you wouldn't readily call "definitions" (there was a bug report related to LaTeX not too long ago about a situation like that, IIRC). But if you wanted to take "d" from "declarations" instead, then, with core Xref commands it's easy to override. Something like: (define-key well-learned-mode-map [remap xref-find-declarations] #'well-learned-find-special-documentation) With the benefit that a known key binding is used. > But however this works, I think the bindings issue is completely > secondary. Secondary not in the sense that it's less important, > but in the sense that we don't have to commit to something right > now, so I don't understand the tortuous route this feature is taking into > what-if territory. If we don't have built-in bindings (or a prefix map), we miss an opportunity to make life for Xref backends' implementors easier. But indeed, it could be deferred. But another issue is that if we drop the commands, we lose the fastest way to access the definitions for each kind OOtB. Then we're back to discussing how the new command which allows accessing different kinds (the unlimited set) could be made faster/more predictable than just using completing-read. E.g. with a customizable registry of key->kind mappings. And I didn't just invent the need for faster interaction by myself - just look at the first responses to the prototype. Okay, perhaps some power users in this thread don't mind adding personal tweaks to their config to speed things up. But that means the OOtB experience will be lacking. > So whatever solution we find to the bindings issue (if it is indeed > an issue) > > It's much more pressing to decide if/why you want a command named > xref-find-all-definitions to return things that aren't "definitions" > by any measure or what is pressuring us to enshrine > "declaration/implementation/typeDefinition" in one of our > most generic libraries. It's a framework, not so much a library. Although it has the latter's capabilities too. As a framework, we should consider what the end user experience would look like.