From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Emacs 26.1 release branch created Date: Mon, 25 Sep 2017 19:52:22 -0700 (PDT) Message-ID: References: <20170922193511.GC7229@ACM> <20170922220700.GD7229@ACM> <20170924143939.GC5725@ACM> <20170924194139.GA6793@ACM> <20170925190357.GA4651@ACM> <855b1231-2279-4fd7-a2d6-be65435bb8be@default> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1506394362 6331 195.159.176.226 (26 Sep 2017 02:52:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 26 Sep 2017 02:52:42 +0000 (UTC) To: Paul Eggert , Alan Mackenzie , emacs-devel@gnu.org, Eli Zaretskii , rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 26 04:52:35 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 1dwfz8-00017h-W7 for ged-emacs-devel@m.gmane.org; Tue, 26 Sep 2017 04:52:35 +0200 Original-Received: from localhost ([::1]:45304 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dwfzG-0002w5-5j for ged-emacs-devel@m.gmane.org; Mon, 25 Sep 2017 22:52:42 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53935) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dwfz9-0002w0-G0 for emacs-devel@gnu.org; Mon, 25 Sep 2017 22:52:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dwfz8-0004rI-Ck for emacs-devel@gnu.org; Mon, 25 Sep 2017 22:52:35 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:25263) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dwfz3-0004p4-Ct; Mon, 25 Sep 2017 22:52:29 -0400 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 v8Q2qPaf027032 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 26 Sep 2017 02:52:25 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v8Q2qOui022547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 26 Sep 2017 02:52:25 GMT Original-Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v8Q2qNYJ005532; Tue, 26 Sep 2017 02:52:23 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6776.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] [fuzzy] X-Received-From: 141.146.126.69 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:218795 Archived-At: > (let ((text-quoting-style 'grave)) > =C2=A0(message "(setq coding-system '%S)" > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0(find-operation-coding= -system 'write-region "x"))) >=20 > is incorrect, because it changes the quoting style not just for the > message, but also for the internals of find-operation-coding-system, > internals that are unrelated to the message and which will behave > contrary to user preference. So don't do that. Just because you _can_ try to evaluate `(cons 42)', that doesn't mean it is usually a great idea to do so. > The let-binding approach is appropriate only for simple cases > where you know all the code that will be executed inside the 'let', On the contrary (see RMS URL below). It is especially useful where you do NOT know all of the code that will be executed within the dynamic extent of the `let' - BUT where you are sure that you want all of that code to respect such a binding. That's the point. The point of control is at the `(let...)': it's there that you express your intent wrt `text-quoting-style'. If you don't know the extent over which you want a setting of that variable to last in some context then perhaps you shouldn't be using it. Or dig in and find an appropriate place for it. It's about what you want: where and when you want the setting to hold. The point is that you _can_ use it to control a given extent of processing - even processing that you don't know in detail or whose code you cannot change. That's the power of using `let' here: control the extent of a given quote-behavior setting. > and know that you want to override user preference Gee, I thought you didn't look at `text-quoting-style' as expressing a user preference, and so didn't want it to be a user option. Now it's a user preference all of a sudden? Hoorah. > for all of the code. It is inflexible and error-prone > compared to the easier-to-use '(message "%s" ...)' Binding the variable is _more_ flexible, not less. Whether it is also more error prone as a result of that I won't argue. It's true that to use `let' you need to know what `let' does and pay attention to that. Use it wrong and errors can result. > style that Emacs has used for decades. Uh, let-binding dynamic variables is as old as the hills. It's older than Emacs (and that's saying something). > This is not a close call: we should document what has > worked rather than try to promote an experimental > alternative that has no significant technical advantages. Ah, so you too prefer tried-and-true `let'? ;-) The `let' approach is more flexible and more powerful. It gives you more control over the scope (extent, really). Do it where/when it makes sense to do it. At least you have a choice, and it is _easy_ to choose the extent of its coverage. Your ability to create straw-man examples of _bad_ uses of `let' - inappropriate extent - shows nothing, except that you are able to create bad uses of `let'. The difference is not at all about "simple" vs "complex" cases. (I disagree with you and John about this.) `let' is appropriate for _both_ simple and complex cases - it is simply more flexible. Do with it what you will. And yes, as it is more flexible you can certainly shoot yourself in the foot with it. This is Lisp. https://www.gnu.org/software/emacs/emacs-paper.html#SEC15