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: Mon, 7 Sep 2015 10:07:10 -0700 (PDT) Message-ID: <573d297e-730f-46b6-9290-624b9497c501@default> References: <2a7b9134-af2a-462d-af6c-d02bad60bbe8@default> <834mjecdy7.fsf@gnu.org> <834mjcbydi.fsf@gnu.org> <83vbbs9qd1.fsf@gnu.org> <66ae6614-75bf-4b1b-9c16-5e7755a824f8@default> <87k2s25oaz.fsf@esperi.org.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1441645686 17183 80.91.229.3 (7 Sep 2015 17:08:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 7 Sep 2015 17:08:06 +0000 (UTC) Cc: Jean-Christophe Helary , bruce.connor.am@gmail.com, emacs-devel To: Nix Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 07 19:07:53 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 1ZYztY-0000GQ-Ea for ged-emacs-devel@m.gmane.org; Mon, 07 Sep 2015 19:07:52 +0200 Original-Received: from localhost ([::1]:57916 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZYztY-00085d-CR for ged-emacs-devel@m.gmane.org; Mon, 07 Sep 2015 13:07:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39337) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZYztI-00085Y-L2 for emacs-devel@gnu.org; Mon, 07 Sep 2015 13:07:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZYztD-0006Ix-Fj for emacs-devel@gnu.org; Mon, 07 Sep 2015 13:07:36 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:40854) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZYztD-0006Ip-9I for emacs-devel@gnu.org; Mon, 07 Sep 2015 13:07:31 -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 t87H7KoE002647 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Sep 2015 17:07:21 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 t87H7JUs000771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 7 Sep 2015 17:07:20 GMT Original-Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t87H7JRR030778; Mon, 7 Sep 2015 17:07:19 GMT In-Reply-To: <87k2s25oaz.fsf@esperi.org.uk> 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:189671 Archived-At: > FWIW I just introduced Emacs to a newbie last month -- using trunk Emacs > because that's what I happened to have available. She was very happy > indeed about not only isearch, not only case-fold search but > specifically char-fold search, and she writes stuff using diacritics all > the time. >=20 > The key to remember here is that there are many use cases in which it is > better if isearch finds something similar to what you typed than if it > misses something you were looking for: you can always hit C-s again! > So thanks to case-fold and char-fold search she doesn't have to worry > about getting either the case or diacritics right, and can cut down on > chording and compose characters while searching. >=20 > So that's one newbie in particular who would vociferously disagree > with you. >=20 > > What should be done is to have simple, obvious default behavior, ^^^^^^^ > She found "searching ignores accent-like things and case" to be easy > and instantly understandable, even though the implementation of > ignoring even case is (thanks to case-conversion tables) quite > complicated in a Unicode world. Anecdotal evidence from one newbie. OK. I don't see anything in your description of her understanding of Isearch that shows that she "would vociferously disagree" with my proposition that literal search is a better default behavior, but I guess that is how you feel. So be it. Nevertheless, I wonder a bit about her nonsurprise and instant understanding wrt char folding. Did she just search for something like `a' and find things like `=E1'? Or did she also search for something like `=E1' and find things like `a'? (She could not have, as that is not yet implemented, AFAIK.) I would be somewhat surprised if she would not be somewhat surprised that looking for `=E1' can find `a'. Note the current discussion and the Subject line. This thread is about making char folding treat `=E1' and `a' as equivalent, i.e., both directions. I think it should be clear that searching for and finding exactly what you type is _absolutely_ easier to understand than finding things that you did not type. Of course, both literal and dwim searching might be easy enough in some contexts or for some users. So sure, this absolute difference in ease of understanding does not preclude the existence of some users for whom even the most complex mapping of search string to search hits might be "easy and instantly understandable". Such users should not be bothered by whichever behavior is chosen as default. Regexp vs literal search is a good example of literal search being easier to "get". Regexp search requires some extra understanding of, or feeling for, the mapping between search patterns and what the patterns match; literal search does not: what you type is what you find, literally. I doubt that all newbies expect our whitespace folding or find it natural. Likewise, how non-nil `case-fold-search' treats the presence of an uppercase letter in the search string. These things are not obvious, in general, even if you can point to a new user for whom they seem to be obvious. The uppercase-letter-in-search-string behavior, in particular, is unusual - not common in text editors. That might have made sense as default behavior for Emacs in 1985, but now? These things are gotchas, even if there might be some newbies who do not seem to have ever been "got" by them. It is better not to make such behavior the default, as long as the alternative is useful. And it is easy enough to customize search to make such dwim searching the default for any particular user. And it is trivial to toggle the behavior anytime. There is no special reason to make the default behavior a "gotcha" one. The _only argument_ that I have heard, for making folding searches the default behavior, and the only one that I can imagine, is that if we do not do so then users might not discover them quickly, and so they might miss out on how useful they can be. I repeat what I said before about that: Discoverability is not an argument for choosing any default behavior. Poor discoverability is an argument for improving discoverability. Nothing more. > The key to remember here is that there are many use cases in > which it is better if isearch finds something similar to what > you typed than if it misses something you were looking for No, that is not anything key to remember, in this discussion. No one has doubted that non-literal search can be extremely useful. That is in fact one of the reasons for this thread: make char-fold search do exactly that for any char in the search string, including for a char with diacritics. Currently, it always searches only literally for `=E1', even when char folding is turned on. It should be clear that no one is arguing against the usefulness of folding search. The post you responded to was a counter to the false argument that we should turn char folding on by default because it facilitates discovery of this nifty feature. This thread is not really about what the default behavior should be, but I did address that extraneous argument, and you did respond. If there is a need to continue about that topic, we should do it in a separate thread.