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: Sat, 02 May 2015 10:39:11 +0300 Message-ID: <831tizqvhc.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> <553EBBBF.6070509@yandex.ru> <838udcwbdc.fsf@gnu.org> <553FFC99.5080701@yandex.ru> <834mnzuedd.fsf@gnu.org> <554161A8.30202@yandex.ru> <83618du3q3.fsf@gnu.org> <5542E486.2010107@yandex.ru> <83k2wsssm8.fsf@gnu.org> <5543632C.6000306@yandex.ru> <834mnwsbfb.fsf@gnu.org> <554392E2.7080109@yandex.ru> <83oam4qh2u.fsf@gnu.org> <5543C97C.6050000@yandex.ru> <83h9rwqf10.fsf@gnu.org> <5543E3CF.5010402@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1430552428 11847 80.91.229.3 (2 May 2015 07:40:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 2 May 2015 07:40:28 +0000 (UTC) Cc: 19468@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat May 02 09:40:17 2015 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 1YoS24-0004iZ-7y for geb-bug-gnu-emacs@m.gmane.org; Sat, 02 May 2015 09:40:16 +0200 Original-Received: from localhost ([::1]:56305 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoS23-0006eu-HK for geb-bug-gnu-emacs@m.gmane.org; Sat, 02 May 2015 03:40:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38681) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoS20-0006ed-6a for bug-gnu-emacs@gnu.org; Sat, 02 May 2015 03:40:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YoS1w-0005ja-TR for bug-gnu-emacs@gnu.org; Sat, 02 May 2015 03:40:12 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49111) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoS1w-0005g0-Q0 for bug-gnu-emacs@gnu.org; Sat, 02 May 2015 03:40:08 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YoS1t-0002jg-8O for bug-gnu-emacs@gnu.org; Sat, 02 May 2015 03:40:05 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 May 2015 07:40:04 +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.143055237910477 (code B ref 19468); Sat, 02 May 2015 07:40:04 +0000 Original-Received: (at 19468) by debbugs.gnu.org; 2 May 2015 07:39:39 +0000 Original-Received: from localhost ([127.0.0.1]:59086 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoS1S-0002iu-1E for submit@debbugs.gnu.org; Sat, 02 May 2015 03:39:38 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:53464) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoS1P-0002ig-L4 for 19468@debbugs.gnu.org; Sat, 02 May 2015 03:39:37 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NNP00I00OWOPX00@a-mtaout22.012.net.il> for 19468@debbugs.gnu.org; Sat, 02 May 2015 10:39:28 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNP00ID1P9SEK70@a-mtaout22.012.net.il>; Sat, 02 May 2015 10:39:28 +0300 (IDT) In-reply-to: <5543E3CF.5010402@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:102358 Archived-At: > Cc: 19468@debbugs.gnu.org > From: Dmitry Gutov > Date: Fri, 1 May 2015 23:36:31 +0300 > > On 05/01/2015 10:22 PM, Eli Zaretskii wrote: > > > If it doesn't, it should ask the user. > > That's a speed bump. Yes. But the alternative, of producing output that the user deosn't want, or no output at all, is worse, don't you think? > How do you know another back-end won't return 140 results for "function > named car"? In the end, it's up to the backend's author to write an > implementation conforming to what's being asked of it. Yes, but the specification to which it should conform should be more detailed, otherwise some back-end could very well claim conformance and still produce such large lists. The restrictions, such as "only exact matches" or "only functions" etc. should be a necessary part of the API -- then and only then would it be possible to reject a back-end that returns 140 hits for "exact matches only" query. > > Note the "I" vs the "we". If _you_ want to see only one match most of > > the time, you should be able to customize the feature to do just that. > > Others could customize it differently, according to their use cases. > > It will still be the same command, though. > > There's nothing to note. While *I* can only speak for myself, Stefan > expressed a similar preference. IIRC, both Jorgen and Helmut did so as well. So at best you have 80% of users that would want the same as you. What about the other 20%? Shouldn't we provide customizable options for them, even though they might be a minority? > Of course, I'd be happy to make it more customizable, if it can still > work well enough for me, at least in one configuration. But I'll need > more concrete design proposals on that. My proposal was to come up with types of matches (I mentioned them already several times), and then let the users customize the collection of types passed to the back-end by default. Whether this translates immediately to some design, I don't know, although it seemed to me it does. > I wonder if it's even possible to define a set of levels in a > backend-agnostic way. I think it is. > For instance, for etags you have "exact matches", > "exact implicit matches", "word matches", "partial file name matches", etc. Except for "implicit matches" that should actually be part of the same generalized class as "exact matches", the rest are quite general, I think. > In the Elisp backend, I'd see the "same kind of entity", "other kinds of > entities with that name", "fuzzy matches on the name". "Fuzzy" is "substring" in etags, "same/other kinds" should be translated to "functions/variables" etc. > Keep in mind though, that if we introduce the notion of levels in the > interface, it'll also complicate things for every implementor. The goal is to provide a better user experience, not to make life easier for the implementors. But if a certain back-end can do a good job by implementing only one level, into which all the levels will map, then it's an okay solution for that back-end's targets.