bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#19468: 25.0.50; UI inconveniences with M-.


From: Dmitry Gutov
Subject: bug#19468: 25.0.50; UI inconveniences with M-.
Date: Tue, 28 Apr 2015 02:47:41 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]