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 09:45:51 +0300 Message-ID: <83k2wsssm8.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1430463480 10607 80.91.229.3 (1 May 2015 06:58:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 1 May 2015 06:58:00 +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 08:57:51 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 1Yo4tR-0005aX-8R for geb-bug-gnu-emacs@m.gmane.org; Fri, 01 May 2015 08:57:49 +0200 Original-Received: from localhost ([::1]:47103 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yo4tQ-0007WL-On for geb-bug-gnu-emacs@m.gmane.org; Fri, 01 May 2015 02:57:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40963) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yo4iA-00006K-18 for bug-gnu-emacs@gnu.org; Fri, 01 May 2015 02:46:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yo4i6-0002m3-R1 for bug-gnu-emacs@gnu.org; Fri, 01 May 2015 02:46:09 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:48085) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yo4i3-0002lo-Co for bug-gnu-emacs@gnu.org; Fri, 01 May 2015 02:46:06 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Yo4i2-00076E-Ic for bug-gnu-emacs@gnu.org; Fri, 01 May 2015 02:46: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 06:46: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.143046276127286 (code B ref 19468); Fri, 01 May 2015 06:46:02 +0000 Original-Received: (at 19468) by debbugs.gnu.org; 1 May 2015 06:46:01 +0000 Original-Received: from localhost ([127.0.0.1]:58060 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yo4i0-00075x-Tu for submit@debbugs.gnu.org; Fri, 01 May 2015 02:46:01 -0400 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:51479) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yo4hx-00075i-5T for 19468@debbugs.gnu.org; Fri, 01 May 2015 02:45:58 -0400 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NNN00L00RRKC200@mtaout25.012.net.il> for 19468@debbugs.gnu.org; Fri, 01 May 2015 09:41:35 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNN009QBRXBUDA0@mtaout25.012.net.il>; Fri, 01 May 2015 09:41:35 +0300 (IDT) In-reply-to: <5542E486.2010107@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:102314 Archived-At: > Cc: 19468@debbugs.gnu.org > From: Dmitry Gutov > Date: Fri, 1 May 2015 05:27:18 +0300 > > On 04/30/2015 04:48 PM, Eli Zaretskii wrote: > > > 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. > > Yeah, that still works like that. "Followed by any matches ... but for > letter-case" simply means to me to use case-insensitive matching in the > first place, since the backend doesn't return matches in groups. I'd still suggest to place the exact matches first. The UI could do that. > > 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. > > Still, that doesn't sound like a good idea. Backends know their > languages better. I don't see anything language-specific here. Etags.el has no language-specific knowledge, either (it is delegated to etags.c). Like I said elsewhere, I think making the UI too dumb might give us sub-optimal design, wrt how functionality is divided between the UI and the back-ends, and in particular produce more of unhappy user experiences caused by the UI relying on the back-ends too much, and the back-ends differing between them too much. Case sensitivity, partial matches, and other similar stuff employed by etags, and conceptually by any other similar facility, has almost nothing to do with languages. And if (and when) we want to support match rules that do depend on languages, the API should allow specifying such rules to the back-end, and the back-end should DTRT when it receives a spec it cannot support. For example, if the UI requests only exact letter-case match, and the back-end is for a case-insensitive language, that back-end should produce caseless matches nonetheless. > > 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? > > From where I'm standing, that's a customization preference, not a > design suggestion. The latter would include a proposal of changes to the > xref-find-function interface. I stopped short of providing a complete proposal. My design suggestion is to generalize and abstract the match types used by etags. Customization preferences might then control which subset of the set of match types are used for each query.