From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Emacs 26.1 release branch created Date: Fri, 22 Sep 2017 18:41:59 +0000 Message-ID: <20170922184159.GB7229@ACM> References: <83377mls4d.fsf@gnu.org> <20170919173511.GA19168@ACM> <20170921205447.GA8240@ACM> <83tvzvcidg.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1506106156 26725 195.159.176.226 (22 Sep 2017 18:49:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 22 Sep 2017 18:49:16 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 22 20:49:12 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dvT0f-0006dP-EE for ged-emacs-devel@m.gmane.org; Fri, 22 Sep 2017 20:49:09 +0200 Original-Received: from localhost ([::1]:60613 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dvT0m-0002jB-Nk for ged-emacs-devel@m.gmane.org; Fri, 22 Sep 2017 14:49:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35989) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dvT0f-0002iq-VM for emacs-devel@gnu.org; Fri, 22 Sep 2017 14:49:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dvT0b-00021G-Br for emacs-devel@gnu.org; Fri, 22 Sep 2017 14:49:10 -0400 Original-Received: from ocolin.muc.de ([193.149.48.4]:41481 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1dvT0b-00020q-55 for emacs-devel@gnu.org; Fri, 22 Sep 2017 14:49:05 -0400 Original-Received: (qmail 21843 invoked by uid 3782); 22 Sep 2017 18:49:03 -0000 Original-Received: from acm.muc.de (p548C6950.dip0.t-ipconnect.de [84.140.105.80]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 22 Sep 2017 20:49:02 +0200 Original-Received: (qmail 7512 invoked by uid 1000); 22 Sep 2017 18:41:59 -0000 Content-Disposition: inline In-Reply-To: <83tvzvcidg.fsf@gnu.org> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.4 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:218696 Archived-At: Hello, Eli and John. I'm putting your two posts together to answer them together. On Fri, Sep 22, 2017 at 10:17:15 +0300, Eli Zaretskii wrote: > > Date: Thu, 21 Sep 2017 20:54:47 +0000 > > From: Alan Mackenzie > > Cc: Richard Stallman > > I have pushed a first draught into the new branch > > scratch/customize-quotes. Comments would be welcome. > > One thing which I hope isn't too controversial, is that I have redefined > > the value of nil in text-quoting-style to mean "no translation of > > quotes" and introduced t to mean "prefer curved quotes", the meaning nil > > previously had. The default value for text-quoting-style remains > > "prefer curved quotes". > This _is_ controversial, since it means we are introducing a backward > incompatible change. > > My reasoning here was that having nil meaning "do nothing" is > > intrinsically the Right Thing. Also very few people, if any, will > > already have explicitly set the variable to nil. And in any case, the > > use of the variable was restricted to experts, all of whom will be able > > to adapt to the new nil and t without difficulty. > IMO, this reasoning is too weak to justify the incompatible change. On Thu, Sep 21, 2017 at 22:58:40 -0700, John Wiegley wrote: > >>>>> "PE" == Paul Eggert writes: > PE> Let's not change the semantics of text-quoting-style's values. Such a > PE> change is not worth the compatibility hassle to users. John asked you to > PE> propose a patch to make text-quoting-style customizable, not to change its > PE> semantics. Whether text-quoting-style is customizable is orthogonal to > PE> what its values mean, and we shouldn't conflate the two issues. > Just to confirm, Paul's assessment is correct: at this late stage, I only want > to add customizability, no other changes. I'm surprised and dismayed by both your reactions to my proposed patch. I thought the issues through carefully before investing time and energy in it. You talk about backward incompatibility. Well, backward incomptibility is only bad when it inconveniences users, which is most of the time. It isn't the case here. Neither of you, nor Paul has suggested a scenario in which a user might suffer. I put it to you that there aren't any, particularly considering how text-quoting-style was kept away from ordinary users in Emacs 25. The current set of symbols used for text-quoting-style is bad. Nobody in recent posts, if ever, has defended them as being good. Its worth bearing in mind that they found their way into the Emacs master without any sort of review beforehand. How are we going to defend the use of the symbol `grave' having the meaning "don't do any translation" five or ten years from now? What makes it worse is its suggestion of "grave danger" alongside "grave accent". I'm concerned for the quality of Emacs, and the use of nil in text-quoting-style sticks out like a sore thumb. The only possible time to fix this problem is now - after text-quoting-style is released for ordinary users in Emacs-26, it will be too late. So, I'm asking you once more to consider very carefully the issues behind my proposed amendment. For my part, I undertake to accept your decision on the matter without further argument, and to change the code in scratch/customize-quotes to the simple change you were expecting, should you say no again. Thanks. -- Alan Mackenzie (Nuremberg, Germany).