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: Wed, 8 Nov 2023 01:17:59 +0200 Message-ID: <9377bf2b-13ed-8d86-4294-0b88e6808d80@yandex.ru> 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; 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="10216"; 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 Wed Nov 08 00:19:27 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 1r0VLy-0002Qa-Ev for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Nov 2023 00:19:26 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r0VKv-0003vj-QJ; Tue, 07 Nov 2023 18:18: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 1r0VKt-0003or-5A for emacs-devel@gnu.org; Tue, 07 Nov 2023 18:18:19 -0500 Original-Received: from forward500b.mail.yandex.net ([178.154.239.144]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r0VKo-0007JC-JJ; Tue, 07 Nov 2023 18:18:18 -0500 Original-Received: from mail-nwsmtp-smtp-production-main-78.myt.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-78.myt.yp-c.yandex.net [IPv6:2a02:6b8:c12:228c:0:640:6319:0]) by forward500b.mail.yandex.net (Yandex) with ESMTP id 44A3061213; Wed, 8 Nov 2023 02:18:09 +0300 (MSK) Original-Received: by mail-nwsmtp-smtp-production-main-78.myt.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id 5Im7xeBUk4Y0-TkZ4OtwD; Wed, 08 Nov 2023 02:18:08 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1699399088; bh=7/RwoFQV+rPdRcSgf2gKXX5V1C0cAqg34dX71pB3KjM=; h=In-Reply-To:From:Subject:Message-ID:Cc:References:Date:To; b=oRr0mMZ5uHnunq+sitipw1VXf16Qth1rDxZaGg+393uFcN3kSSBR6d7I+YpyAJerr tbglK1oAz0JgSw02DK+1UpqH6sqScS3nTNIxG40FNnHK5+Tihr6DJSOp7C6VwR8VB9 AeofhJgi62Bf8Fv1yQO3LOne9AKgQUq6l1ZkiD1c= Authentication-Results: mail-nwsmtp-smtp-production-main-78.myt.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailauth.nyi.internal (Postfix) with ESMTP id C69AF27C0054; Tue, 7 Nov 2023 18:18:04 -0500 (EST) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 07 Nov 2023 18:18:04 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddukedgtdekucetufdoteggodetrfdotf 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; Tue, 7 Nov 2023 18:18:01 -0500 (EST) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=178.154.239.144; envelope-from=dgutov@yandex.ru; helo=forward500b.mail.yandex.net X-Spam_score_int: -44 X-Spam_score: -4.5 X-Spam_bar: ---- X-Spam_report: (-4.5 / 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=-2.344, 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:312326 Archived-At: On 07/11/2023 23:30, Eshel Yaron wrote: >>> 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. But for read-multiple-choice you have to move your eyes to the echo area, read the char->value mappings, choose one in your head, and type it. Typing the first 2-3 chars of the value you wanted without looking anywhere might take less time. >> 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. An advice binding completing-read to something using read-multiple-choice internally should do it. Or a user option, etc. >>> 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. Imagine you are switching between different buffers using different languages. If the backends are different, your set of keys that could be used would have to be looked up every time, because the sets of values are different. That could even happen when using the same client, if e.g. Eglot should different kinds of different languages. If, however, we managed to work out a fixed set of commands that cover 99% of the languages and assigned them to a map, old-style, that would make things more stable: at least the same char would always mean the same. Just spitballing again, with a different take on the problem (a less flexible and extensible one). >>>> 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. It sometimes happens that the Elisp Xref backend guesses the "kind" automatically more correctly than I might (usually because of missing or extra parens), ultimately hinting at problems with code. > 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. Does that happen often? With which languages? Are there "kinds" that you more often would prefer not to see in the list? >>> 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? Joao didn't want to have such definitions in Xref. I'm still on the fence, personally. But these are two different/separate features: - Add command that can ask you which kind you want, and show matches. - Define different new commands, one for each "kind". >>> 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. What I meant is, using it with the Elisp implementation didn't convince me of the usefulness of the feature. Perhaps you disagree? Or it would be nice to hear from someone who have tried out Eglot's integration and found more upsides there.