unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Ludovic Brenta <ludovic@ludovic-brenta.org>
Cc: 32510@debbugs.gnu.org
Subject: bug#32510: xref-find-definitions should return file names, too
Date: Thu, 18 Jul 2019 18:16:23 +0300	[thread overview]
Message-ID: <83a7dbweyg.fsf@gnu.org> (raw)
In-Reply-To: <b8f087f2fa5c8680fa90a77a147286c5@ludovic-brenta.org> (message from Ludovic Brenta on Thu, 18 Jul 2019 16:53:42 +0200)

> Date: Thu, 18 Jul 2019 16:53:42 +0200
> From: Ludovic Brenta <ludovic@ludovic-brenta.org>
> 
> I can confirm that the patch by Eli Zaretskii works, with a
> difference compared to find-tag: find-tag opens the first
> file whose name matches the searched string whereas
> xref-find-definitions opens a new buffer with all matches,
> forcing the user to use many keystrokes (or worse: reach
> for the mouse :)) to choose a match.

That's not what happened to me after the patch.  For me, M-. just
visited the one file whose name I typed.

Can you show the exact sequence of commands you typed, preferably
using the Emacs sources and corresponding TAGS tables and file names
as the basis, so that I could repeat it here?

> I suppose this change of behavior is intentional, consistent
> with all other cross-references, and only affects ergonomy;
> the patch more importantly restores the functionality that
> was previously lost.

I cannot tell whether it's intentional until I see the behavior you
describe.  What I can say is that if there's only one match, xref goes
there automatically and immediately, but if there are several
candidate matches, xref shows them and allows you to select the one(s)
you want.  The xref behavior is better when the match you want is not
one of the first few, because find-tag required you to continuously
type "C-u M-." in that case, and moreover do that blindly, since you
had no idea how far away is your match.  With xref you can select the
match you are after without iterating through all the previous ones.

However, I would expect the user to type the full file name in this
use case, since that's what this feature is about: finding a file
given its name.  In that case, both commands behave almost
identically.

Dmitry, any comments on the patch?  I admit I didn't study in detail
the role of the PATTERN slot of the object generated by the function
where I proposed to make the change, so perhaps I'm missing some use
case where the patch will not DTRT?

Thanks.





  reply	other threads:[~2019-07-18 15:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87ftnazlz3.fsf@mouse.gnus.org>
2018-08-23 15:32 ` bug#32510: xref-find-definitions should return file names, too Ludovic Brenta
2019-07-13  2:50   ` Lars Ingebrigtsen
     [not found]   ` <handler.32510.C.15629862456126.notifdonectrl.0@debbugs.gnu.org>
2019-07-13 19:34     ` bug#32510: acknowledged by developer (control message for bug #32510) Ludovic Brenta
2019-07-13 23:25       ` Drew Adams
2019-07-14  5:21       ` Eli Zaretskii
2019-07-30  0:06         ` Dmitry Gutov
2019-07-30 14:00           ` Dmitry Gutov
2019-08-03 10:00             ` Eli Zaretskii
2019-07-15 13:54   ` bug#32510: Tags: wontfix -> patch Ludovic Brenta
2019-07-18 14:53   ` bug#32510: xref-find-definitions should return file names, too Ludovic Brenta
2019-07-18 15:16     ` Eli Zaretskii [this message]
2019-07-18 15:54       ` Ludovic Brenta
2019-07-18 16:07         ` Eli Zaretskii
2019-07-19 22:23       ` Dmitry Gutov
2019-07-20  7:17         ` Eli Zaretskii

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=83a7dbweyg.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=32510@debbugs.gnu.org \
    --cc=ludovic@ludovic-brenta.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.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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).