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: Thu, 30 Apr 2015 16:48:20 +0300 Message-ID: <83618du3q3.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1430401768 17207 80.91.229.3 (30 Apr 2015 13:49:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 30 Apr 2015 13:49: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 Thu Apr 30 15:49: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 1Ynoq0-0006Za-0Z for geb-bug-gnu-emacs@m.gmane.org; Thu, 30 Apr 2015 15:49:12 +0200 Original-Received: from localhost ([::1]:43924 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ynopz-0007mI-Fx for geb-bug-gnu-emacs@m.gmane.org; Thu, 30 Apr 2015 09:49:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58500) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ynopv-0007m8-EP for bug-gnu-emacs@gnu.org; Thu, 30 Apr 2015 09:49:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ynopr-0003JH-Ad for bug-gnu-emacs@gnu.org; Thu, 30 Apr 2015 09:49:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:47143) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ynopr-0003JD-76 for bug-gnu-emacs@gnu.org; Thu, 30 Apr 2015 09:49:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Ynopq-0005i2-NN for bug-gnu-emacs@gnu.org; Thu, 30 Apr 2015 09:49: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: Thu, 30 Apr 2015 13:49: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.143040171821908 (code B ref 19468); Thu, 30 Apr 2015 13:49:02 +0000 Original-Received: (at 19468) by debbugs.gnu.org; 30 Apr 2015 13:48:38 +0000 Original-Received: from localhost ([127.0.0.1]:57118 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnopR-0005hH-BK for submit@debbugs.gnu.org; Thu, 30 Apr 2015 09:48:38 -0400 Original-Received: from mtaout27.012.net.il ([80.179.55.183]:51988) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YnopN-0005gz-VT for 19468@debbugs.gnu.org; Thu, 30 Apr 2015 09:48:35 -0400 Original-Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NNM00E00GI8QE00@mtaout27.012.net.il> for 19468@debbugs.gnu.org; Thu, 30 Apr 2015 16:43:28 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNM00CY7GSG2130@mtaout27.012.net.il>; Thu, 30 Apr 2015 16:43:28 +0300 (IDT) In-reply-to: <554161A8.30202@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:102281 Archived-At: > Cc: monnier@IRO.UMontreal.CA, 19468@debbugs.gnu.org > From: Dmitry Gutov > Date: Thu, 30 Apr 2015 01:56:40 +0300 > > 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. I believe the default in Emacs is to use caseless searches in these situations, and leave it to the user to either customize case-fold-search or type the exact letter-case if she wants such exact matches. With languages that customarily use both letter-cases, I see no reason to deviate from that practice. > However, in xref-find-apropos we shouldn't like the exact matches that > much, and likely care about all matches. Yes. > In that command's output we could use the order in which etags > returns its results. I agree. > >> 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). If it can't, it's probably because no one coded that. But the rules are not so complex, so it's not inconceivable that such code could exist in the UI. > > 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. Why not learn from find-tag-tag-order, and allow the same categories of matches as it uses, sans those that make no sense outside of the TAGS data? > > 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. Thanks, I will take a look soon.