From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: UI inconveniences with M-. Date: Fri, 01 May 2015 21:32:15 +0300 Message-ID: <83pp6kqhcg.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1430505202 25277 80.91.229.3 (1 May 2015 18:33:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 1 May 2015 18:33:22 +0000 (UTC) Cc: emacs-devel@gnu.org, dgutov@yandex.ru To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 01 20:33:15 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 1YoFkP-0000KQ-SM for ged-emacs-devel@m.gmane.org; Fri, 01 May 2015 20:33:14 +0200 Original-Received: from localhost ([::1]:55171 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoFkP-00016K-2I for ged-emacs-devel@m.gmane.org; Fri, 01 May 2015 14:33:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41848) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoFk8-00015l-IW for emacs-devel@gnu.org; Fri, 01 May 2015 14:32:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YoFk3-0001eY-Lf for emacs-devel@gnu.org; Fri, 01 May 2015 14:32:56 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:36293) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoFk3-0001eS-94 for emacs-devel@gnu.org; Fri, 01 May 2015 14:32:51 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NNO00D00OSBPN00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Fri, 01 May 2015 21:32:31 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNO00DNWOU6CK70@a-mtaout22.012.net.il>; Fri, 01 May 2015 21:32:31 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 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:186095 Archived-At: > From: Stefan Monnier > Cc: dgutov@yandex.ru, emacs-devel@gnu.org > Date: Fri, 01 May 2015 10:21:04 -0400 > > > 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. Not according to my references. > > 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. Isn't that what I said? > 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. Emacs has a school-book solution for these problems: let the user specify what she wants, with prefix arguments and user options. My point was that a back-end that isn't prepared for such degree of control, and decides for the user what she wants is not just "imperfect", it's semi-broken. > etags.el also failed miserably in some scenarios which xref/elisp > handles acceptably. E.g. try C-u M-. diff-mode-abrev-table RET. I don't see diff-mode-abrev-table in TAGS, so I don't understand what you want to demonstrate with that. > > 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. No, I said that blaming the back-end for what I observed, and saying that nothing can be done "because that's what the back-end gives" is not the right way of approaching these kinds of problems. > > 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. The 140 hits are symbol names, not just locations. Discerning between exact matches, caseless matches, and partial matches does not need any language-specific knowledge. I don't understand what problems you see here. But if you are certain that the fixes belong to the back-end, it's fine with me. Just don't tell me that the back-end is to blame, and therefore there's nothing that can be done. > > 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 question is which smarts. I'm saying that the UI cannot blindly trust the back-end to always DTRT, it needs to control it according to its needs and user preferences. These smarts _must_ be in the UI. Having just 2 or 3 query types -- either get me only one match or give me all of them -- is too rough, there must be more shades of gray, and more ways for the user to extend and refine the query. The old API provided an approximation to this by returning a long list in order of importance, so where you stopped asking for more was a rather crude, but usually effective way of getting exactly what you wanted. This is now gone, so we must find other, hopefully better ways of giving the user the same fine-grained control on what she gets in response to a query. > > 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. This issue is tangential to the subject f this discussion. My complaints are valid even if you work with a single project, and in fact were observed while working with a single project. > >> 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. Irrelevant. I wasn't saying etags was better, or didn't have disadvantages. I was talking about deficiencies of the current solution, as a whole, for looking up definitions of symbols. I don't really care which back-end is used for that, but I do care about the results, and I do care when if I switch back-ends and suddenly get very different results. > (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). Yes, I'm an annoying guy. Feel free to ask me to step down and disappear from here, if that annoys you too much. (The profanities are already a sign of that.) > > Building TAGS is almost instant, even in Emacs, > > The problem is not computer-time but human-time. What human time? The time it takes to type "make TAGS"? > > 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. Emacs can guess where the user _might_ want it, but it has to allow for seldom exceptions, otherwise how can the user switch to another project or add its data to the current one? > > 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. It's definitely an option for this curmudgeon, if the new-and-improved solution will not become better. > > That "little detail" all but invalidates most of my use cases. > > Then don't use that backend. E.g. use xref-etags-mode. Are we again talking about my personal problems? If they are only mine, I can solve them very easily, and don't need this discussion or the bug reports to do so. What do you tell users whose use case is similar to mine? "Use xref-etags-mode"? Then why did we switch away of etags.el, if we still need to use its core machinery? > >> 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. I don't want 2 different commands. I know about etags-apropos as well, but never used it, because I never needed to. Forcing me to use 2 different commands where I could use one is an annoyance. Anyway, I'm out of this discussion. Good luck selling your ideas and use cases to others. I'm not sold. And I don't enjoy having to read uncalled-for profanities in response to legitimate questions and issues.