etags to xref changed navigation

etags to xref changed navigation

[Phillip Susi]

Etags used to work by hitting ( I think it was ) M-. to find the first
reference, then M-, to cycle through the remaining references.  It seems
that when it was replaced with xref, the M-, binding was removed, and
now M-. opens an xref buffer ( splitting the window ) listing all of the
references, and you have to navigate that buffer in one window while
viewing each location in another.

I find this process slow and cumbersome compared to the old way of just
jumping from reference to reference.  Is there a way to get back to the
old behavior?

Re: etags to xref changed navigation

[Eli Zaretskii]

> From: Phillip Susi <phill@thesusis.net>
> Date: Mon, 22 Apr 2024 11:11:10 -0400
> 
> Etags used to work by hitting ( I think it was ) M-. to find the first
> reference, then M-, to cycle through the remaining references.  It seems
> that when it was replaced with xref, the M-, binding was removed, and
> now M-. opens an xref buffer ( splitting the window ) listing all of the
> references, and you have to navigate that buffer in one window while
> viewing each location in another.
> 
> I find this process slow and cumbersome compared to the old way of just
> jumping from reference to reference.  Is there a way to get back to the
> old behavior?

The old behavior is supposed to be necessary much less with xref,
since xref's search is more accurate, and usually finds only one
candidate.  So I'd be interested to know in what programming language
do you see many candidates, and why.

