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: Thu, 30 Apr 2015 01:56:40 +0300 Message-ID: <554161A8.30202@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> 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 1430348244 23781 80.91.229.3 (29 Apr 2015 22:57:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Apr 2015 22:57:24 +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 Thu Apr 30 00:57:13 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 1Ynaul-000304-Ui for geb-bug-gnu-emacs@m.gmane.org; Thu, 30 Apr 2015 00:57:12 +0200 Original-Received: from localhost ([::1]:41347 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ynaul-0004Nl-1T for geb-bug-gnu-emacs@m.gmane.org; Wed, 29 Apr 2015 18:57:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49358) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ynaui-0004Ln-8D for bug-gnu-emacs@gnu.org; Wed, 29 Apr 2015 18:57:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ynaud-0005sz-77 for bug-gnu-emacs@gnu.org; Wed, 29 Apr 2015 18:57:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46802) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ynaud-0005sv-4k for bug-gnu-emacs@gnu.org; Wed, 29 Apr 2015 18:57:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Ynauc-0006C8-Kr for bug-gnu-emacs@gnu.org; Wed, 29 Apr 2015 18:57: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: Wed, 29 Apr 2015 22:57: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.143034821023792 (code B ref 19468); Wed, 29 Apr 2015 22:57:02 +0000 Original-Received: (at 19468) by debbugs.gnu.org; 29 Apr 2015 22:56:50 +0000 Original-Received: from localhost ([127.0.0.1]:56777 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnauQ-0006Bf-0x for submit@debbugs.gnu.org; Wed, 29 Apr 2015 18:56:50 -0400 Original-Received: from mail-wi0-f178.google.com ([209.85.212.178]:33484) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnauO-0006BS-0W for 19468@debbugs.gnu.org; Wed, 29 Apr 2015 18:56:48 -0400 Original-Received: by wief7 with SMTP id f7so434353wie.0 for <19468@debbugs.gnu.org>; Wed, 29 Apr 2015 15:56:42 -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=rkhLn9SfwF5BCyVBn6eYD5pkpkrPElOWBI+VwMOGoO8=; b=JCJFDsElwx/zAGYdVToFV09S0gQkRfSw1mVYH9n4Zwln+t13F3mZXWwOdRvh1tUe3u tcdW3gNYFkIOB9E6BBWP/cwxw92zw6ZfV4IA/fuHoth9h79CsIL6xmlIDpnwvKQ3m8F9 y/VB0hdC6CwJVa2eZGnJUm+jQJjo02yoD1LskZnXZ+KDTWK7sONY3lI/GUer4MGBYJd/ cL5ht6iU/I+wKtSbUbHK67z9/ivr7sOxYdcNxHEkiyHZ3Ls3wqVCA4Vh2XT/HOLNWJsf C8v2fIfPD5R8K5X41v57eEdPwLsKZcrq140IhcMmUDkwwsxpbYTknXOAd2vW9yd9v6dc p/lw== X-Received: by 10.180.7.133 with SMTP id j5mr10161930wia.84.1430348202425; Wed, 29 Apr 2015 15:56:42 -0700 (PDT) Original-Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id v3sm1115677wix.8.2015.04.29.15.56.41 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2015 15:56:42 -0700 (PDT) user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 in-reply-to: <834mnzuedd.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:102268 Archived-At: On 04/29/2015 06:46 PM, Eli Zaretskii wrote: > I'd suggest first an exact match, followed by any matches that are > exact but for letter-case. I think we've settled on "only exact matches" (to the best of backend's ability) for xref-find-definitions. However, in xref-find-apropos we shouldn't like the exact matches that much, and likely care about all matches. In that command's output we could use the order in which etags returns its results. >> Without using the order, in which matches are returned by the backend, we can't even know what the "best matches" are. > > Of course, we can: see above. The backend can. The UI can't, thus far (unless only the best matches are returned to it). > Moreover, ideally the API to the back-end should allow the UI to > control the matches applied by the back-end, so that the UI gets only > the matches it wants in the first place. Would you like to describe it in more detail? The current main options are: "give me matches for this name" and "give me matches for this regexp". There's nothing that would correspond to find-tag-tag-order. > Not sure what is included in "the rest". For example, I don't think > it makes sense to disregard tag-implicit-name-match-p, since many tags > don't have explicit names. Okay. > In general, I think it would be good to have a user option that > controls which predicates are used by the etags back-end. I think we > should group the predicates into meaningful groups (e.g., it makes no > sense to use tag-exact-match-p without tag-implicit-name-match-p). > The default list of the predicates should IMO include these: > > tag-exact-match-p tag-implicit-name-match-p tag-symbol-match-p See the newly added defvar `etags-xref-find-definitions-tag-order'. The last element seems a bit too lax to me, but it's up to you.