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 13:15:42 -0700 (PDT) Message-ID: <7ac81449-e004-46d6-ba10-72eadcc3961e@default> References: <2a7b9134-af2a-462d-af6c-d02bad60bbe8@default> <834mjecdy7.fsf@gnu.org> <38061f42-eaf1-47c6-b74d-f676ac952b18@default> <83r3miatvl.fsf@gnu.org> <83k2saaqwx.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 1441138575 31960 80.91.229.3 (1 Sep 2015 20:16:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 1 Sep 2015 20:16:15 +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 22:16:02 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 1ZWryJ-0004u4-J2 for ged-emacs-devel@m.gmane.org; Tue, 01 Sep 2015 22:15:59 +0200 Original-Received: from localhost ([::1]:58199 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWryJ-0003Mm-VD for ged-emacs-devel@m.gmane.org; Tue, 01 Sep 2015 16:15:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53572) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWryD-0003ML-9O for emacs-devel@gnu.org; Tue, 01 Sep 2015 16:15:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZWryC-00008K-3p for emacs-devel@gnu.org; Tue, 01 Sep 2015 16:15:53 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:42146) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWry7-00005v-2N; Tue, 01 Sep 2015 16:15:47 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t81KFjL1031756 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Sep 2015 20:15:46 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t81KFiSX017106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Sep 2015 20:15:45 GMT Original-Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t81KFigc027198; Tue, 1 Sep 2015 20:15:44 GMT In-Reply-To: <83k2saaqwx.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: 156.151.31.81 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:189422 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? ^^^^^^^^^^^^ > > > Because =E1 does include a diacritical. By specifying it, the user t= old > > > us the diacriticals are important, and shouldn't be disregarded. > > > > Again, you are just parroting what the implementation does >=20 > ??? I explained the interpretation of the user input, how's that > implementation? You described the current interpretation, by Emacs, of the user input =E1. That's "what the implementation does." That does not explain why use =E1 in a search string _should_ mean that diacriticals are important and shouldn't be disregarded. And that was the question I asked - why should this be the (only) behavior? Your answer is, just because it _is_ the behavior. Because it is the behavior, users expect it and we can interpret what they want in terms of it. Well yes, sure - it's the only choice they have now. It _is_ the behavior, so of course they use it accordingly. They type =E1 in order to match =E1. So what? > > 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 > You've got all the reasons, you just refuse to hear them. > Time to bail out. The only reason you gave is that this is what Emacs does now. And that that means that this is what a user expects. S?he types =E1 to match =E1 and a to match a (or variants, with char folding). User intention is clear here: s?he gets the behavior s?he asks Emacs for. QED. Sorry, that's not a reason _why_ this should be the (only) behavior available to a user. It's just repeating that users expect this behavior from Emacs and so act accordingly. That they get what they expect is no proof that that is the only useful behavior. It just shows that they know what Emacs does.