From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#19468: 25.0.50; UI inconveniences with M-. Date: Tue, 28 Apr 2015 18:00:35 +0300 Message-ID: <831tj4wb58.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <553ECA9D.6090306@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1430233298 25992 80.91.229.3 (28 Apr 2015 15:01:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 28 Apr 2015 15:01:38 +0000 (UTC) Cc: 19468@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Apr 28 17:01:23 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Yn70e-0007qj-DB for geb-bug-gnu-emacs@m.gmane.org; Tue, 28 Apr 2015 17:01:16 +0200 Original-Received: from localhost ([::1]:33973 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yn70d-00076F-Vl for geb-bug-gnu-emacs@m.gmane.org; Tue, 28 Apr 2015 11:01:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39226) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yn70V-00074J-Sj for bug-gnu-emacs@gnu.org; Tue, 28 Apr 2015 11:01:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yn70R-0001cK-DF for bug-gnu-emacs@gnu.org; Tue, 28 Apr 2015 11:01:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53119) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yn70R-0001cG-AJ for bug-gnu-emacs@gnu.org; Tue, 28 Apr 2015 11:01:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Yn70Q-000353-Ou for bug-gnu-emacs@gnu.org; Tue, 28 Apr 2015 11:01:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2015 15:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143023325711823 (code B ref 19468); Tue, 28 Apr 2015 15:01:02 +0000 Original-Received: (at 19468) by debbugs.gnu.org; 28 Apr 2015 15:00:57 +0000 Original-Received: from localhost ([127.0.0.1]:42895 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn70H-00034X-Bb for submit@debbugs.gnu.org; Tue, 28 Apr 2015 11:00:57 -0400 Original-Received: from mtaout27.012.net.il ([80.179.55.183]:41241) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yn70B-00034G-K5 for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 11:00:52 -0400 Original-Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NNI00K00USQ5T00@mtaout27.012.net.il> for 19468@debbugs.gnu.org; Tue, 28 Apr 2015 17:55:47 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNI0087TUSZZEB0@mtaout27.012.net.il>; Tue, 28 Apr 2015 17:55:47 +0300 (IDT) In-reply-to: <553ECA9D.6090306@yandex.ru> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:102171 Archived-At: > Date: Tue, 28 Apr 2015 02:47:41 +0300 > From: Dmitry Gutov > CC: 19468@debbugs.gnu.org > > 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 Yes, but I'm unsure how is that relevant. Are you talking about auto-loading, or are you talking about a global minor mode? > 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. Sorry, you lost me. What aspects prevent us from making a global minor mode that uses xref-etags-mode in all buffers? > . 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. How is the old UI relevant here? We are talking about the new UI. (I already explained elsewhere that the old UI had "C-u M-." to go to the next match, whereas the new UI provides the *xref* buffer for that instead. So what the old UI did in this situation is not relevant, because the crucial feature of going to the next match, which was part of dealing with this situation in the old UI, is missing in the new UI. Thus, the new UI should find a different solution for this situation.) > I don't know if adding a new message in this case will be too helpful, but you're welcome to suggest the wording. I thought I already did, see above. > . 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. OK (did I say the documentation is missing?), but RET is the usual way of doing this, so I guess many users will. > > 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? Maybe, if/when I have time. The more important issue is how to go to the next candidate once the window showing *xref* is closed. > . 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. Possibly. > (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? Something like that, yes. There's also "C-x `". Or maybe you should bring the equivalent of tags-loop-continue back ;-) > Would you be comfortable with forgetting the current list of errors after navigating somewhere with xref? No, I don't think so. > 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. I don't see any xref-related code in ggtags. Did I miss something?