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 17:41:10 +0200 Message-ID: <83tx0db0x5.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 1419954139 28383 80.91.229.3 (30 Dec 2014 15:42:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Dec 2014 15:42:19 +0000 (UTC) Cc: eller.helmut@gmail.com, 19468@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 30 16:42:12 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 1Y5yvz-0000ow-O5 for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Dec 2014 16:42:11 +0100 Original-Received: from localhost ([::1]:37268 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5yvz-0000ZN-7P for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Dec 2014 10:42:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52308) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5yvu-0000ZI-65 for bug-gnu-emacs@gnu.org; Tue, 30 Dec 2014 10:42:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y5yvq-0004fH-TP for bug-gnu-emacs@gnu.org; Tue, 30 Dec 2014 10:42:06 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51812) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5yvq-0004fB-Q8 for bug-gnu-emacs@gnu.org; Tue, 30 Dec 2014 10:42:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Y5yvq-0000V9-Hk for bug-gnu-emacs@gnu.org; Tue, 30 Dec 2014 10:42: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 15:42: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.14199540871858 (code B ref 19468); Tue, 30 Dec 2014 15:42:02 +0000 Original-Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 15:41:27 +0000 Original-Received: from localhost ([127.0.0.1]:32945 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y5yvG-0000Tt-6K for submit@debbugs.gnu.org; Tue, 30 Dec 2014 10:41:26 -0500 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:39048) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y5yvC-0000Tf-DB for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 10:41:23 -0500 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NHE00K00JCDP800@mtaout28.012.net.il> for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 17:39:12 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NHE00JCBJHCVU10@mtaout28.012.net.il>; Tue, 30 Dec 2014 17:39:12 +0200 (IST) In-reply-to: <54A24079.4020902@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:97835 Archived-At: > Date: Tue, 30 Dec 2014 08:04:41 +0200 > From: Dmitry Gutov > CC: Helmut Eller > > On 12/29/2014 10:26 PM, Eli Zaretskii wrote: > > Why doesn't it put me on "display_line"s line, and display its > definition at the same time? This is a regression from the old tags > feature, where just "M-. RET" will already show the first matching > definition. > > > It's a tradeoff. Otherwise, you'd see two new buffers at once, possibly covering both windows (if you have two). Sorry, I don't follow. I started that from a single window, and M-. already did split it into 2, and displayed the candidates in the lower one. So I already see 2 buffers, and showing the first candidate in the upper window doesn't do anything I won't expect -- after all, I did ask to see something different from what I was already seeing. > And it seems inconsistent with your further complaint that movement visits files automatically (if it shouldn't, it shouldn't start with displaying the buffer at point either). I see no inconsistency: we could display the first candidate automatically, but not switch to others without the user's say-so. Imagine a situation where the list of possible candidates is very long, longer than what the window shows. Then the user might wish to scroll the list of candidates before she makes up her mind about the one she wants to see. But moving point visits the candidates, which is not what the user asked for in this use case. Moreover, I see that scrolling the window by C-v/PageDn does _not_ visit the tags at point, while scrolling by up- and down- arrow key does. Looks like another confusing inconsistency. So I suggest that the automatic visiting will be at least customizable, if not switched off by default. > Compared to `find-tag', you see the list of all possible definitions (and only if there are several). What are the odds that the first location is the right one anyway? With completion? excellent. Moreover, the old find-tags employed some logic in its completion, so that matches that are more likely appear first. I generally found the results very good, certainly in languages which require symbols to have unique names on the source level. > 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? How about "*find-function-candidates*" or even "*Completions*"? > The candidates are not mouse-sensitive, either, which is > un-Emacsy. It functions like *Completions*, but it ain't one. > > > One might argue that using the mouse is also un-Emacsy. That ship sailed a long time ago. > But sure, that shouldn't be hard to add (and would increase discoverability). More importantly, it will tell the user what she needs to do, even if she doesn't use the mouse, because mouse-sensitive portions of Emacs display generally behave very similarly. > By trial and error I found out that I'm expected to move to the > candidate I want with cursor movement keys, > > > Or with `.' and `,', which are a bit easier to press right after `M-.'. It would be nice to have some instructions to this effect. Once again, this is not a UI that is used in other places in Emacs, it is very different. So you shouldn't assume that its keybindings are known by users, especially keybindings such as '.' and ',' that are not widely used in other programs, and therefore must be learned anew. > > Moving up an down is slow, probably because it visits files > > without waiting for RET or some other gesture to select a candidate > (why was that design decision made?). > > If you look at the related thread in emacs-devel, you'll see that it hasn't been discussed at all. Helmut implemented it this way, and apparently everyone that looked at it (the few people that did), liked it. I expect it will have its admirers, since helm-swoop, a package with the same visual effect, is pretty popular. I described above one use case where I think this reaction to moving point will not be appreciated by users, since Emacs moves point as result of scrolling. > This can be made configurable, though. For instance, `C-o' could be that "other gesture". Would you prefer the window configuration restored before point moves to a different line, or should the new buffer keep being displayed? The latter presents a challenge if we want `q' in the xref buffer to restore the original window configuration before xref-find-definitions was invoked, as long as the user hadn't made any manual changes thereafter. Why is it a challenge? Typing 'q' and 'C-o' can invoke different functions, can't it? I'm probably missing something. > > Hitting RET on the first line, > > the one that shows the file name, results in "No reference at point", > which is not really useful. > > > Would you prefer to navigate to the first line of that file? That seems unlikely. My point is that putting me on that line when the buffer pops up makes little sense, because that line is just a heading. > 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: > pressing on the 2nd line doesn't move point, but it does return > the original buffer to the window above *xref*. Weird. > > A bit weird, yes. Would you prefer not to "return the original buffer"? No, I prefer that the lines that show file names be not reachable at all. They are just clutter, as far as moving point is concerned. Let point jump over them. > Finally, invoking the same command from the menu bar ought to present > a dialog box with the candidates, according to the general rule: if a > command was invoked by a mouse gesture, selection of candidates is via > a GUI dialog, not a special-purpose buffer. But that doesn't happen. > > Example? Click File->Quit when you have unsaved edits. > Since when do we have a working completion interface that uses a GUI dialog ("open file" doesn't count)? If it's as fully functional, then sure, we should use that. But this is not completion, this is a list of completion results. Completion happens _before_ the *xref* buffer is popped up. Or am I missing something? > As a counterpoint, Buffers->Select Named Buffer... uses the minibuffer. That _is_ completion. I'm not talking about prompting the user for a symbol, I'm talking about _displaying_ the matching symbols once the user has typed her input. > In sum: please make the new feature at least as good as the old one it > replaces. > > I'd say it's already much better, but maybe not in all respects. And the latter would be a tough goal. I don't think we can deprecate/obsolete find-tag unless xref is at least as good. And I don't see any reasons why it couldn't become as good or better, the issues I mentioned seem to be minor and easy to fix. > And when introducing new exhibits, like the *xref* window, > please make them self-explanatory and convenient/natural to use for > newbies and veterans alike. > > That's a great ideal to strive for, but a poor criterion for acceptance (convenient and natural are subjective notions). I agree it's subjective, but I think I provided explanations for my views. > When the veterans don't participate in the discussion about a new feature, I suspect having follow-up discussions in bug reports would often be inevitable. I'm sorry I didn't participate. The reason is that I never understood this is meant as a replacement for find-tag etc., until you asked whether to remove them from the menu bar. The discussion was long enough and focused on technicalities enough to turn me off. Perhaps a prominent announcement of the intent to replace Tags, with explicit reference to that word in the Subject, would have done a better job of attracting people who might have had something to say about this. Thanks.