emacs-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]