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: Wed, 9 Sep 2015 20:15:50 -0700 (PDT) Message-ID: <5c860cd6-6453-4d7e-971b-bb047f6c9b1e@default> References: <<2a7b9134-af2a-462d-af6c-d02bad60bbe8@default> <834mjecdy7.fsf@gnu.org> <38061f42-eaf1-47c6-b74d-f676ac952b18@default> <83r3miatvl.fsf@gnu.org> <21998.29683.916211.867479@a1i15.kph.uni-mainz.de> <83pp1s7w1m.fsf@gnu.org>> <<87lhcg38x7.fsf@mail.linkov.net> <83y4gg5n4q.fsf@gnu.org>> <> <> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1441855010 23148 80.91.229.3 (10 Sep 2015 03:16:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Sep 2015 03:16:50 +0000 (UTC) Cc: eliz@gnu.org, emacs-devel@gnu.org, ulm@gentoo.org, bruce.connor.am@gmail.com, juri@linkov.net To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 10 05:16:33 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 1ZZsLb-0005IC-5c for ged-emacs-devel@m.gmane.org; Thu, 10 Sep 2015 05:16:27 +0200 Original-Received: from localhost ([::1]:46619 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZsLQ-0001cB-Sp for ged-emacs-devel@m.gmane.org; Wed, 09 Sep 2015 23:16:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47984) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZsLE-0001bT-GC for emacs-devel@gnu.org; Wed, 09 Sep 2015 23:16:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZsLD-0002N8-HX for emacs-devel@gnu.org; Wed, 09 Sep 2015 23:16:04 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:21552) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZsL8-0002M2-Hr; Wed, 09 Sep 2015 23:15:58 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t8A3FraW014232 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Sep 2015 03:15:54 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t8A3FqiV008778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 10 Sep 2015 03:15:53 GMT Original-Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t8A3Fpxo012357; Thu, 10 Sep 2015 03:15:51 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] 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:189785 Archived-At: > > They are equivalence classes. The chars are equivalent when searched > > for (with char folding turned on). >=20 > No, they aren't. For instance, A and =C3=81 are not equivalent in search= . > Searching for A will match =C3=81, but searching for =C3=81 will not matc= h A. Please read what I said: "The chars are equivalent when searched for." ^^^^^^^^^^^^^^^^^ I did *not* say, as you say, that they are "equivalent in search." I tried to carefully distinguish the two uses of the chars: when used as search targets (they are currently equivalent) vs when used in the search string (they are not equivalent, currently). If you search for A with char folding on you will find both A and =C3=81 (and all the rest of the A family). All members of that family (class) are equivalent _as search targets_. Currently. 100% equivalent. They form an equivalence class wrt the operation of searching _for_ them. They are not yet equivalent also as search patterns, i.e., when used in the search string. That is the proposal of this thread: to make them equivalent also in their use in a search string (when char folding is turned on). =20 > To make them equivalent would be a change for the worse. > I already explained why. The only explanation I saw from you was that you want the presence of an accented char in the search string to automatically turn off char folding. That's your preference. It leads to an absolute reduction of possibilities for users (they cannot use abstract from accented search when there are accented chars in the search string). But you have every right to prefer that limitation. Please be aware that with what is being proposed a user can still, anytime, get diacritic-sensitive search when there are accented chars in the search string (and when there not). It is sufficient to toggle off char folding. You want that toggling off to happen automatically, based on the mere presence of an accented char in the search string. I don't, because users lose the possibility of getting char-folded search whenever there are accented chars in the search string. They then need to edit the search string if they want to abstract from diacritics, replacing any such chars with the unaccented ("base") versions, in order to get char-fold search. In the code I sent, I provided a user option, to let _users_ decide which behavior they want, individually: the one you prefer or the one I prefer. Why not give them the choice?