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: lax matching is not a great default behavior Date: Fri, 27 Nov 2015 21:04:54 -0800 (PST) Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1448687116 11074 80.91.229.3 (28 Nov 2015 05:05:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 28 Nov 2015 05:05:16 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 28 06:05:01 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 1a2Xgz-0003CP-7a for ged-emacs-devel@m.gmane.org; Sat, 28 Nov 2015 06:05:01 +0100 Original-Received: from localhost ([::1]:59556 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2Xh2-0006Fz-4x for ged-emacs-devel@m.gmane.org; Sat, 28 Nov 2015 00:05:04 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59478) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2Xgy-0006Fa-8V for emacs-devel@gnu.org; Sat, 28 Nov 2015 00:05:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a2Xgv-0005r7-1z for emacs-devel@gnu.org; Sat, 28 Nov 2015 00:05:00 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:40726) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2Xgu-0005r3-Rx for emacs-devel@gnu.org; Sat, 28 Nov 2015 00:04:56 -0500 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tAS54sMN009941 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 28 Nov 2015 05:04:55 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tAS54sWU022582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 28 Nov 2015 05:04:54 GMT Original-Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tAS54s1K022236 for ; Sat, 28 Nov 2015 05:04:54 GMT X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 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:195428 Archived-At: This has been discussed somewhat, but I don't think there was any actual proposal to change the behavior. So here goes. Does it still make sense to make search and replacement use lax matching, i.e., fold stuff, by default? I don't think it does. I think that users, especially new users, would be less confused if Emacs defaulted to literal searching - no whitespace, case, "character", or other folding by default. Folding features and their combinations and customizations will only increase in the future (at least I hope so - that's a good thing). The starting point that is the least ambiguous, least surprising, and least difficult for a user to discover and understand is zero folding: literal search. I realize that this would change the longstanding practice of having letter-case folding be default. I think that choice made sense back when most programming languages and OS's did not have a letter-case difference. But I don't think it is the best choice for the default behavior now. Same for whitespace folding, though that is not longstanding. Even more so for "character" folding, i.e., ignoring diacriticals and differences among quote marks etc. (and some other ad hoc equivalences). Such classes might be clear to those who are familiar with them, and this folding feature can certainly be useful. But I don't think it is the right choice for the default behavior. Literal search is dead simple, plain, obvious, boring, clear. Anyone who wants to go further, and fold whitespace, for instance, can easily ask Emacs how to do that and find out that there is a simple toggle key for it. Starting with whitespace folding turned on, on the other hand, can be confusing, particularly for programmers, who often care about which whitespace chars, and how many, they are searching for. Similarly for case fold. Let's start with WYTIWYSF: what you type is what you search for. Anyone who wants to abstract from letter case can easily ask Emacs how to do that and find out that a simple toggle key suffices. (Yes, there is also the "clever" complication of automatic case-fold-search change when an upper-case char is present. I don't propose any change in that regard now, but I do think that its time is also soon up. Not so useful as a default behavior, IMO. And I don't think it was a great idea to copy the same cleverness for "character" folding. But this is a different story.) It's likely I won't have more to say about this. I think the pros & cons are pretty straightforward. It's more a question of choosing than arguing reasons at this point, I expect.