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 09:58:57 -0700 (PDT) Message-ID: <42be0ab7-f1e0-4fac-8b80-0e1686e88445@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> <87mvwx0wdq.fsf@uwakimon.sk.tsukuba.ac.jp> 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 1441731603 21553 80.91.229.3 (8 Sep 2015 17:00:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Sep 2015 17:00:03 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 08 18:59: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 1ZZMFG-0004Wg-Kd for ged-emacs-devel@m.gmane.org; Tue, 08 Sep 2015 18:59:46 +0200 Original-Received: from localhost ([::1]:35851 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZMFG-00051c-9Y for ged-emacs-devel@m.gmane.org; Tue, 08 Sep 2015 12:59:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51574) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZMEd-0004wb-4K for emacs-devel@gnu.org; Tue, 08 Sep 2015 12:59:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZMEX-0003C6-HT for emacs-devel@gnu.org; Tue, 08 Sep 2015 12:59:07 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:45704) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZMEX-0003Bt-BR for emacs-devel@gnu.org; Tue, 08 Sep 2015 12:59:01 -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 t88GwxUc032475 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Sep 2015 16:59:00 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 t88GwxiN014616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Sep 2015 16:58:59 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 t88Gwwcm017384; Tue, 8 Sep 2015 16:58:59 GMT In-Reply-To: <87mvwx0wdq.fsf@uwakimon.sk.tsukuba.ac.jp> 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:189721 Archived-At: > > This should be a no-brainer, IMO. >=20 > Put your code on ELPA and demonstrate its superiority. > Since it's a no-brainer, there's no risk. If you're going to quote something written by someone else, please at least do not mislead by taking it totally out of context. Here is that text in context. It says nothing about implementation being a no-brainer. > Being _able_ to fold `=C3=A9' to `e' or `=C3=A8', and to fold one > kind of quote mark to others, is, yes, a normal use case. > Nothing odd, abstract, or academic about it. Herr M=C3=BCller > confirms this with his own example. This should be a > no-brainer, IMO. It's about _what_ users can do. It should be a no-brainer, IMO, that users should _be able_ to do what Ulrich, Juri, and I have requested. That same emphasis on _being able_ was in the original text quoted, but you still ignored it. _How_ to fix the current implementation to support that behavior is a different question. Feel free to raise that question - _how_ to do it - in another thread, if you are=20 interested. And contribute code to it, if you like.=20 The question this thread raises is why and why not do it. I've approached this question only from a user point of view (it is useful to be able to do it). But it is fine to present implementation-related considerations that argue against (or for) doing it. None seen so far.