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, 8 Sep 2015 14:25:45 -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> <21998.29683.916211.867479@a1i15.kph.uni-mainz.de> <9A972800-D8F0-4DA8-877E-07D5BDC2E1F9@gmail.com> <87oahd11i9.fsf@uwakimon.sk.tsukuba.ac.jp> <8cf269bc-69d8-4752-8506-de8d992512e1@default> 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 1441747641 28687 80.91.229.3 (8 Sep 2015 21:27:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Sep 2015 21:27:21 +0000 (UTC) Cc: stephen@xemacs.org, jean.christophe.helary@gmail.com, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 08 23:27:07 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 1ZZQPw-0001lk-RL for ged-emacs-devel@m.gmane.org; Tue, 08 Sep 2015 23:27:04 +0200 Original-Received: from localhost ([::1]:37940 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZQPw-0001td-CY for ged-emacs-devel@m.gmane.org; Tue, 08 Sep 2015 17:27:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48208) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZQOq-00010Z-RI for emacs-devel@gnu.org; Tue, 08 Sep 2015 17:25:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZQOn-0005Kx-LV for emacs-devel@gnu.org; Tue, 08 Sep 2015 17:25:56 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:49727) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZQOn-0005KK-Fr; Tue, 08 Sep 2015 17:25:53 -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 t88LPlfC019403 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Sep 2015 21:25:47 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t88LPlOU019379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Sep 2015 21:25:47 GMT Original-Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t88LPkRF023664; Tue, 8 Sep 2015 21:25:47 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: 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:189745 Archived-At: > > Nothing more. What's good for `e' should be good for `=C3=A9' and > > all the rest. It's about equivalence classes. >=20 > That would be a change for the worse, since it would reduce the range > of searches that the user can specify with one character in the > search. Not at all. It adds to what the user can do. It does not subtract. > Currently the user can either search for "any kind of e" or "only =C3=A9" > or "only =C3=A8" or "only =C3=AA", etc. That would still be the case. The only difference would be that when s?he wants to search for "any kind of e" s?he can use any of the equivalent e-chars. Any of [e=C3=A9=C3= =A8=C3=AA=C3=A6=C3=AB] would behave the same as `e' does not, when searching for any of [e=C3=A9= =C3=A8=C3=AA=C3=A6=C3=AB]. > With your change, the user would be limited to searching for "any kind > of e". That would be a step back in flexibility. Not at all. Just as now, the user can toggle char folding OFF, to search for the search string literally, i.e., to take its chars as what they are, and not consider them as representative of an equivalence class. With folding OFF, `e' searches only for `e'; `=C3=A9' searches only for `= =C3=A9', and so on. These are all of the possible possibilities, for `e' and `=C3=A9': Folding ON/OFF Search string char Buffer chars that match -------------- ------------------ ----------------------- OFF e [e] OFF =C3=A9 [=C3=A9] ON e [e=C3=A9=C3=A8=C3=AA=C3=A6=C3=AB] ON =C3=A9 [e=C3=A9=C3=A8=C3=AA=C3=A6=C3=AB]= <=3D=3D=3D=3D=3D=3D=3D MISSING NOW And the same goes for any of the other e-chars. With folding off it matches only itself. With folding on it matches any of its class. This proposal adds more matching possibilities. It does not remove any possibilities. Currently, you cannot do what is shown in the last line above. You cannot use =C3=A9 to search for [e=C3=A9=C3=A8=C3=AA=C3=A6=C3=AB]. Sim= ilarly, you cannot use a curly quote to search for other kinds of quote marks. You are currently limited to using only the "canonical" chars that represent their class. That removes the possibility of pasting text into the search string and being able to get char-folding search. Quote marks are a good example chars in text that you might copy and try to search for. To do that, if the copied text contained curly quotes then you would need to use `M-e' and edit the search string, to convert each of them to the corresponding "canonical" member of the quotation-mark equivalences, an ascii quote mark. There is no good reason to make users jump through such a hoop. (Plus, they would need to know what the "canonical" char is, for each equivalence class they might want to use.) Let any member of a class represent the class. > Since the current interface is fairly natural, there is no loss in > offering the user all these options. All what options? The proposal does not remove any matching options. On the contrary, it adds matching options. > I would not oppose offering a configuration setting to get the > behavior you want. There is nothing to lose with that. But the > current behavior is a more useful default than the behavior you would > like. Did you understand what is being proposed, when you wrote that? If so, how is the current restriction to `e' for matching [e=C3=A9=C3=A8=C3= =AA=C3=A6=C3=AB] more useful than letting any e-char do the same?