unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Patrick Mahan <plmahan@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: help-gnu-emacs@gnu.org
Subject: Re: Using xref-find-definitions
Date: Sat, 7 Oct 2023 12:05:59 -0700	[thread overview]
Message-ID: <CAFDHx1KMPJ75RVp4tSy2sgxKQ9MvmEdUhb5Z3pBBUSJtnr0GyQ@mail.gmail.com> (raw)
In-Reply-To: <CAFDHx1JNsi_B1qPo_2TU+TtgzqND2_Yh563gAriNU86eaVjBCw@mail.gmail.com>

On Sat, Oct 7, 2023 at 12:35 AM Patrick Mahan <plmahan@gmail.com> wrote:

> On Fri, Oct 6, 2023 at 11:02 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
>> > From: Patrick Mahan <plmahan@gmail.com>
>> > Date: Fri, 6 Oct 2023 11:38:18 -0700
>> >
>> > An *xref* buffer appears with the following -
>> > /home/pmahan/workspaces/myos/src/bin/mserv/appclass/my_ipserv.c
>> > 109: void flow_log(
>> > /home/pmahan/workspaces/myos/src/bin/mserv/appclass/my_ipserv.c
>> > 109: void flow_log(
>> >
>> > When I was using find-tag, it would give me the first hit, then I could
>> do
>> > CTRL-u M-. to go to the next entry.  I would not have this presented.
>> In
>> > the new method, this is churning my buffer displays around which is
>> > annoying, especially when the entry is in the same code module.
>>
>> I don't understand this description.  Can you explain in more detail
>> what happens with Xref and why this is annoying?
>>
>> The Emacs user manual says about M-. and similar commands:
>>
>>      If any of the above commands finds more than one matching definition,
>>   it by default pops up the ‘*xref*’ buffer showing the matching
>>   candidates.  (‘C-M-.’ _always_ pops up the ‘*xref*’ buffer if it finds
>>   at least one match.)  The candidates are normally shown in that buffer
>>   as the name of a file and the matching identifier(s) in that file.  In
>>   that buffer, you can select any of the candidates for display, and you
>>   have several additional commands, described in *note Xref Commands::.
>>   However, if the value of the variable
>>   ‘xref-auto-jump-to-first-definition’ is ‘move’, the first of these
>>   candidates is automatically selected in the ‘*xref*’ buffer, and if it’s
>>   ‘t’ or ‘show’, the first candidate is automatically shown in its own
>>   window; ‘t’ also selects the window showing the first candidate.  The
>>   default value is ‘nil’, which just shows the candidates in the ‘*xref*’
>>   buffer, but doesn’t select any of them.
>>
>> You are supposed to use these facilities instead of "C-u M-.".  Did
>> you try that?
>>
>>
> Not really since I have not updated my last copy of the emacs manual and I
> tend to find it clumsy to navigate anyways.  I tend to fall back to the
> Emacs Wiki or rely on google-fu to find my answer.  I do use the
> xref-find-definition commands, via the keystrokes described (M-., CTRL-x 4
> ., etc).  What I was wanting to stop seeing was the multiple entries
> because my TAGS tables would have not only the local directory but any
> identifiers from the sub-directories.  That tends to consistently pop-up
> the other *xref* buffer when I would rather just jump to the first entry
> found, most of the time.  I will miss the option to jump to the next entry,
> but I suppose then I can always switch to the *xref* buffer and select
> another definition.
>
> But now that `xref-auto-jump-to-first-definition` has been pointed out, I
> can at least eliminate this annoyance.
>
>
Hmmm, obviously I spoke too soon.  I did mention in my original post that I
was using emacs 25.2.  It turns out that
`xref-auto-jump-to-first-definition` does not exist in the xref.el shipped
with emacs 25.2.

It looks like I need to fallback to the solution proposed here -
https://emacs.stackexchange.com/questions/61384/how-to-go-to-the-first-definition-with-xref-find-definitions-do-not-show-all-op

 Just in case somebody else is in my situation.

Thanks,

Patrick


      reply	other threads:[~2023-10-07 19:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-06 18:38 Using xref-find-definitions Patrick Mahan
2023-10-07  6:02 ` Eli Zaretskii
2023-10-07  7:35   ` Patrick Mahan
2023-10-07 19:05     ` Patrick Mahan [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFDHx1KMPJ75RVp4tSy2sgxKQ9MvmEdUhb5Z3pBBUSJtnr0GyQ@mail.gmail.com \
    --to=plmahan@gmail.com \
    --cc=eliz@gnu.org \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).