GNU bug report logs - #19468
25.0.50; UI inconveniences with M-.

Previous Next

Package: emacs;

Reported by: Eli Zaretskii <eliz <at> gnu.org>

Date: Mon, 29 Dec 2014 20:27:02 UTC

Severity: normal

Found in version 25.0.50

Done: Dmitry Gutov <dgutov <at> yandex.ru>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 19468 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: bug#19468: 25.0.50; UI inconveniences with M-.
Date: Mon, 27 Apr 2015 13:35:25 -0400
>> I don't understand exactly the scenario you're talking about.  Can you
>> give a recipe?
>
> Yes:
>
>   emacs -Q
>   C-x C-f lisp/simple.el RET
>   M-. find-tag RET
>
> This puts you at the first line of find-tag, without showing the other
> possible symbols whose names contain "find-tag" as their substring.

Yes, that's the expected behavior, and matches the behavior of Emacs-24.
Is that a behavior you like or a behavior you dislike?

> By contrast, this:
>
>   emacs -Q
>   C-x C-f lisp/simple.el RET
>   M-x load-library RET xref RET
>   M-x xref-etags-mode RET
>   M-. find-tag RET
>
> does NOT show the definition of find-tag, but instead opens an *xref*
> buffer with possible matches, and expects you to pick one of them (and

Indeed, one of the differences in the new UI is that we don't have the
"C-u M-. lets you cycle among matches" any more.  Instead we pop up an
*xref* buffer where you can choose the match that interests you.  I find
this easier (and generally faster) to use.

This is an issue that only affects the UI (not the API and hence not the
backends), so we can easily fix it by providing either different UIs, or
some config var, or ...

> btw the defun I'm probably after is not the first or second hit there;
> looks like the candidates are arranged in the alphabetical order of
> the *.el files).

Indeed, the ordering looks incorrect.  This is a bug.

> I guess the elisp-mode back-end returns just one candidate, whereas
> the etags back-end returns a list.

Exactly.

> But it's confusing to have such evident differences just because you
> changed the back-end, I think.

But popping up the *xref* buffer when there's only one element in it
doesn't make much sense I think.


        Stefan




This bug report was last modified 9 years and 150 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.