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: Sun, 05 Nov 2023 09:16:40 +0100 Message-ID: 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 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32751"; 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 Sun Nov 05 09:17:47 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 1qzYKJ-0008Mt-C7 for ged-emacs-devel@m.gmane-mx.org; Sun, 05 Nov 2023 09:17:47 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qzYJU-0005pq-HB; Sun, 05 Nov 2023 03:16:56 -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 1qzYJR-0005pT-Ug for emacs-devel@gnu.org; Sun, 05 Nov 2023 03:16:53 -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 1qzYJQ-0006Bl-77; Sun, 05 Nov 2023 03:16:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1699172210; bh=Faa1m1WUosCSZhy9D3+agdXm7Y2MkhMVquik6iUw/TQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=iCaoZG8o+j6jRpOpdAzhuavyWnE6WsmNgsuQQil1xvfty94iQTs9WI2pp8To8qAG6 yzSubg+jFvU88lLtuAuLhHYYuAczjxVcQonn42dcvf6fUp9ShBlLNkV8MLjYiVu4y6 5ZZUTcnjP4z9ShS1xNCY5An+PWRl0gXMWHR4ffzanF212WmsOVJbFIq9RMoYBsJkQ1 5aZibqQGg5Wc4NzJVwP4+pLp9wJslZBq6RCnR1P1eR3kSPqvCr5DQAql+F8155G+bI YaD3pEHYxTFliXm3XE5zrhL1mAa6egfnbZe2hR/eCl2tm0XUmkWGBQaflXBN4r3sK1 WQT9MwAL7fzWw== In-Reply-To: (Dmitry Gutov's message of "Sun, 5 Nov 2023 01:16:08 +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:312236 Archived-At: Hi Dmitry, Thanks for working on this feature. I'm looking forward to using it. 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`. > 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. The backend can also associate stable `read-multiple-choice` keys to the different kinds it support. WDYT? > 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`. > 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. > 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". 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. Best, Eshel