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 08:21:01 -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 1441812121 16744 80.91.229.3 (9 Sep 2015 15:22:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Sep 2015 15:22:01 +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 Wed Sep 09 17:21:48 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 1ZZhBm-0007O2-CC for ged-emacs-devel@m.gmane.org; Wed, 09 Sep 2015 17:21:34 +0200 Original-Received: from localhost ([::1]:43450 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZhBh-0002kt-Dq for ged-emacs-devel@m.gmane.org; Wed, 09 Sep 2015 11:21:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40483) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZhBT-0002kN-0x for emacs-devel@gnu.org; Wed, 09 Sep 2015 11:21:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZhBO-0008RG-Bm for emacs-devel@gnu.org; Wed, 09 Sep 2015 11:21:14 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:43555) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZhBO-0008RB-4T; Wed, 09 Sep 2015 11:21:10 -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 t89FL3BX021672 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Sep 2015 15:21:04 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t89FL3ut020092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 Sep 2015 15:21:03 GMT Original-Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t89FL3vP007505; Wed, 9 Sep 2015 15:21:03 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:189766 Archived-At: > > > Currently the user can either search for "any kind of e" or "only = =C3=A9" > > > or "only =C3=A8" or "only =C3=AA", etc. >=20 > > 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]. >=20 > This seems to be a miscommunication. That communication is itself unclear. _What_ seems to you to be a=20 miscommunication? The point is that what you say is true currently would still be the case with what is proposed in this thread. The user would continue to be able to search for either any kind of e or for only a specific kind of e.