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:46:00 -0700 (PDT) Message-ID: <9fff9ff9-f66f-4341-9360-a3035337c10f@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> <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 1441748833 15394 80.91.229.3 (8 Sep 2015 21:47:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Sep 2015 21:47:13 +0000 (UTC) Cc: stephen@xemacs.org, jean.christophe.helary@gmail.com, emacs-devel@gnu.org To: rms@gnu.org, Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 08 23:46:52 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 1ZZQio-0004Rt-1n for ged-emacs-devel@m.gmane.org; Tue, 08 Sep 2015 23:46:34 +0200 Original-Received: from localhost ([::1]:38049 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZQin-0004Er-Ja for ged-emacs-devel@m.gmane.org; Tue, 08 Sep 2015 17:46:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55484) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZQiT-0004Bs-Fu for emacs-devel@gnu.org; Tue, 08 Sep 2015 17:46:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZQiO-0007BT-E5 for emacs-devel@gnu.org; Tue, 08 Sep 2015 17:46:13 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:31995) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZQiO-0007BH-86; Tue, 08 Sep 2015 17:46:08 -0400 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t88Lk2vC021203 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Sep 2015 21:46:02 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t88Lk2ST012420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Sep 2015 21:46:02 GMT Original-Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t88Lk1Yq032473; Tue, 8 Sep 2015 21:46:02 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: userv0021.oracle.com [156.151.31.71] 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:189746 Archived-At: > > Personally, yes, I would get rid of that anomaly too at some > > point, but I'm not proposing that now. Likewise, for the > > anomaly that whitespace folding is switched off by SPC SPC. >=20 > SPC SPC should match only a pair of spaces! This is not the topic of this thread. But if and when we get to that discussion (if I'm still around in 20 years ;-)), the right answer is the same as for the current proposal, which is about char folding: Just toggle whitespace-folding OFF. "Just say NO" to SPC SPC matching any string of whitespace. Whitespace folding will stay off as long as you do not toggle it ON. And you can customize the default behavior so that it starts either ON or OFF. (I'm not a fan of whitespace folding most of the time, so I will turn it OFF by default, personally. I do want SPC SPC to match only two consecutive spaces, nearly all the time.) The simple idea is that folding is either on or off. When on, equivalence classes are used - whether for diacritics ("char folding"), or for case (case folding), or for whitespace (whitespace folding). But that's just a preview of a possible FUTURE discussion. No one is proposing NOW that we change the current behavior of case folding or whitespace folding. The topic here, now, is char folding - whether it should treat all chars of a class the same or not. What do you LOSE with the proposed behavior (for char folding now, and perhaps for case or whitespace folding later)? You lose the fact that any particular members of an equivalence class are "canonical", and so using one of them during folding automatically switches folding off. E.g., currently, using =C3=A9 in a search string turns char folding off. And of course using an uppercase char turns case folding off. And SPC SPC turns whitespace folding off. What do you GAIN with the proposed behavior? You need not type a particular, privileged member of a class in order to match any member of the class. Any member will match any member (including itself, of course). The point is to have users explicitly hit a key to toggle folding. That enables the use of any char in a class to match any other char in the same class. That's the tradeoff. With the proposal, there is nothing to remember, no exceptions or special rules. Folding is either on or off, and a single key toggles it (for each kind of folding).