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: Wed, 29 Apr 2015 17:54:04 -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> <837fsvuefq.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1430344469 24193 80.91.229.3 (29 Apr 2015 21:54:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Apr 2015 21:54:29 +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 23:54:20 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 1YnZvs-0005iE-3K for ged-emacs-devel@m.gmane.org; Wed, 29 Apr 2015 23:54:16 +0200 Original-Received: from localhost ([::1]:41204 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YnZvr-0008F8-Mk for ged-emacs-devel@m.gmane.org; Wed, 29 Apr 2015 17:54:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39612) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YnZvo-0008C6-GO for emacs-devel@gnu.org; Wed, 29 Apr 2015 17:54:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YnZvm-0001YY-PX for emacs-devel@gnu.org; Wed, 29 Apr 2015 17:54:12 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:47085) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YnZvi-0001Xk-AC; Wed, 29 Apr 2015 17:54:06 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAGvvdVS4rw4V/2dsb2JhbAA3gVOhb4EIgXUBAQQBViMFCws0EhQYDSQuh2WiEYk7gjkBAQIEBgEBCAELAwMFBAM6g00Dg3AEo2OEWIE3 X-IPAS-Result: AgUFAGvvdVS4rw4V/2dsb2JhbAA3gVOhb4EIgXUBAQQBViMFCws0EhQYDSQuh2WiEYk7gjkBAQIEBgEBCAELAwMFBAM6g00Dg3AEo2OEWIE3 X-IronPort-AV: E=Sophos;i="5.11,557,1422939600"; d="scan'208";a="117839636" Original-Received: from 184-175-14-21.dsl.teksavvy.com (HELO pastel.home) ([184.175.14.21]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2015 17:54:04 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 679F04DCE; Wed, 29 Apr 2015 17:54:04 -0400 (EDT) In-Reply-To: <837fsvuefq.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 29 Apr 2015 18:44:41 +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:186043 Archived-At: >> In the "M-. find-tag" example, the UI does let you see all matches. >> It's just that there's only one. > We already agreed that there were at least 2. No, we agreed that in some ideal world there could be two. But the backend as it is written now, only returns one for that case. > More importantly, the issue that I was raising in that example is that > the results change too radically when the back-end is changed. IMO, > it makes no sense to display more than 140 candidates with one > back-end, and only one with another, in the default configuration. I agree the 140 "matches" are absurd and need to be fixed. The single match of the other backend is what I want, OTOH. > Once again, I never said that a single match should be popped in a > buffer. I said that I don't expect to see a single match in this > case, because that's a lie! No, it's not a lie and I would even argue it's neither a bug nor a misfeature. You expect etags-style information from the xref/elisp backend, but that's simply not the info it tries to give you. > compelled to respond. But my perspective in filing the bug report was > the perspective of a user looking at the results through the UI, and > trying to use that UI to manipulate the results. See, you use the term "UI" in a completely different way. When I say "UI" in this discussion, I'm talking about the code which takes the info from the backend and makes it available to the user. So the fact that one backend returns 1 item and the other returns 140 of them is completely outside of the control of the UI. Maybe the resulting end-user experience sucks, but that's not the fault of the UI but the fault of the backends. The reason why I use the term UI in this way is because the API is designed so that you can have several UIs using the same API (just like you can have several backends). >> >> 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. > If so, then it's much less useful than I thought. And to me, it makes it more useful. > I don't see how such a back-end can even be a candidate for becoming > the default. And I don't see how we've live with the etags.el UI for so many years. I've tried several times to make real use of it, but always found it completely unpalatable. What with having to build those damn TAGS files, remember to refresh them, remember where they are, constantly tell Emacs again where they are, deal with its inability to find the right spot and having to repeat the "C-u M-." finger gymnastics umpteen times. xref/elisp may not let you jump to those functions/vars that aren't yet loaded, but beside this little detail, it *just works* without any extra setup, nothing. > Apropos pops up a new window, and 'q' quits it, so that problem has a > solution there as well. But the apropos is just an intermediate, what I want to see is the corresponding source, and by the time I'm there, I can't so easily use `q' to go back. >> 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). > Think about compiled languages. AFAIK, JDEE used the same approach for Java. [ There's no such thing as "a compiled language". I guess you mean "think of the case where your language's implementation uses good old static compilation scheme". ] I don't claim that all backends will have to work this way. Just that it's a common implementation technique. > If those many use mainly ELisp or REPL-type language interpreters, I > can understand why. But Emacs is not limited to those. And neither is the xref API. > Until that problem is solved in core, I don't see how a back-end that > requires to load a package can be the default. Agreed. >> > 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. > I was talking about "C-u M-." C-u M-. also lets you do loose matching, via completion, if your memory is failing you. >> If you're not sure what you're looking for, then you're expected to use >> the completion facilities in C-u M-. > Completion shows only part of the matches, we've been through that > already. It doesn't by default show substring matches. For one, you can make substring the default by tweaking the completion styles configuration, if you so prefer. The default completion is partial-completion, which is actually "more powerful" than substring matching: e.g. "*find-tag" would not only match "find-tag-tag" and "my-own-find-tag" but also "my-finder-tag". But there's nothing magical about substring matching anyway. etags.el used it because it was easy to implement, not because it is the best thing there is. Of course, it's good, but partial-completion is also good, and many other options are also good. > I didn't say "unfiltered". I asked for user control of the amount of > filtering or of looseness of the matches. In etags.el terms, think > about giving the user control on what goes into find-tag-tag-order. That's OK, then. It seems that etags is simply unable to give sufficiently reliable data to filter it effectively, so we're stuck with heuristics and user-knobs to choose where they're rather get bitten. > Once again, I question the decision to switch to this UI, when we I know, but that's just a waste of time. The backends won't come before this system is standard and common place (and they'll take their time, because in the mean time they can keep using their ad-hoc UI which also works on older Emacsen). > But having 2 orders of magnitude difference between the results > _by_default_ is absolutely insane! Agreed, because the etags backend sucks right now. > It's not!! There are partial matches shown by completion -- they are > the next candidates. Again, you choose to look at it this way because you're used to the way etags.el worked. But to me, "find-tag" and "find-tag-tag" are not two different matches to my request. They're just two completely unrelated things: either I'm looking for one or I'm looking for the other. The design of xref is based on the hope that the backend can return a very small list of candidates, ideally of length 1. That's not always the case, but for most potential backends (other than those based on heuristic techniques like regexp-matching) it's pretty close. >> > . 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. > User options to control how loose the matches are, and the default > level of looseness that yields similar results. Feel free to implement another UI on top of this API which provides this functionality. I sure will stay away from it, because I have no use for something which wastes my time showing me unrelated functions whose name just happen to contain the name of my function as a substring. On the contrary, I want a tool that's precise, and gets me directly to the only corresponding definition (in the 99% of the cases where there's indeed only one) with a single key-press and no questions asked. Stefan