In addition, you haven't explained why you find the navigation in the
XREF buffer slow and cumbersome.  Basically, once you switch to the
XREF buffer, you can display next/previous candidate with a single
key, which is not more typing than "M-," (and there's the ability to
select a candidate that is not next or previous, something "M-,"
couldn't give you).  In addition, you can customize the variable
xref-auto-jump-to-first-definition to the value 'move' or 'show', in
which case the first candidate will be shown even if there are several
candidates.

Given all these facts, I'd be interested to hear why you consider the
new operation inferior to the old one.

If you still want to have the old behavior back, you can rebind M-. to
find-tag and M-, to tags-loop-continue, which still exist, just
without the default key binding.

Re: etags to xref changed navigation

[Stefan Monnier via Users list for the GNU Emacs text editor]

> If you still want to have the old behavior back, you can rebind M-. to
> find-tag and M-, to tags-loop-continue, which still exist, just
> without the default key binding.

But these use only the TAGS info, not the Xref info.
Maybe we could make consecutive uses of `M-.` jump to the "next def"
(when there are more than one)?


        Stefan

Re: etags to xref changed navigation

[Philip Kaludercic]

Phillip Susi <phill@thesusis.net> writes:

> Etags used to work by hitting ( I think it was ) M-. to find the first
> reference, then M-, to cycle through the remaining references.  It seems
> that when it was replaced with xref, the M-, binding was removed, and
> now M-. opens an xref buffer ( splitting the window ) listing all of the
> references, and you have to navigate that buffer in one window while
> viewing each location in another.

Not necessarily, you can use M-g M-n and M-g M-p from the buffer you
invoked xref in to navigate definitions as well.

> I find this process slow and cumbersome compared to the old way of just
> jumping from reference to reference.  Is there a way to get back to the
> old behavior?
>
>
>

-- 
	Philip Kaludercic on peregrine

Re: etags to xref changed navigation

[Eli Zaretskii]

> Date: Mon, 22 Apr 2024 12:00:39 -0400
> From:  Stefan Monnier via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> 
> > If you still want to have the old behavior back, you can rebind M-. to
> > find-tag and M-, to tags-loop-continue, which still exist, just
> > without the default key binding.
> 
> But these use only the TAGS info, not the Xref info.

That's what the pre-Emacs 25 M-. and M-, did.  So if that was good
enough then, find-tag should be good enough now.

> Maybe we could make consecutive uses of `M-.` jump to the "next def"
> (when there are more than one)?

That'd get in the way of some workflows, I think, and is also very
problematic from the UI POV.

Re: etags to xref changed navigation

[Stefan Monnier via Users list for the GNU Emacs text editor]

>> Maybe we could make consecutive uses of `M-.` jump to the "next def"
>> (when there are more than one)?
> That'd get in the way of some workflows, I think, and is also very
> problematic from the UI POV.

I'm not sure what the problems would be, concretely, but we can always
solve the problem by making the behavior optional.


        Stefan

Re: etags to xref changed navigation

[Phillip Susi]

Eli Zaretskii <eliz@gnu.org> writes:

> The old behavior is supposed to be necessary much less with xref,
> since xref's search is more accurate, and usually finds only one
> candidate.  So I'd be interested to know in what programming language
> do you see many candidates, and why.

Typically there is only one *definition*, but many *referenecs*.

> In addition, you haven't explained why you find the navigation in the
> XREF buffer slow and cumbersome.  Basically, once you switch to the
> XREF buffer, you can display next/previous candidate with a single
> key, which is not more typing than "M-," (and there's the ability to
> select a candidate that is not next or previous, something "M-,"
> couldn't give you).  In addition, you can customize the variable
> xref-auto-jump-to-first-definition to the value 'move' or 'show', in
> which case the first candidate will be shown even if there are several
> candidates.

I find the window splitting to be a bit annoying, and if I want to poke
around each callsite a bit, I have to keep switching windows with C-o to
move between exploring, and moving to the next callsite.

> If you still want to have the old behavior back, you can rebind M-. to
> find-tag and M-, to tags-loop-continue, which still exist, just
> without the default key binding.

Do they still function the same, especially if you are using eglot?  I
thought I checked and found that tags-loop-continue was obsolete/removed
in emacs 29.

Re: etags to xref changed navigation

[Phillip Susi]

Stefan Monnier via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> I'm not sure what the problems would be, concretely, but we can always
> solve the problem by making the behavior optional.

I think the reason why it was on M-, before was because repeated
M-. couldn't tell whether you wanted the next, or to start a new search
for whatever point is on now.

C-M-, is now bound to xref-go-foward.  If there is no more to go foward,
what if it instead jumped to the next ref?

Re: etags to xref changed navigation

[Eli Zaretskii]

> From: Phillip Susi <phill@thesusis.net>
> Date: Tue, 23 Apr 2024 13:02:17 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The old behavior is supposed to be necessary much less with xref,
> > since xref's search is more accurate, and usually finds only one
> > candidate.  So I'd be interested to know in what programming language
> > do you see many candidates, and why.
> 
> Typically there is only one *definition*, but many *referenecs*.

Now I'm confused: M-. and M-, were about finding *definitions*, not
references.  If you want to find references, you need to type M-?
instead.  So I wonder what am I missing here.

> > In addition, you haven't explained why you find the navigation in the
> > XREF buffer slow and cumbersome.  Basically, once you switch to the
> > XREF buffer, you can display next/previous candidate with a single
> > key, which is not more typing than "M-," (and there's the ability to
> > select a candidate that is not next or previous, something "M-,"
> > couldn't give you).  In addition, you can customize the variable
> > xref-auto-jump-to-first-definition to the value 'move' or 'show', in
> > which case the first candidate will be shown even if there are several
> > candidates.
> 
> I find the window splitting to be a bit annoying, and if I want to poke
> around each callsite a bit, I have to keep switching windows with C-o to
> move between exploring, and moving to the next callsite.

You don't need to switch windows if you don't like it.  Customize
xref-auto-jump-to-first-definition to the value t, and move between
candidate with "M-g M-n" and "M-g M-p".  This way, you never need to
go to the window showing the *xref* buffer.  (If you want that for
M-?, customize xref-auto-jump-to-first-xref instead.)

> > If you still want to have the old behavior back, you can rebind M-. to
> > find-tag and M-, to tags-loop-continue, which still exist, just
> > without the default key binding.
> 
> Do they still function the same, especially if you are using eglot?  I
> thought I checked and found that tags-loop-continue was obsolete/removed
> in emacs 29.

They work the same as they did before, and are obsolete, but not
removed.

They don't support Eglot, of course, since find-tag never did.  So if
you want to have Eglot support, I suggest the customization described
above, it should give you the same UX as the old bindings, albeit with
different keys and the *xref* window which will be popped up.

Re: etags to xref changed navigation

[Phillip Susi]

Philip Kaludercic <philipk@posteo.net> writes:

> Not necessarily, you can use M-g M-n and M-g M-p from the buffer you
> invoked xref in to navigate definitions as well.

Ahh, that does the trick, just with two chords instead of one.  And a
C-x 0 to dismiss the xref buffer first.

Re: etags to xref changed navigation

[Stefan Monnier]

>> I'm not sure what the problems would be, concretely, but we can always
>> solve the problem by making the behavior optional.
> I think the reason why it was on M-, before was because repeated
> M-. couldn't tell whether you wanted the next, or to start a new search
> for whatever point is on now.

That's also my understanding, and I'm suggesting that it distinguishes
the two by checking if `M-.` is used consecutively or not (just like
`C-/` can't easily tell whether you want to keep undoing or you want to redo
the thing you just undid, so it checks whether these `C-/` are
consecutive or not).


        Stefan

Re: etags to xref changed navigation

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: help-gnu-emacs@gnu.org
> Date: Tue, 23 Apr 2024 14:29:31 -0400
> 
> >> I'm not sure what the problems would be, concretely, but we can always
> >> solve the problem by making the behavior optional.
> > I think the reason why it was on M-, before was because repeated
> > M-. couldn't tell whether you wanted the next, or to start a new search
> > for whatever point is on now.
> 
> That's also my understanding, and I'm suggesting that it distinguishes
> the two by checking if `M-.` is used consecutively or not

The problem with this proposal is that any command in-between will
break the chain.  One must remember not event to move point.  That
could well be problematic: for example, imagine that I'm not sure
whether I want the current candidate, and to be sure I need to scroll
the window a bit, because what M-. displayed doesn't show enough
(e.g., because the window is too small).

Re: etags to xref changed navigation

[Philip Kaludercic]

Phillip Susi <phill@thesusis.net> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Not necessarily, you can use M-g M-n and M-g M-p from the buffer you
>> invoked xref in to navigate definitions as well.
>
> Ahh, that does the trick, just with two chords instead of one.  

Note that these are just the next-error and previous-error functions.
You could just as well (re)bind them to whatever other key you prefer,
if you feel that this is something you use frequently enough.  I
personally find the M- prefix simple and convenient enough to not need a
shorter chord.

>                                                                 And a
> C-x 0 to dismiss the xref buffer first.

You could change this by setting xref-show-definitions-function to the
right function.


-- 
	Philip Kaludercic on peregrine

Re: etags to xref changed navigation

[Stefan Monnier via Users list for the GNU Emacs text editor]

>> >> I'm not sure what the problems would be, concretely, but we can always
>> >> solve the problem by making the behavior optional.
>> > I think the reason why it was on M-, before was because repeated
>> > M-. couldn't tell whether you wanted the next, or to start a new search
>> > for whatever point is on now.
>> 
>> That's also my understanding, and I'm suggesting that it distinguishes
>> the two by checking if `M-.` is used consecutively or not
>
> The problem with this proposal is that any command in-between will
> break the chain.  One must remember not event to move point.  That
> could well be problematic: for example, imagine that I'm not sure
> whether I want the current candidate, and to be sure I need to scroll
> the window a bit, because what M-. displayed doesn't show enough
> (e.g., because the window is too small).

IIUC if you break the chain, indeed you wouldn't be able to use `M-.` to
keep going to the next def, but you could still use `M-g M-n` for that.
The extra keyboard movement from `M-.` to `M-g M-n` is expected to be
much less of a burden since you presumably already moved your fingers
away from `M-.` to break the chain.


        Stefan

Re: etags to xref changed navigation

[Eli Zaretskii]

> Date: Tue, 23 Apr 2024 22:07:08 -0400
> From:  Stefan Monnier via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> 
> >> >> I'm not sure what the problems would be, concretely, but we can always
> >> >> solve the problem by making the behavior optional.
> >> > I think the reason why it was on M-, before was because repeated
> >> > M-. couldn't tell whether you wanted the next, or to start a new search
> >> > for whatever point is on now.
> >> 
> >> That's also my understanding, and I'm suggesting that it distinguishes
> >> the two by checking if `M-.` is used consecutively or not
> >
> > The problem with this proposal is that any command in-between will
> > break the chain.  One must remember not event to move point.  That
> > could well be problematic: for example, imagine that I'm not sure
> > whether I want the current candidate, and to be sure I need to scroll
> > the window a bit, because what M-. displayed doesn't show enough
> > (e.g., because the window is too small).
> 
> IIUC if you break the chain, indeed you wouldn't be able to use `M-.` to
> keep going to the next def, but you could still use `M-g M-n` for that.
> The extra keyboard movement from `M-.` to `M-g M-n` is expected to be
> much less of a burden since you presumably already moved your fingers
> away from `M-.` to break the chain.

That's correct, but I think remembering to use only "M-g M-n" is
easier, and together with xref-auto-jump-to-first-definition set to t
it should provide a UX almost identical to the old UX.

Re: etags to xref changed navigation

[Dmitry Gutov]

On 23/04/2024 21:29, Stefan Monnier wrote:
>>> I'm not sure what the problems would be, concretely, but we can always
>>> solve the problem by making the behavior optional.
>> I think the reason why it was on M-, before was because repeated
>> M-. couldn't tell whether you wanted the next, or to start a new search
>> for whatever point is on now.
> That's also my understanding, and I'm suggesting that it distinguishes
> the two by checking if `M-.` is used consecutively or not (just like
> `C-/` can't easily tell whether you want to keep undoing or you want to redo
> the thing you just undid, so it checks whether these `C-/` are
> consecutive or not).

In such as scheme, if the first 'M-.' brings you to a beginning of a 
symbol, the next 'M-.' would be ambiguous: would you want to continue 
the previous navigation (and go to the second location), or would you 
want to go to the definition of the new symbol?

Re: etags to xref changed navigation

[Stefan Monnier]

>>>> I'm not sure what the problems would be, concretely, but we can always
>>>> solve the problem by making the behavior optional.
>>> I think the reason why it was on M-, before was because repeated
>>> M-. couldn't tell whether you wanted the next, or to start a new search
>>> for whatever point is on now.
>> That's also my understanding, and I'm suggesting that it distinguishes
>> the two by checking if `M-.` is used consecutively or not (just like
>> `C-/` can't easily tell whether you want to keep undoing or you want to redo
>> the thing you just undid, so it checks whether these `C-/` are
>> consecutive or not).
> In such as scheme, if the first 'M-.' brings you to a beginning of a symbol,
> the next 'M-.' would be ambiguous: would you want to continue the previous
> navigation (and go to the second location), or would you want to go to the
> definition of the new symbol?

Not sure which part of my above-quoted text isn't clear: the ambiguity
would be "hand waved" away by saying that when the users hits `M-.` without
doing anything else in between, they are telling Emacs to keep looking
for the same symbol.  If they want to start a new search, they should
break the sequence, e.g. with `C-g` or `C-f C-b`, you name it.

IME in most languages `M-.` usually jumps to a symbol which you will
rarely want to use for a new search.


        Stefan

Re: etags to xref changed navigation

[Dmitry Gutov]

On 25/04/2024 06:34, Stefan Monnier wrote:
> Not sure which part of my above-quoted text isn't clear: the ambiguity
> would be "hand waved" away by saying that when the users hits `M-.` without
> doing anything else in between, they are telling Emacs to keep looking
> for the same symbol.  If they want to start a new search, they should
> break the sequence, e.g. with `C-g` or `C-f C-b`, you name it.
> 
> IME in most languages `M-.` usually jumps to a symbol which you will
> rarely want to use for a new search.

"Handwaved" indeed, though I'm guessing some singular cases would remain 
where this is different. So the proposed UI sounds "wrong", to me at least.

I wouldn't object to an extra mode or a user option, though. Since 
indeed what you are suggesting would work like the user expects 99% of 
the time.