GNU bug report logs -
#19468
25.0.50; UI inconveniences with M-.
Previous Next
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
Message #194 received at 19468 <at> debbugs.gnu.org (full text, mbox):
On 04/26/2015 05:56 PM, Eli Zaretskii wrote:
> emacs -Q
> M-x xref-et TAB => [No match]
>
> It should be autoloaded, IMO. Perhaps there should also be a
> global minor mode, for those who'd like that.
I don't know if we want to settle on that solution, actually. Have you
seen this thread?
http://lists.gnu.org/archive/html/emacs-devel/2015-04/msg01236.html
That's not so easy to wrap in a global minor mode. I'm not even sure a
minor mode would be a good approach here at all.
However, it's a lot more flexible than using xref-etags-mode, especially
with the changes to help buffers proposed by Daniel.
> . It does nothing when point is on a unique symbol:
>
> M-. set_cursor_from_row RET
> Now, with point on its position under set_cursor_from_row, type
> M-. again => nothing(??!!) happens
>
> I guess it looks for more symbols matching set_cursor_from_row,
> finds out that this is the only one, and does nothing. This is
> not useful. It should at the very least say something like
> "set_cursor_from_row: this is the only match".
`M-x find-tag' behaves exactly the same: even when the result is that we
don't move anywhere (for the same reason), there's no helpful message.
Just "Mark set" in the echo area.
I don't know if adding a new message in this case will be too helpful,
but you're welcome to suggest the wording.
> Bonus points for
> prompting for a symbol, like it does when there's no symbol at
> point, because I think this is more useful in this situation.
I'd take a look at the patch.
> . Some problems with key bindings in the *xref* buffer:
>
> . RET displays the candidate listed on the current line, but
> closes the window displaying *xref*, so it's not easy to try
> another candidate afterwards.
There's also the `C-o' binding, which displays the xref, but keeps the
current focus.
> I think it would be more helpful
> to just switch to the window showing the definition, but leave
> the *xref* buffer shown.
Some packages take this approach; I don't like it. But this should be
easy to implement with a user option that would slightly change the
behavior of `xref-goto-xref'. Care to take a stab at it?
> . You need to use the unconventional '.' and ',' to both move and
> display the definitions -- this should at least be mentioned in
> the initial echo-area message when *xref* is first displayed.
> (This was reported as a problem in the original report, but
> seems to be left unchanged.)
Should those be `n' and `p' instead, by default? I've found myself using
these bindings very rarely anyway, and `n' is still very close.
> (Other similar Emacs modes,
> like Compilation and Grep, do provide commands to move to the
> next item without first switching to the buffer that shows all
> the hits.)
Compilation and Grep both use M-g M-n/M-g M-p, and the
next-error-function variable. Do you want xref to reuse it?
Would you be comfortable with forgetting the current list of errors
after navigating somewhere with xref?
> But what are the alternatives, if any? I could only find
> something related in ada-mode and in elisp-mode. This means
> that, for example, for C/C++ and Java, etags is the only
> available back-end, and this change is currently just a different
> UI wrapping the same basic functionality? Is there any further
> development planned for the near future?
There's also ggtags in GNU ELPA. I'm sure it could provide some
integration, too.
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.