[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Adding support for xref jumping to headers/interfaces
From: |
João Távora |
Subject: |
Re: Adding support for xref jumping to headers/interfaces |
Date: |
Mon, 27 Nov 2023 17:46:07 +0000 |
On Mon, Nov 27, 2023 at 5:22 PM Dmitry Gutov <dmitry@gutov.dev> wrote:
>
> 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.
This whole thing started because you used that misnaming of
existing things as a justification for misnaming new things.
> > 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.
Not necessarily, it depends on the backend's. But yes, it might.
But I presume they will be categorized by kind.
> Why would you want to also be able to reach "references" through that
> interface anyway?
Why not? To avoid the noise of that categorization. To get to some
reference type not explicitly covered in those other categories.
> 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).
How bout "cross-reference", or simply xref? There's a reason why your xref.el
which you maintain inherited that name from SLIME by whoever ported the UI
(Helmut it was, IIRC);-) There's a lot of wisdom in that name.
xref-backend-extra-kinds ->
xref-backend-xref-kinds OR
xref-backend-xref-cross-reference-kinds
xref-backend-extra-defs ->
xref-backend-xref-defs OR
xref-backend-cross-reference-defs OR
xref-backend-xrefs (this method literally returns xrefs)
xref-find-extra ->
xref-find-all (more people suggested this, I think)
xref-find
xref
xref-find-combined
xref-find-by-kind
> > 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.
Yes! a simple workable patch that someone else liked, spent time
on, worked on, solves real-world problems, and doesn't lock us in
anything. "Doesn't come with keybindings! Blasphemy! Let's
bikeshed, make it very complicated!"
João
- 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/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, 2023/11/27
- Re: Adding support for xref jumping to headers/interfaces,
João Távora <=
- 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
- Re: Adding support for xref jumping to headers/interfaces, Dmitry Gutov, 2023/11/12