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: Sun, 26 Apr 2015 17:56:37 +0300 Message-ID: <837fszx7iy.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1430060321 4250 80.91.229.3 (26 Apr 2015 14:58:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 26 Apr 2015 14:58:41 +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 Sun Apr 26 16:58:29 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 1YmO0o-0003m2-PF for geb-bug-gnu-emacs@m.gmane.org; Sun, 26 Apr 2015 16:58:27 +0200 Original-Received: from localhost ([::1]:51048 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmO0o-0001dj-66 for geb-bug-gnu-emacs@m.gmane.org; Sun, 26 Apr 2015 10:58:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38448) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmO0U-0000vz-Dy for bug-gnu-emacs@gnu.org; Sun, 26 Apr 2015 10:58:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YmO0R-0005Au-83 for bug-gnu-emacs@gnu.org; Sun, 26 Apr 2015 10:58:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:50747) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmO0R-0005Am-4H for bug-gnu-emacs@gnu.org; Sun, 26 Apr 2015 10:58:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YmO0Q-0007jI-D4 for bug-gnu-emacs@gnu.org; Sun, 26 Apr 2015 10:58: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: Sun, 26 Apr 2015 14:58: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.143006028029704 (code B ref 19468); Sun, 26 Apr 2015 14:58:02 +0000 Original-Received: (at 19468) by debbugs.gnu.org; 26 Apr 2015 14:58:00 +0000 Original-Received: from localhost ([127.0.0.1]:40523 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmO0O-0007j2-3k for submit@debbugs.gnu.org; Sun, 26 Apr 2015 10:58:00 -0400 Original-Received: from mtaout27.012.net.il ([80.179.55.183]:54732) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmO0L-0007ik-4y for 19468@debbugs.gnu.org; Sun, 26 Apr 2015 10:57:58 -0400 Original-Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NNF00K005762800@mtaout27.012.net.il> for 19468@debbugs.gnu.org; Sun, 26 Apr 2015 17:51:53 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNF00J0L5AHG010@mtaout27.012.net.il>; Sun, 26 Apr 2015 17:51:53 +0300 (IDT) In-reply-to: <54ABBB47.7010603@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:102057 Archived-At: So, prompted by the renewed discussion of 'xref', I took another look at the current states of affairs with the UI, and found the following issues: . xref-etags-mode: I tried this mode, and found a few places for improvement: . It's not available by default: 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. . 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". 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. . 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. I think it would be more helpful to just switch to the window showing the definition, but leave the *xref* buffer shown. . 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.) . No replacement for tags-loop-continue: If I somehow let the window showing *xref* close (e.g., by typing RET, see above), what is the equivalent for tags-loop-continue, i.e. display the next candidate, without explicitly displaying the *xref* buffer again? If there isn't one, please provide it, at least as part of xref-etags-mode. (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.) . The back-end issue: . Caveat: I couldn't find any documentation of back-ends, so perhaps I'm missing something important. That being said... . I tried the ELisp back-end and found that it somehow affects the UI, so that the UI behaves differently than with the default etags back-end, when the user types something that is "complete, but not unique": when using the etags back-end, Emacs displays a list of candidates in the *xref* buffer, whereas with the elisp-mode back-end it shows the "complete" candidate, doesn't display *xref*, and doesn't insert the other candidates into *xref*. Is this difference intended? It's confusing, to say the least. . xref.el says: ;; For now, make the etags backend the default. (defvar xref-find-function #'etags-xref-find 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? . The doc string of xref-find-function mentions several variants of invoking the function, but there doesn't seem to be any way of controlling that when invoking the function interactively, is there? I think it would be good to be able to lookup only the definitions or only the references of a symbol. HTH