From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: UI inconveniences with M-. Date: Tue, 28 Apr 2015 22:41:27 -0400 Message-ID: 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> <83r3r5wqwv.fsf@gnu.org> <83k2wxwexb.fsf@gnu.org> <83fv7kwbow.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1430275321 20204 80.91.229.3 (29 Apr 2015 02:42:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Apr 2015 02:42:01 +0000 (UTC) Cc: emacs-devel@gnu.org, dgutov@yandex.ru To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 29 04:41:52 2015 Return-path: Envelope-to: ged-emacs-devel@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 1YnHwe-0000S2-0O for ged-emacs-devel@m.gmane.org; Wed, 29 Apr 2015 04:41:52 +0200 Original-Received: from localhost ([::1]:36575 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YnHwc-00086l-QY for ged-emacs-devel@m.gmane.org; Tue, 28 Apr 2015 22:41:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35780) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YnHwN-00083p-Ps for emacs-devel@gnu.org; Tue, 28 Apr 2015 22:41:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YnHwL-0003G4-Ue for emacs-devel@gnu.org; Tue, 28 Apr 2015 22:41:35 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:2473) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YnHwI-0003EC-5l; Tue, 28 Apr 2015 22:41:30 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAGvvdVRMCqjW/2dsb2JhbAA3gVOhb4EIgXUBAQQBViMFCws0EhQYDSSIE6IRi3YFAgUBCQ8CAQMJOoNNA4NwBKNjhFg X-IPAS-Result: AgUFAGvvdVRMCqjW/2dsb2JhbAA3gVOhb4EIgXUBAQQBViMFCws0EhQYDSSIE6IRi3YFAgUBCQ8CAQMJOoNNA4NwBKNjhFg X-IronPort-AV: E=Sophos;i="5.11,557,1422939600"; d="scan'208";a="117736967" Original-Received: from 76-10-168-214.dsl.teksavvy.com (HELO pastel.home) ([76.10.168.214]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Apr 2015 22:41:30 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id DCF2E4650; Tue, 28 Apr 2015 22:41:27 -0400 (EDT) In-Reply-To: <83fv7kwbow.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 28 Apr 2015 17:48:47 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:185991 Archived-At: [ Moving this to emacs-devel. ] >> > Emacs 24 also had "C-u M-." to go to the next one. This one doesn't; >> > moreover, if you try "C-u M-.", you get prompted for the symbol again, >> > and if you type the same one, you get nowhere. The other matches are >> > only available via completion, see below. >> Maybe we should write an xref-old-ui-mode. > I didn't ask for the old UI. (If I want it, I can still have it, > since the etags.el commands are still available.) I'm okay with the > new UI. This bug report is about the new UI, and its goal is to make > the new UI better. Then I don't understand what you mean by the text I quoted. E.g.: if you try "C-u M-.", you get prompted for the symbol again, and if you type the same one, you get nowhere Well, duh! What did you expect? In the new UI, "C-u M-." jumps to *the* definition (the "C-u" is only used to let you type the name of thing you're looking for), so of course if you just jumped to it, asking to jump to it again will get you nowhere else. I guess it would be OK to make M-. emit a message like "Hello? We're already here!" in this corner case, if you want to make sure something happens. > old UI was consistent and complete: it always displayed the first/next > match and provided a command to go to the next/previous one. By > contrast, the new UI is inconsistent: with some back-ends it shows the > list of matches and allows to navigate it, with others it shows only > the first match and does not give any way to get the next match. In the "M-. find-tag" example, the UI does let you see all matches. It's just that there's only one. If you want, we could make this case popup an *xref* buffer with a single entry, but I think it makes more sense to just jump straight to that one entry instead. > But that's largely immaterial: this bug report is not about the > back-end, it's about the UI. I wouldn't be so sure. >> Arguably, the find-tag advice in org-ctags.el could be offered as well, >> if org-ctags.el happens to be loaded > ??? Why should the xref matches depend on what is and isn't loaded? Because that's how xref/elisp works. > That would make xref exactly equivalent to "M-x apropos", which means > this mode of operation would make xref entirely redundant. To you, maybe. Personally, I find it's *much* quicker to use M-. than to use C-h f RET RET, and it has the added benefit that M-, brings me right back if I need to. > To say nothing of the fact that this doesn't scale to any language > except ELisp. Not at all. Many (most?) packages which offer a functionality along the lines of "M-. to jump to the definition" use an implementation technique which is fundamentally similar/equivalent (obviously, they don't query a running Emacs, but they query a running REPL). > We could offer this mode as an optional feature, but it certainly > shouldn't be the default. Many users here disagree. > (One of my worst annoyances is to type a C-h command and be presented > with "[No match]", because some package is not loaded or some function > is not available in the Emacs configuration I happen to be using.) Yes, that's a long standing problem, indeed. I have a local hack which tries to add to loaddefs.el a concise description of where definitions might be found (basically, for each file, list the few prefixes used in that file), so that "C-h f" can load those packages when needed. It's "proof of concept" and it has occasionally rendered my Emacs session unusable (e.g. because it ended up deciding to try and load, say, w32-fns.el to see if it might contain the definition). I think I've now solved most of those problems in the w32-* files, but the underlying risk is still there. > That's one way of looking at it. Another is to say that etags gave > you more information and thus allowed to find more loose matches, > which is helpful when your memory is failing you. M-. jumps to the definition of the "thing under point". There's no memory involved. If you're not sure what you're looking for, then you're expected to use the completion facilities in C-u M-. > But in the context of this bug report, that, too, is immaterial: if we > think the etags back-end gives too much information, by all means > let's filter it before presenting the matches. Yes, that's clearly very much needed. > Bonus points for making the filtering optional, since some people > might like that, and in some situations even you might need it. I disagree. The filtering is needed by the design of the xref API. If you want to see the "unfiltered" data, then use M-x xref-find-apropos. > Then let's fix the results we display with the etags back-end to show > only the relevant ones. Yes, please. > Saying that the back-end returns a confusingly large amount of bogus > matches, and then switching to a UI that assumes much smarter > back-ends (which don't really exist) makes very little sense to me. The smarter backends already exist, in so far as there is already code out there which provides the needed functionality. It just doesn't use the xref API yet, because it was written before xref.el. > The old code attempted to support both use cases, by showing the exact > match(es) first, followed by less likely ones. We do similar things > in other commands. The advantages of such a method are that (1) you > don't need to second-guess the user, (2) you provide only one command > for the user to remember, and (3) if the user only _thinks_ she knows > the name, but really doesn't, she can find the information without > having to invoke another command. >> I think that's an important feature of the new code in this respect. > But it is incomplete without a means to get to the other possible > matches in this case. > To summarize my points in this sub-thread: > . the UI should depend much less on the back-end, ideally not at all You keep repeating this, but that is absolutely meaningless to me (kind of like "it doesn't work" in bug reports): - This consistency was trivially obtained with the old etags.el code since it had one 1 backend. - What the fuck should the new UI do if one backend returns 1 match and another returns a hundred (as in your "find-tag" example)? > . there should be a way to go to the next/previous match if the > *xref* buffer is not displayed (or not created in the first > place); if this happens because there's only one match, we should > say so explicitly The only case where the *xref* is not displayed is when there's only 1 match returned by the backend. So "go to the next/previous match" is again meaningless. > . when there are more than one possible match, the UI should behave > similarly, i.e. display the *xref* buffer; when there's only one > match, it should _never_ display *xref*, That's exactly what the code does. > and should display an indication of the fact that there's only one > match The current code "displays" this indication by jumping to the sole match instead of jumping to the *xref* buffer. I think it's clear enough. > . if the criteria for filtering of the matches are very different > between the possible back-ends, there should be some agreed-upon > uniform default that returns roughly the same number of matches > with all back-ends, and the rest should be controlled by user > options I don't see what that could concretely look like. Stefan