From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: char equivalence classes in search - why not symmetric? Date: Tue, 1 Sep 2015 11:46:11 -0700 (PDT) Message-ID: References: <2a7b9134-af2a-462d-af6c-d02bad60bbe8@default> <834mjecdy7.fsf@gnu.org> <38061f42-eaf1-47c6-b74d-f676ac952b18@default> <83r3miatvl.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1441133952 21596 80.91.229.3 (1 Sep 2015 18:59:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 1 Sep 2015 18:59:12 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 01 20:59:00 2015 Return-path: Envelope-to: ged-emacs-devel@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 1ZWqln-0003ZR-R8 for ged-emacs-devel@m.gmane.org; Tue, 01 Sep 2015 20:58:59 +0200 Original-Received: from localhost ([::1]:57061 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWqlo-0006cY-2G for ged-emacs-devel@m.gmane.org; Tue, 01 Sep 2015 14:59:00 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55022) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWqZa-0001LC-Uz for emacs-devel@gnu.org; Tue, 01 Sep 2015 14:46:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZWqZW-0006I4-V5 for emacs-devel@gnu.org; Tue, 01 Sep 2015 14:46:22 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:25013) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWqZS-0006EK-9E; Tue, 01 Sep 2015 14:46:14 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t81IkCYp032114 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Sep 2015 18:46:13 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t81IkC44018080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Sep 2015 18:46:12 GMT Original-Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t81IkC7N025901; Tue, 1 Sep 2015 18:46:12 GMT In-Reply-To: <83r3miatvl.fsf@gnu.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:189414 Archived-At: > > > We are asking for matches that disregard the diacriticals > > > (and in case of =AA also higher-order collation-order variation). > > > > No. You are asking for that only when you use a search pattern > > that does not use the diacriticals. When you search with =E1 in > > the pattern you are NOT asking for matches that disregard the > > diacriticals. And why not? >=20 > Because =E1 does include a diacritical. By specifying it, the user told > us the diacriticals are important, and shouldn't be disregarded. Again, you are just parroting what the implementation does, not giving a reason supporting it. By turning on folding, a user can be said to be choosing to disregard diacriticals. Again, both options for fold matching should probably be available. There is no reason to hard-code one of them at design time. At least no reason has been put forth so far. =20 > > > It's what the Unicode Standard recommends, and IMO it makes a > > > lot of sense. See http://unicode.org/reports/tr10/#Searching. > > > > I don't see that, when reading that section. I do see that it > > explicitly calls out that behavior as an _option_: > > > > 8.2 Asymmetric Search > > Users often find asymmetric searching to be a useful option. >=20 > "Users often find asymmetric searching to be a useful option" sounds > like a recommendation to me. No, it is not. Not at all. That, and all of the text about this, makes clear, AFAICT, that this is a useful OPTIONAL behavior. That is the language used: "a useful option". Nowhere (AFAICT) is there any language supporting an interpretation of this as the recommended behavior. The language instead clearly points out that there are different behaviors covered by the report. And the one that is complex and needs explanation is clearly called out as an optional behavior. Not the recommended behavior, but a useful behavior to consider for inclusion as an option. Anyway, thanks for confirming that there was not some text that I missed, which in fact recommends asymmetric matching.