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, 30 Dec 2014 18:00:24 +0200 Message-ID: <83oaqlb013.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1419955281 13983 80.91.229.3 (30 Dec 2014 16:01:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Dec 2014 16:01:21 +0000 (UTC) Cc: dgutov@yandex.ru, 19468@debbugs.gnu.org To: Helmut Eller Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 30 17:01:13 2014 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 1Y5zEO-0007vS-7C for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Dec 2014 17:01:12 +0100 Original-Received: from localhost ([::1]:37330 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5zEN-0005oO-Ha for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Dec 2014 11:01:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56999) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5zEJ-0005lX-Ie for bug-gnu-emacs@gnu.org; Tue, 30 Dec 2014 11:01:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y5zEE-0002jV-Jq for bug-gnu-emacs@gnu.org; Tue, 30 Dec 2014 11:01:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51817) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5zEE-0002jR-Gx for bug-gnu-emacs@gnu.org; Tue, 30 Dec 2014 11:01:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Y5zEE-0001Aa-20 for bug-gnu-emacs@gnu.org; Tue, 30 Dec 2014 11:01:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 16: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.14199552424442 (code B ref 19468); Tue, 30 Dec 2014 16:01:02 +0000 Original-Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 16:00:42 +0000 Original-Received: from localhost ([127.0.0.1]:32950 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y5zDt-00019Y-Gg for submit@debbugs.gnu.org; Tue, 30 Dec 2014 11:00:42 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:60821) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y5zDp-00019E-Ou for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 11:00:39 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NHE00L00K84BS00@a-mtaout20.012.net.il> for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 18:00:35 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NHE00KJJKGYYWB0@a-mtaout20.012.net.il>; Tue, 30 Dec 2014 18:00:35 +0200 (IST) In-reply-to: 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:97836 Archived-At: > From: Helmut Eller > Cc: Dmitry Gutov , 19468@debbugs.gnu.org > Date: Tue, 30 Dec 2014 09:19:18 +0100 > > >> Why doesn't it put me on "display_line"s line, and display its > >> definition at the same time? > > As Dmitry says: that would replace the current buffer and at the same > time create and switch to the *xref* buffer. I had tried that and it > didn't like it. But that's what the old M-. did, so it should be at least an option, IMO. > >> This is a regression from the old tags > >> feature, where just "M-. RET" will already show the first matching > >> definition. > > It's not a regression as M-. is now a different command with a different > UI. My goal was never to be 100% backward compatible with find-tag but > to make something better. You lost your key binding for find-tag. Sorry > about that, but there are only so many good keys. Of course, you know > how to get the old key binding back. But etc/NEWS says that find-tag is now obsolete. So I think the replacement should be at least as good, in terms of usability and speed. I didn't ask for 100% backward compatibility, I'm asking for convenience and speed. I don't think they are unreasonable requests. > >> Further, this buffer's name, *xref*, has no mnemonic significance, and > >> there are no clues as to what it wants to tell me or what is expected > >> of me. > > > > Would you like it to be called the same as the current command? > > *xref-find-definitions-other-window*, *xref-find-apropos*, etc? > I bet that after 15 minutes of using it, nobody will care what the name > of the *xref* buffer is. So we can just as well use something short. I don't see how the length of the buffer's name is important here. Short names are okay if they explain themselves; this one doesn't. We periodically have discussions full of flames about discoverability in Emacs and its steep learning curve. It is my impression as a user that the name of this buffer, its specialized keybindings, and lack of instructions, don't make the curve less steep, to say the least. I hope we can do better, as the problems don't seem to be grave or hard to fix. > >> By trial and error I found out that I'm expected to move to the > >> candidate I want with cursor movement keys, > > Trial and error isn't the worst way to learn things; at least if it > doesn't take too long. Turns out I missed '.' and ',', though. So trial and error are evidently less efficient than we would want. > Apparently you didn't even need to read any documentation What documentation? These commands are not yet in the manual. Or maybe you meant this: M-. runs the command xref-find-definitions (found in global-map), which is an interactive autoloaded Lisp function in `xref.el'. It is bound to M-., . (xref-find-definitions IDENTIFIER) Find the definition of the identifier at point. With prefix argument, prompt for the identifier. That's the entire doc string of the command, all of it. (Btw, it doesn't even say that if no identifier is found at point, it will prompt even without an argument.) I hope now you understand why I needed to "try and err". > >> Another peculiarity is that once I press arrow once, I can no > >> longer get back to the first line, the one that shows the source > >> file: > > That's as expected. There is nothing to select on the first line. Then why let me position point there? > >> In sum: please make the new feature at least as good as the old one it > >> replaces. > > You can't make progress by keeping everything the same. Once again, no one asked for "the same". I'm asking for the new feature to be at least as convenient and fast as the one it replaces. The two issues that I find annoying about this are: the first candidate is not displayed until I press a key, and I'm unable to find functions that the current major mode doesn't know about. I hope these can be fixed, they don't seem major to me. Thanks.