[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Adding support for xref jumping to headers/interfaces
|
From: |
Dmitry Gutov |
|
Subject: |
Re: Adding support for xref jumping to headers/interfaces |
|
Date: |
Mon, 27 Nov 2023 19:22:45 +0200 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 |
On 27/11/2023 18:27, João Távora wrote:
On Mon, Nov 27, 2023 at 4:04 PM Dmitry Gutov <dmitry@gutov.dev> wrote:
Why don't you read up on the difference between
xref-show-definitions-function and xref-show-xrefs-function. Those are
not implementation details but something that affects user experience.
And users can customize one or the other, which correspondingly affects
dispatches which go through one or the other.
<eyeroll> First, who does that? I thought you were concerned about
the OOtB experience for non-powerusers.
It doesn't take a power user to use the Customize interface to set
xref-show-definitions-function to xref-show-definitions-completing-read.
Who uses that? I do, for example. And the people who asked for it (see
https://lists.gnu.org/archive/html/emacs-devel/2020-11/msg00824.html).
There are also third-party packages which provide alternative UIs
through these options (e.g. ivy-xref and helm-xref).
Secondly, if something called
"definitions" is used for things that are patently not "definitions"
that thing is incorrectly named, period. It's not because that editor
thing was misnamed by its creator that magically my C++ declaration is
now a definition, too.
It's about "set of things where I usually want to pick only one and jump
to it" versus "set of things which I usually want to see the full list
of, which stays around".
You can say that "definition" is perhaps not an ideal term for the
former. But the distinction is useful, and if you have better naming
suggestions, go ahead.
Until now the only built-in commands which went through that dispatcher
were the variations of xref-find-definitions, so the name wasn't a problem.
o show me "references" as one of the kinds of thing to search for.
Then the list of results would drown in "references", wouldn't it?
But if I want to see references to the given symbol at point, that's what
I want! I press M-? xref-find-references all the time in Eglot.
And that's great -- please continue to press M-? for that purpose.
But if 'references' joins the "definition kinds", then the command to
"find all definition kinds" will become pointless. And we already have
command to "find all references".
No, not pointless at all. My main use case for this is to
first invoke the command on a given place of interest and _then_
ask myself what I want to see of that symbol. "All references",
"definitions", "declarations"?
The combined view, as implemented in the current
xref-find-all-definitions by default, will then just show references.
Why would you want to also be able to reach "references" through that
interface anyway?
For experimentation.
Then perhaps we could cut another less contentious branch off
279203199a2d10677e42747476b39394a4184a78
Over that branch we can rename Eglot kinds to strings and "extra"
to "all". I'm sure that's less contentious, a good candidate
for master and not incompatible with evolving into whatever
results of your experimentation.
See above.
So, awright. Do you really really want to rename "extra" to
"definitions"?? is that the blocker? Makes 0 sense, but if
there's no talking you out of it then I guess users like me
can swallow the awkwardness and translate "definition" to
"thing" in their minds. And we have strategies for renaming
things anyway.
Like I said, they are not "extra" because they will on most cases
include the kinds already shown by xref-find-definitions. I'm open to
other names, but please keep the intended semantics in mind (see above).
Well I am, but not of that code, at least not yet of that code.
Merge to master something useful that doesn't compromise us.
We're yet finding that.
What exactly is compromised by that patch? And do you not agree
it is minimally useful? You wrote the thing! Noone forced you to.
I voiced my doubts in the very first message that patch was attached to.
And that it's experimental. It's also like 20 lines total. Let's keep a
perspective.
- Re: Adding support for xref jumping to headers/interfaces, (continued)
- Re: Adding support for xref jumping to headers/interfaces, João Távora, 2023/11/27
- Re: Adding support for xref jumping to headers/interfaces, Eli Zaretskii, 2023/11/27
- Re: Adding support for xref jumping to headers/interfaces, Dmitry Gutov, 2023/11/27
- Re: Adding support for xref jumping to headers/interfaces, Eli Zaretskii, 2023/11/27
- Re: Adding support for xref jumping to headers/interfaces, Dmitry Gutov, 2023/11/27
- Re: Adding support for xref jumping to headers/interfaces, João Távora, 2023/11/26
- Re: Adding support for xref jumping to headers/interfaces, Dmitry Gutov, 2023/11/27
- Re: Adding support for xref jumping to headers/interfaces, João Távora, 2023/11/27
- Re: Adding support for xref jumping to headers/interfaces, Dmitry Gutov, 2023/11/27
- Re: Adding support for xref jumping to headers/interfaces, João Távora, 2023/11/27
- Re: Adding support for xref jumping to headers/interfaces,
Dmitry Gutov <=
- Re: Adding support for xref jumping to headers/interfaces, João Távora, 2023/11/27
- Re: Adding support for xref jumping to headers/interfaces, Dmitry Gutov, 2023/11/27
- Re: Adding support for xref jumping to headers/interfaces, João Távora, 2023/11/27
- Re: Adding support for xref jumping to headers/interfaces, Dmitry Gutov, 2023/11/27
- Re: Adding support for xref jumping to headers/interfaces, João Távora, 2023/11/27
- Re: Adding support for xref jumping to headers/interfaces, Dmitry Gutov, 2023/11/10
- Re: Adding support for xref jumping to headers/interfaces, Dmitry Gutov, 2023/11/10
- Re: Adding support for xref jumping to headers/interfaces, João Távora, 2023/11/11
- Re: Adding support for xref jumping to headers/interfaces, Dmitry Gutov, 2023/11/11
- Re: Adding support for xref jumping to headers/interfaces, João Távora, 2023/11/12