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: Sun, 24 Sep 2017 20:18:06 +0000 Message-ID: <20170924201806.GD5725@ACM> References: <83377mls4d.fsf@gnu.org> <20170919173511.GA19168@ACM> <20170921205447.GA8240@ACM> <20170922180440.GA7229@ACM> <5de6367f-49a0-b991-e084-c673d8443fde@cs.ucla.edu> <20170924143341.GB5725@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1506284744 21074 195.159.176.226 (24 Sep 2017 20:25:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 24 Sep 2017 20:25:44 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: Eli Zaretskii , Richard Stallman , emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 24 22:25:38 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 1dwDT7-0004rp-4g for ged-emacs-devel@m.gmane.org; Sun, 24 Sep 2017 22:25:37 +0200 Original-Received: from localhost ([::1]:39301 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dwDTB-0005Dd-C8 for ged-emacs-devel@m.gmane.org; Sun, 24 Sep 2017 16:25:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57664) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dwDT4-0005DL-OS for emacs-devel@gnu.org; Sun, 24 Sep 2017 16:25:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dwDT1-0000we-JI for emacs-devel@gnu.org; Sun, 24 Sep 2017 16:25:34 -0400 Original-Received: from ocolin.muc.de ([193.149.48.4]:29553 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1dwDT1-0000uD-8K for emacs-devel@gnu.org; Sun, 24 Sep 2017 16:25:31 -0400 Original-Received: (qmail 75629 invoked by uid 3782); 24 Sep 2017 20:25:28 -0000 Original-Received: from acm.muc.de (p548C6746.dip0.t-ipconnect.de [84.140.103.70]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 24 Sep 2017 22:25:28 +0200 Original-Received: (qmail 9669 invoked by uid 1000); 24 Sep 2017 20:18:06 -0000 Content-Disposition: inline In-Reply-To: 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:218758 Archived-At: Hello, Paul. On Sun, Sep 24, 2017 at 11:13:06 -0700, Paul Eggert wrote: > Alan Mackenzie wrote: > > Putting a single output > > operation through two `format'-like operations is bizarre and > > extravagant. It's not something we should encourage. > It's not bizarre; it's routine in Emacs Lisp code. It occurs once in Emacs Lisp code, in cc-engine.el. I doubt it's used more than once, and you are remarkably evasive about this point. > And it's not extravagant: the loss in efficiency for messages is tiny, > and is not something users have noticed or complained about. But it's a loss of efficiency nevertheless, no matter how slight. You've given no reasons to use it, other than "we've already used it once", which is a poor reason. > > By contrast, binding a controlling variable around an operation is the > > standard Emacs way of doing such things. > It's standard for other things, but it's definitely not standard here. The Emacs > source code never does it this way. It soon will, once I amend cc-engine.el. > > How many such instances are there in the code anyway? [ Trim evasive non-answer ] Why won't you anwer this question, Paul? Why do you twist my text by selective quoting? What are you trying to hide? Once again, how many instances of this double format technique exist in the Lisp code? Cite another one which isn't in cc-engine.el. > > This would need fleshing out with something like "To inhibit > > or influence this translation of ASCII quotes, see text-quoting-style". > Sure, that's easy. Revised proposal attached. Thanks, I'll read it. > > The "boilerplate" you want to replace is short and to the point, > It is not short; it's discursive and it gets in the way. In your proposal, it's > about ten lines of boilerplate for each affected function, .... of which I've contributed only around three lines. "Boilerplate" is hardly an accurate term for it, since it only occurs three times, and it's essential information for users of these functions, which would get lost if moved into a separate page. > .... boilerplate that is about as long as the main function > description itself. We should move most of this boilerplate to a > common section, and briefly allude to it in each affected function. > This will give us room to expand on the issue in the common section, > which I've done in my proposal - it has about twenty lines discussing > the issue, and this is shorter and provides more useful info than > repeating ten lines in multiple places. > > A further general point about this bit of doc is its rather strange use > > of the verb "generate". > Also easy; the revised proposal (attached) uses "translates to" instead of > "generates". Thanks. [ .... ] -- Alan Mackenzie (Nuremberg, Germany).