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, 7 Nov 2023 04:12:50 +0200 Message-ID: <65a16247-1b1a-149c-b413-71612f88f184@yandex.ru> References: <83pm9sfxfa.fsf@gnu.org> <861qm4tkih.fsf@stephe-leake.org> <71ea5e83-183f-2ae3-8146-6a31045a0309@yandex.ru> <834jqzafse.fsf@gnu.org> <83h6uv47e8.fsf@gnu.org> <4639d7ca-2109-864c-33c0-38e65f26f262@yandex.ru> <835ybb3txt.fsf@gnu.org> <83wn3q311i.fsf@gnu.org> <412afa2d-5dbc-52da-39c4-99be3873929c@yandex.ru> <83o7p20wdi.fsf@gnu.org> <72b09256-5a1b-8962-9e3c-7d2ffd0dc0d7@yandex.ru> <83ilf925n8.fsf@gnu.org> <95afa441-18ae-e62a-be16-be73a545bbba@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25312"; 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: Spencer Baugh , Eli Zaretskii , stephen_leake@stephe-leake.org, john@yates-sheets.org, rms@gnu.org, fgunbin@fastmail.fm, casouri@gmail.com, emacs-devel@gnu.org, azeng@janestreet.com To: Eshel Yaron Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 07 03:14:20 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 1r0Bbg-0006So-OM for ged-emacs-devel@m.gmane-mx.org; Tue, 07 Nov 2023 03:14:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r0Bac-00074m-Kx; Mon, 06 Nov 2023 21:13:14 -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 1r0Baa-0006yp-Gp for emacs-devel@gnu.org; Mon, 06 Nov 2023 21:13:12 -0500 Original-Received: from forward502a.mail.yandex.net ([178.154.239.82]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r0BaW-0007op-Jg; Mon, 06 Nov 2023 21:13:11 -0500 Original-Received: from mail-nwsmtp-smtp-production-main-31.vla.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-31.vla.yp-c.yandex.net [IPv6:2a02:6b8:c18:3b87:0:640:4625:0]) by forward502a.mail.yandex.net (Yandex) with ESMTP id E0A8660CDF; Tue, 7 Nov 2023 05:13:00 +0300 (MSK) Original-Received: by mail-nwsmtp-smtp-production-main-31.vla.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id uCR8iwrWnKo0-ZO17rOYo; Tue, 07 Nov 2023 05:13:00 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1699323180; bh=GoPm80MLws2xCy9MowsCuX7B+KpELWN6K6QcX8Sk3F0=; h=In-Reply-To:From:Subject:Message-ID:Cc:References:Date:To; b=h0bsRnCrN/rhuV7hmTGRFdDcN0aGOvAAtTwq6hARfjh6F/28baMzU8NwXBydXQgJv 8bxOujprplfnm4G1M5+Xes3d3XNrbzNy6T1DCpdjS382w+WNoPjChJWrbysNKd71VW NqfZBfS/ZUyeRmkPg4VzMdNJpt5s6Qp72YERemYA= Authentication-Results: mail-nwsmtp-smtp-production-main-31.vla.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Original-Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailauth.nyi.internal (Postfix) with ESMTP id 2616D27C0054; Mon, 6 Nov 2023 21:12:55 -0500 (EST) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Mon, 06 Nov 2023 21:12:56 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudduhedggedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegughhuthhovheshigrnhguvgigrdhruheqnecuggftrfgrth htvghrnheptdffgeegkeelteevtdekleethfeftdduvdegkedtkedujefhfedtveeftdff udevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hguhhtohhvodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqddufeeffeelleeh hedvqddvleegjeejjeejiedqughguhhtohhvpeephigrnhguvgigrdhruhesfhgrshhtmh grihhlrdgtohhm X-ME-Proxy: Feedback-ID: ib1d9465d:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 6 Nov 2023 21:12:52 -0500 (EST) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=178.154.239.82; envelope-from=dgutov@yandex.ru; helo=forward502a.mail.yandex.net X-Spam_score_int: -51 X-Spam_score: -5.2 X-Spam_bar: ----- X-Spam_report: (-5.2 / 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, NICE_REPLY_A=-3.085, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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:312279 Archived-At: Hi Eshel, On 05/11/2023 10:16, Eshel Yaron wrote: > Thanks for working on this feature. I'm looking forward to using it. Thanks for testing! Just to be clear, it's an experiment so far, to try to determine the best direction to go with. Whether it will be a new command, or several, or augmentation of some existing one(s). > Dmitry Gutov writes: > >> Attached is the patch along the lines that we discussed: a new command >> xref-find-extra currently bound to M-' just for the sake of this >> experiment (eliminating the need to set up define-key to try out the >> "fast" workflow). > > That's was indeed convenient for testing the patch, although in the long > run there should probably be a different binding since `M-'` is already > bound to `abbrev-prefix-mark`. Honestly, it's a pretty obscure command, and the binding is nice. Anyway, it's not a given we'll have a new command like this, so there's no point in discussing bindings too early. >> It uses the symbol at point or asks for it, then >> polls the backend for available kinds, > > So far so good. > >> does completing-read and asks the backend for definitions of that >> kind. And shows the list or jumps to the unique one. > > Personally, I would prefer a `read-multiple-choice` alternative to > `completing-read` here, that would allow me to select the "kind" with a > single key press. Since there are rarely more than a few kinds to > choose from, in many cases `completing-read` introduces unnecessary > friction. Ideally, the backend should be able to choose whether to do a > `completing-read` or a "quick" `read-multiple-choice` on a case-by-case > basis. People override completing-read using modes like icomplete-vertical-mode, but there are no popular augmentations for read-multiple-choice. Also, sometimes the types will start with the same characters, and sometimes not. Just using completing-read at least provides a stable UI for all cases: if you remember the type, you can input the first part of the name without thinking and press RET. > The backend can also associate stable `read-multiple-choice` > keys to the different kinds it support. WDYT? Perhaps you are instead thinking of a solution when there is a stable keymap with known commands assigned to the same characters. >> To have something to test, I implemented this for Elisp. However, all >> known kinds are already printed by the regular xref-find-definitions >> output in that backend. So the result turned out interesting, but a >> little impractical: with Elisp, we already make the choice between the >> kinds in the Xref output buffer, when that buffer is shown at all (as >> Eli pointed out, actually). So... we could proceed in that direction >> and recommend that all kinds of definitions would be added there. > > Yes, I've noticed that redundancy of sorts while testing this patch, but > I think that selecting the definition kind explicitly with this new > command still provides a distinct experience compared to the > `xref-find-definitions`. Yes, but is it better? Does it bring much to the table? For Elisp, my own answer is "probably not": all the kinds are available in xref-find-definitions, and the selection UI is adequate already (isn't it?) But maybe it will be more useful for some Eglot languages, specific contexts and specific "kinds" to search for? >> But let's try to answer the question: which workflows would the >> attached approach work better for? > > My above suggestion to provide "quick kind selection" with something > like `read-multiple-choice` would also be a general advantage here. > >> Or perhaps the main value would be in actually having separate >> commands which could be bound to a submap with faster key sequences >> and/or to the context menu (with context-menu-mode on). > > That's indeed an added value IMO. In that spirit, it might be better for > `xref-find-extra` to take the "kind" as an argument, so we can define > `xref-find-foo` as `(apply-partially #'xref-find-extra 'foo)`. > Interactively, `xref-find-extra` would still pick up the identifier first > and then prompt for the kind. A helper for defining new commands is definitely doable. For that route, though, I would like to ask whether we'll want to define any of them inside core Xref. And if not, then where would those definitions reside. >> Please try out the attached (with implementation for Eglot hopefully >> coming soon) and let me know your thoughts (you all). > > One issue I had was with selecting "feature" as the definition kind. > Basically it doesn't seem to work for some reason, so for example typing > `M-' isearch RET feature RET` says "No extra-defs found for: isearch". That's just a missing mapping inside xref-backend-extra-defs, I didn't want to spend too much time polishing the prototype. > Also, for minor mode names, we currently suggest both "function" and > "variable" kinds, but they both point to the same `define-minor-mode`. > Ideally, we'd unify the two and simply suggest "minor-mode" as the > definition kind. Also easy enough to do, e.g. by borrowing the solution from elisp--xref-filter-definitions. Still, though. It's not clear to me that improving this particular feature for Elisp will bring a lot to the table. Does it really do certain things better than simply using 'M-.' and then choosing between all the available definition types inside the buffer (and then navigating to one with TAB)? Or if one prefers a more dynamic interface with completions, (setq xref-xref-show-definitions-function #'show-definitions-completing-read) could fit that bill. There is a tradeoff of not being able to just press a single char, but OTOH one doesn't always know which definition kind they want in advance, and here, the full list helps one make that choice.