From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#19468: 25.0.50; UI inconveniences with M-. Date: Fri, 1 May 2015 23:36:31 +0300 Message-ID: <5543E3CF.5010402@yandex.ru> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1430512643 17387 80.91.229.3 (1 May 2015 20:37:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 1 May 2015 20:37:23 +0000 (UTC) Cc: 19468@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri May 01 22:37:12 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 1YoHgM-0001va-8P for geb-bug-gnu-emacs@m.gmane.org; Fri, 01 May 2015 22:37:10 +0200 Original-Received: from localhost ([::1]:55481 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoHgL-0002ij-Ke for geb-bug-gnu-emacs@m.gmane.org; Fri, 01 May 2015 16:37:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35256) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoHgI-0002iT-BG for bug-gnu-emacs@gnu.org; Fri, 01 May 2015 16:37:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YoHgE-0007PR-Su for bug-gnu-emacs@gnu.org; Fri, 01 May 2015 16:37:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:48984) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoHgE-0007PL-Q7 for bug-gnu-emacs@gnu.org; Fri, 01 May 2015 16:37:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YoHgE-0000Do-95 for bug-gnu-emacs@gnu.org; Fri, 01 May 2015 16:37:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 May 2015 20:37:02 +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.1430512602826 (code B ref 19468); Fri, 01 May 2015 20:37:02 +0000 Original-Received: (at 19468) by debbugs.gnu.org; 1 May 2015 20:36:42 +0000 Original-Received: from localhost ([127.0.0.1]:58959 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoHfu-0000DG-4x for submit@debbugs.gnu.org; Fri, 01 May 2015 16:36:42 -0400 Original-Received: from mail-wg0-f53.google.com ([74.125.82.53]:35395) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoHfr-0000D2-7f for 19468@debbugs.gnu.org; Fri, 01 May 2015 16:36:40 -0400 Original-Received: by wgyo15 with SMTP id o15so100067030wgy.2 for <19468@debbugs.gnu.org>; Fri, 01 May 2015 13:36:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=ebjzAng9SiD986u1Nor79jEHZcIE+KgG0kPBnzlESjc=; b=oTC1R3fp+yJgyMY4c0O2HbebbDNqZOQbvr1Xlt2I2bPv/Mt7PH/G0yp+IDNqmXJ8PS kx1u1ILUNVIW6McpzFIglW0jXTVNoLiqsNutGVlBhkt6Uw+IJPzm3H74bo2nbvgr60KG hUv9+j6l5Xq2QYI1EBgL8wG82pOOHwEuckLXiXFDt8Ya2WQuB9qAGrWNqr7Y1xNGTqIb rAXMsMqFK0J7t5xvcwX7ALTLQSH1kEii3xi+LygOrXmTtHDaug/umgdytdgtDyCCfM+7 9pkgYv7zb+rLoITHVQ5RFtxfeTrSd1bs26CkuP1wkiaJAJYPdlWUuiWWz8CLwRYB0rVV ojjw== X-Received: by 10.180.208.42 with SMTP id mb10mr15918011wic.80.1430512593623; Fri, 01 May 2015 13:36:33 -0700 (PDT) Original-Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id k9sm8122862wia.6.2015.05.01.13.36.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 May 2015 13:36:33 -0700 (PDT) user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 in-reply-to: <83h9rwqf10.fsf@gnu.org> 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:102345 Archived-At: On 05/01/2015 10:22 PM, Eli Zaretskii wrote: > If it doesn't, it should ask the user. That's a speed bump. Not to say that a generic symbol-browsing facility handling different kinds of them won't be useful, but that's not what I see `M-.' doing. > The example is still valid. How do you know another back-end won't do > something similar? 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. > 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. 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. > Other IDEs ask the user explicitly to specify how wide she wants the > search and how detailed the results. We could do that as well, > although I think it's less Emacsy. That hasn't been my experience. They do have different commands for different searches, but those vary between editors. Yet, there's always a "go to definition" command that tries its best not to ask the user anything else, and jumps to wherever the symbol at point was "defined". It's usually bound to Ctrl-Click. > But having just one level is never right in such cases. I wonder if it's even possible to define a set of levels in a backend-agnostic way. For instance, for etags you have "exact matches", "exact implicit matches", "word matches", "partial file name matches", etc. In the Elisp backend, I'd see the "same kind of entity", "other kinds of entities with that name", "fuzzy matches on the name". Keep in mind though, that if we introduce the notion of levels in the interface, it'll also complicate things for every implementor. Maybe the solution is to define the ability for a backend to return groups, probably nested ones.