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: lax matching is not a great default behavior Date: Fri, 4 Dec 2015 07:55:34 -0800 (PST) Message-ID: <45e1580a-863c-4bd7-82ec-38c27a0d930e@default> References: <837fl2qzs2.fsf@gnu.org> <83610ikvto.fsf@gnu.org> <83bna6ipn7.fsf@gnu.org> 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 1449244568 27919 80.91.229.3 (4 Dec 2015 15:56:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Dec 2015 15:56:08 +0000 (UTC) Cc: jwiegley@gmail.com, rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii , =?utf-8?B?UGVyIFN0YXJiw6Rjaw==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 04 16:55:55 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 1a4si8-000664-90 for ged-emacs-devel@m.gmane.org; Fri, 04 Dec 2015 16:55:52 +0100 Original-Received: from localhost ([::1]:41724 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4si7-0004Ti-NZ for ged-emacs-devel@m.gmane.org; Fri, 04 Dec 2015 10:55:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46828) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4si2-0004TZ-6Z for emacs-devel@gnu.org; Fri, 04 Dec 2015 10:55:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a4si0-0004iD-PU for emacs-devel@gnu.org; Fri, 04 Dec 2015 10:55:46 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:20757) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4shv-0004h7-Sb; Fri, 04 Dec 2015 10:55:40 -0500 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tB4FtaO3007218 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Dec 2015 15:55:37 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 tB4FtZgx028076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 4 Dec 2015 15:55:35 GMT Original-Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tB4FtZto019198; Fri, 4 Dec 2015 15:55:35 GMT In-Reply-To: <83bna6ipn7.fsf@gnu.org> 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: 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:195891 Archived-At: > > > If we are afraid users will hate this default, we can turn it > > > off in v25.1 and consider making it the default later. > > > > That would be good You snipped the rest of Per's point there, which makes a difference, I think: > > , together with introducing an entry for it in the Options > > menu directly below (or above?) "Ignore case for search". > > This deserves to be as visible as that option. > I see no real reasons yet for such a decision. ... To revert > that [other] decision will take more than just "I think it's > wrong" kind of posts. So, no real reasons have appeared yet for a decision in favor of the (longstanding) default behavior that you don't agree with. But a decision has already been made in favor of the default you do agree with? And now you're entertaining arguments to "revert that decision"? _Has_ such a decision to change the default behavior in fact already been made? > Character folding was introduced with the explicit goal of giving > users what the other text-editing and word-processing environments > provide, what they therefore are expected to expect. So what? So was CUA mode and lots of other features that are not turned on by default. Being introduced for such a reason is not by itself a sufficient reason, let alone a "decision", that it should immediately become the new default behavior. > In any case, introducing massive changes that are turned on by default > is nothing new in Emacs development. Bidirectional display engine > introduced in Emacs 24.1 comes to mind; it certainly was much more > massive than this one. And turning that one off was nowhere as simple > as turning character folding off, so the risk was much higher. We did > it anyway, because we thought that was TRT to do, and because we > wanted any bugs and adverse side effects of that change found and > fixed before the release. Likewise here. Bidi did not noticeably affect users who do not edit bidi text. Had it done so, it is not so clear that it would have been turned on by default. I think that a much better comparison is CUA mode. You argue that we should turn char folding on by default _because_ that's what users of other editors are used to. Most users of other editors are used to CUA-like behavior too. Yet we don't turn that on by default (and I agree with that decision). Turning char folding on by default might well be the best thing to do at some point, but I see no reason to rush to that. > > Should it be "Ignore accents for search"? >=20 > No, because ignoring accents is just a small part of character > folding. Please take a look at character-fold.el for the details. Agreed. And neither is it folding of diacriticals, because there are also ad hoc foldings (e.g., quote marks). And there will likely be more to come. It is, in fact, a hodge podge of foldings - pretty much all of the various char foldings provided by Emacs so far, except for letter case. In such a situation, only a vague term such as "character folding" or "miscellaneous character folding" can characterize it. Until we perhaps divide it into different folding groups, which each can have a specific name that says something, we can only, I think, give it such a catch-all name. That's OK, IMO. > > > Alternatively, we > > > could quickly release Emacs 25.2 with character folding turned off if > > > we see an outcry. But polling at this time will not be efficient, > > > IMO. > > > > Not at all as good! To "quickly release" something doesn't mean that > > it is a quick change for users, who may keep using that version for a > > long time. >=20 > If they are annoyed by a feature, they will upgrade quickly, I think. What's the crying need to do it this way? Why not leave it off by default, for now? Make it available, advertise it, put it in the Options menu, give it a toggle key, and see how users like it. It's not hard to _later_ make it the default behavior. What's the rush? > Most posts I've seen explained why their authors don't like this > feature. Well I, for one, very much like this feature. But I don't think we should precipitously turn it on by default. > turning it off today means that it will get much less testing, > and therefore bugs related to it...will most probably remain > hidden for who knows how long. I seriously doubt that. That sounds alarmist, to me. It is trivial to toggle it on, and I am _sure_, given its usefulness, that it will get sufficiently used ("tested") after the release that we can get a good idea of whether, later, we want to turn it on by default. My expectation, if we turn it off by default, is that users will try it, like it, and possibly ask for it to become the default behavior. There is no reason to jump the gun on this.