From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eshel Yaron Newsgroups: gmane.emacs.devel Subject: Re: Adding support for xref jumping to headers/interfaces Date: Tue, 07 Nov 2023 22:30:13 +0100 Message-ID: References: <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> <65a16247-1b1a-149c-b413-71612f88f184@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24436"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) 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: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 07 22:30:50 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 1r0Ter-0006AC-Mz for ged-emacs-devel@m.gmane-mx.org; Tue, 07 Nov 2023 22:30:49 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r0TeP-0004tQ-Mj; Tue, 07 Nov 2023 16:30:21 -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 1r0TeP-0004tD-4F for emacs-devel@gnu.org; Tue, 07 Nov 2023 16:30:21 -0500 Original-Received: from mail.eshelyaron.com ([107.175.124.16] helo=eshelyaron.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r0TeN-0005YX-8j; Tue, 07 Nov 2023 16:30:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1699392617; bh=7y9K5hSUOFT28XYV0Knylv14BqQa766bd06MFrAKAUo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=sAkYzZVu/kqHFjmt0TBFwjD6LN3ABHYkK5tAchfvBgc7AqyUWLk+RmhylCpQdJql6 b44wet4B1XL4l+Qlbj13TLkwIIWYFIOlFNqx4+KLFqpVBjCQmRJtWubFxGUutkeGLI +gKcyvLooHeO1cwRXo/wvAUVgD/aQYfOmeWFbIDLCbRY+gy4XtOR/W67wKDhkiXZml TQTrwqc3+40BTiVPnD644RKRADnSHjA+rtjztqK5Ha2hWBYMHjpx5NCy9lbBHXeYN0 0qDKNuZUfONwijUBlZTEarm6naSO+MzNIYqep4BpT7fD/F2n3pJYSh35gj1TbYL8i7 ipW3yNwiexRcg== In-Reply-To: <65a16247-1b1a-149c-b413-71612f88f184@yandex.ru> (Dmitry Gutov's message of "Tue, 7 Nov 2023 04:12:50 +0200") Received-SPF: pass client-ip=107.175.124.16; envelope-from=me@eshelyaron.com; helo=eshelyaron.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, 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:312323 Archived-At: Dmitry Gutov writes: > Hi Eshel, > > On 05/11/2023 10:16, Eshel Yaron wrote: > >>> 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. I agree, both that this `abbrev-prefix-mark` hardly deserves such a precious global default binding, and that it's futile to discuss changing that right now. >> 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. Sure, I also tweak and customize `completing-read`, and it's definitely up for the task of selecting among a few candidates, but nevertheless I think that `completing-read` is not the best tool for this job. With `read-multiple-choice` you make a selection with a single key, and you don't need to press TAB to see which options are available--the prompt tells you what each key does in case you don't know. That's hard to beat even with a highly optimized `completing-read` interface IME. > 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. That's true, but to know which kinds are available you need to see the list at least once, even if only to know how exactly the backend chose to name these kinds (is it `defvar` or `variable`?). Anyway, I don't think this is such a crucial issue. We can always add a `read-multiple-choice` wrapper later, as long as the API permits it. >> 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. That could work too, perhaps, but what I meant is for the backend to provide along with each kind the unique key that you press to select it. So you always use the same key to the select the same kind with a given backend, regardless of the set of kinds available for a specific identifier. >>> 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?) I think that there's some benefit in being able to designate the kind of definition you want in advance, especially if I already know which kind I want. In the current state of affairs, I get all definitions and then possibly skip one or two and get to select the one I wanted. But I don't know in advance if the one I want will come first, or last, so I need to take a look at the results and respond accordingly. `xref-find-extra` (or similar) removes that bit of friction, and IMO that's an advantage over the current UI. >> 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. > I would imagine that the backends should provide such commands in the appropriate contexts, so maybe those definitions could reside alongside the backend code? >>> 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. Yes, the general API is probably more interesting to then the specifics of the Elisp backend. Cheers, Eshel