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: Fri, 01 May 2015 10:21: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> <837fstu3zh.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1430490090 1246 80.91.229.3 (1 May 2015 14:21:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 1 May 2015 14:21:30 +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 Fri May 01 16:21: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 1YoBod-0004Cd-8v for ged-emacs-devel@m.gmane.org; Fri, 01 May 2015 16:21:19 +0200 Original-Received: from localhost ([::1]:54215 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoBoc-0004hr-LD for ged-emacs-devel@m.gmane.org; Fri, 01 May 2015 10:21:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50051) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoBoV-0004hW-SV for emacs-devel@gnu.org; Fri, 01 May 2015 10:21:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YoBoU-0003Dm-Hc for emacs-devel@gnu.org; Fri, 01 May 2015 10:21:11 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:27139) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoBoP-0003DQ-Fp; Fri, 01 May 2015 10:21:05 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAGvvdVS4rw4V/2dsb2JhbAA3gVOhb4EIgXUBAQQBViMFCws0EhQYDSSIE6IRi3YCBQ8CCQMBAgEBAgk6g00Dg3AEo2OEWA X-IPAS-Result: AgUFAGvvdVS4rw4V/2dsb2JhbAA3gVOhb4EIgXUBAQQBViMFCws0EhQYDSSIE6IRi3YCBQ8CCQMBAgEBAgk6g00Dg3AEo2OEWA X-IronPort-AV: E=Sophos;i="5.11,557,1422939600"; d="scan'208";a="117985879" 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; 01 May 2015 10:21:04 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 943C06ADE; Fri, 1 May 2015 10:21:04 -0400 (EDT) In-Reply-To: <837fstu3zh.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 30 Apr 2015 16:42:42 +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:186080 Archived-At: > If the back-end conceals potentially useful information, it should be > fixed not to do so. "Conceal" makes it sound like it's ill-intentioned, done on purpose or something. For (defadvice find-tag ...), the problem is in advice.el. Patches welcome, but since this library is on the way out AFAIC, I'd recommend you don't bother spending time on it. > That you personally find that information always redundant does not > mean it's true for everyone else. There's more than one use case for > these queries, see below. We can't know what the user wants and handle all conceivable scenarios. Maybe the user really wants to jump to this chunk of code somewhere that does (fset foo bar) and hence ends up overriding the "official" definition of the function. But unless you can solve the halting problem and read the user's mind at the same time, we'll have to settle for something imperfect. etags.el also failed miserably in some scenarios which xref/elisp handles acceptably. E.g. try C-u M-. diff-mode-abrev-table RET. > That's your misunderstanding. I described my user experience from > using this new feature; I never said where the fixes should be made, Well, you kept insisting that it's not a question of backend, so maybe you didn't say where the fixes should go, but you did say where the blame should go. > Says you. Through my naive-user eyes, filtering 140 hits to provide > just a few is perfectly within the capabilities of the UI, at least in > principle. The 140 hits are just a list of locations. The UI has no fucking clue whether these are function definitions or what, nor does it know in which language the file is written. > IOW, the separation of functionality is in the wrong place. To be > useful, some of the "smarts" need to be on the UI side, where user > control can be best implemented, and where user intent is known much > better. The UI has to be agnostic. So the smarts can't be in the UI. The API can be extended to provide the extra smarts that the UI might need, of course. E.g. we could add to the API a function that sorts/groups the entries, so the etags backend can sort them based on "likelyhood" rather than group them by file. > I very much hope Emacs will continue to be able to support the kind of > activities I described above, which AFAIK are very important part of a > software developer's job throughout the industry. You fail to understand why complaint about etags.el. I'm not complaining about `etags', but about the etags.el front-end, which is in need of improvement to handle the case where the user is navigating several completely different projects and doesn't want one to pollute the other one. >> 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. > Those are exaggerations. Partly, yes. I'm just venting my frustration with the tool, and pointing out that if xref/elisp (and xref/etags) has some downsides, etags.el had its own set of downsides. And some of those shouldn't be that hard to fix (tho they would probably be a lot easier if we didn't have to worry about annoying some old-time users because they'd have to slightly change their habits). > Building TAGS is almost instant, even in Emacs, The problem is not computer-time but human-time. > you need only refresh them very seldom, and Emacs offers the > place from which to load them so you don't need to remember. If Emacs knows where the file is, the user shouldn't need to be queried. > But this, again, is immaterial for this discussion. I hope you will > agree that, whatever issues we have with etags, replacing it with > something that lacks important functionality is not a good idea. As I said, going back to etags.el is not an option. > That "little detail" all but invalidates most of my use cases. Then don't use that backend. E.g. use xref-etags-mode. >> C-u M-. also lets you do loose matching, via completion, if your memory >> is failing you. > I don't think completion is the right tool for these searches, because > the name alone doesn't tell enough. Don't pretend you don't know about xref-apropos. > See above: you assume that the division of functionality between the > UI and the back-ends is at the right place. No I don't. I don't assume the API is fixed either. All I assume is that the UI can't know about the programming language or about the quality of any given answer, or any such thing. >> 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. > Assuming you know what you are looking for, yes. I described a > situation that is frequent for me where you generally don't, at least > not well enough to be satisfied by a single exact match. And that's not what M-. for. For that we have xref-apropos. > And therein lies its weakness. I actually don't understand how this > kind of assumption could be allowed to exist, when the _default_ Because this assumption is known to be obtainable, with help from the toolchain (the compiler will generally know with 100% certainty the few possible definitions matching a particular use). Stefan