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:23:05 -0700 (PDT) Message-ID: <4f3b1db3-d3d2-480f-8662-fbf7c74aa67f@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 1441855435 29168 80.91.229.3 (10 Sep 2015 03:23:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Sep 2015 03:23:55 +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 Thu Sep 10 05:23:40 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 1ZZsSY-0004Z5-CP for ged-emacs-devel@m.gmane.org; Thu, 10 Sep 2015 05:23:38 +0200 Original-Received: from localhost ([::1]:46638 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZsSX-0003nN-Rl for ged-emacs-devel@m.gmane.org; Wed, 09 Sep 2015 23:23:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50078) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZsSD-0003ht-4a for emacs-devel@gnu.org; Wed, 09 Sep 2015 23:23:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZsS9-0005wy-4I for emacs-devel@gnu.org; Wed, 09 Sep 2015 23:23:17 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:23249) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZsS8-0005wT-TJ; Wed, 09 Sep 2015 23:23:13 -0400 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t8A3N67k019687 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Sep 2015 03:23:07 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t8A3N6Uq003202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 10 Sep 2015 03:23:06 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 t8A3N6u5014511; Thu, 10 Sep 2015 03:23:06 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: userv0022.oracle.com [156.151.31.74] 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:189786 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 > I mean, that the user can do all of these with one character, not > using any toggle command. Yes, that is the difference in our views. Sure, "with one character", but the flip side is that if you happen to have =C3=A9 in your search strin= g, however it got there (e.g. by pasting), then with your preferred behavior you *cannot* use your search string to search for "any kind of e". This is maybe clearer when you think about copying some text to search for from outside Emacs, and that text might have curly quotes in it, in multiple places, and the text that you want to search might use other kinds of quotes, and you want the matching to match quotes regardless of type. In that use case, you are screwed in the current design. Nothing to be done, to get char-fold search, until you replace all such non-base chars in the search string with their corresponding base chars. (And you talk about difficulty remembering? Try remembering the base char of each equivalence class... Sure, letters and numerals are easy, but not some others. And we're just getting started.) > > 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. >=20 > No, another difference would be that NONE of the other options > is possible with one character -- all would require a toggle command > that people may not remember. (I don't.) NONE of what other options? All of the same search behaviors are available. That is, you can find any search target that you can find today, using any search string that you use today. On the difficulty of toggling char folding: Do you remember how to toggle case sensitivity? How come you do? Because you've done it a few times? And if you forget, you use `C-s C-h'? Or you use `C-h f isearch-forward'? How hard is that? Anyway, it's not likely I'll convince you to enjoy the feature yourself. But maybe you can appreciate giving users the choice? > > 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. >=20 > The user would continue to be able to do this _somehow_, but not as > now without using a separate toggle command. Correct. But at least that use case would still be available. Currently, the use case that the proposal provides for is not even possible - not never not noway not nohow. That's really the point: provide that possibility.