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: Fri, 01 May 2015 21:38:01 +0300 Message-ID: <83oam4qh2u.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1430505562 30652 80.91.229.3 (1 May 2015 18:39:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 1 May 2015 18:39:22 +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 Fri May 01 20:39: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 1YoFqA-0004tI-Pj for geb-bug-gnu-emacs@m.gmane.org; Fri, 01 May 2015 20:39:10 +0200 Original-Received: from localhost ([::1]:55193 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoFqA-0003a4-BL for geb-bug-gnu-emacs@m.gmane.org; Fri, 01 May 2015 14:39:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43475) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoFq7-0003Zz-Cy for bug-gnu-emacs@gnu.org; Fri, 01 May 2015 14:39:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YoFq3-0003wp-6l for bug-gnu-emacs@gnu.org; Fri, 01 May 2015 14:39:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:48958) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoFq3-0003wl-2t for bug-gnu-emacs@gnu.org; Fri, 01 May 2015 14:39:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YoFq2-0005u4-Kv for bug-gnu-emacs@gnu.org; Fri, 01 May 2015 14:39:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 May 2015 18:39: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.143050550922651 (code B ref 19468); Fri, 01 May 2015 18:39:02 +0000 Original-Received: (at 19468) by debbugs.gnu.org; 1 May 2015 18:38:29 +0000 Original-Received: from localhost ([127.0.0.1]:58933 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoFpT-0005tG-DS for submit@debbugs.gnu.org; Fri, 01 May 2015 14:38:28 -0400 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:44169) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YoFpP-0005sw-BM for 19468@debbugs.gnu.org; Fri, 01 May 2015 14:38:24 -0400 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NNO00E00OQDJQ00@mtaout28.012.net.il> for 19468@debbugs.gnu.org; Fri, 01 May 2015 21:37:10 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNO00D2VP1XO220@mtaout28.012.net.il>; Fri, 01 May 2015 21:37:10 +0300 (IDT) In-reply-to: <554392E2.7080109@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:102341 Archived-At: > Cc: 19468@debbugs.gnu.org > From: Dmitry Gutov > Date: Fri, 1 May 2015 17:51:14 +0300 > > On 05/01/2015 03:57 PM, Eli Zaretskii wrote: > > > Sorry, I don't understand what "Elisp environment at runtime" means in > > practice, or how it's used to affect what results are returned for a > > query. > > find-func knows about defined functions and defined variables. > elisp-mode knows that a function usually goes after a paren, and a > variable - after a space (to simplify things). > > Thus, elisp-xref-find could narrow the search space based on whether > there is a paren before the symbol at point (we don't do that, partially > because the situation is more complicated; but we should, in the > future). A language-agnostic UI won't ever be able to do so. A language-agnostic UI could well ask the back-end for variables, or for functions, or for both, or whatever. Like I said: some functionality must reside in the back-end, but the UI must control it, instead of blindly trusting its defaults. When we blindly trust the defaults of each back-end, we get what triggered this discussion, because etags' default is to produce a 140-long list of potential matches, which elisp-mode's xref default is to produce only one. In most of my use cases, neither is TRT. > > That's the case where the UI should instruct the back-end what it > > needs, because the back-end doesn't know which of these alternatives > > is the right one. If the user wants all bar functions, or maybe those > > whose parent class matches some regexp, not just the one from the > > class instance at point, then producing only one match would be wrong, > > and the UI won't be able to correct that. > > If the user calls xref-find-definitions, we consider that to see the > definition of the function called at point (or definitions, if virtual > dispatch is unavoidable, such as in case of a Java interface, and there > are several options), but not more. We shall never second-guess the user. I already described an important class of use cases where this assumption is simply wrong. It shouldn't probably even be the default. > For more lax matching options, the user will call xref-find-apropos. It's an annoyance to have to use more than one command for a single purpose.