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: Fri, 29 Sep 2017 21:06:46 -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>> <<83shf597b0.fsf@gnu.org>> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1506744443 26091 195.159.176.226 (30 Sep 2017 04:07:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 30 Sep 2017 04:07:23 +0000 (UTC) Cc: acm@muc.de, eggert@cs.ucla.edu, rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii , Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 30 06:07:19 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 1dy93c-0005pM-NQ for ged-emacs-devel@m.gmane.org; Sat, 30 Sep 2017 06:07:16 +0200 Original-Received: from localhost ([::1]:38045 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dy93e-00072v-Bl for ged-emacs-devel@m.gmane.org; Sat, 30 Sep 2017 00:07:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36746) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dy93V-00072e-PZ for emacs-devel@gnu.org; Sat, 30 Sep 2017 00:07:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dy93U-0001e5-Sb for emacs-devel@gnu.org; Sat, 30 Sep 2017 00:07:09 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:24167) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dy93P-0001ZZ-6Q; Sat, 30 Sep 2017 00:07:03 -0400 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 v8U46qev014148 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 30 Sep 2017 04:06:53 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v8U46po1006869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 30 Sep 2017 04:06:52 GMT Original-Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v8U46lgp031989; Sat, 30 Sep 2017 04:06:47 GMT In-Reply-To: <<83shf597b0.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4588.0 (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: 156.151.31.81 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:218956 Archived-At: > > > The form I favour is: > > > (let ((text-quoting-style 'grave)) (1) > > > (message "'%s" form)) > > > > > > What Paul favours is something like > > > (message "%s" (format "'%s" form)) (2) > > > > Another difference between the two (of course): With #1 > > you can easily control the scope of the effect. > > > > For example, you can use a single such `let' for multiple > > such messages. And you can of course do this at any depth. > > And you can override that locally at some depth using another > > `let', binding a different value to `text-quoting-style'. >=20 > The above use case is a marginal one: there's rarely a reason to > display symbols like 'foo in echo-area messages, let alone in a series > of such messages. I agree. It was Paul's (or Alan's?) example, not mine. > So let's not let marginal use cases drive this discussion, > which is complex enough already. Marginal use cases are not driving what I've said in this discussion - at all. That's why I emphasized the greater flexibility of using `let' - easy to use for both marginal and more significant use cases. > FWIW, Paul's proposal sounds better to me, for the purposes > of documenting the "fire escape". Wunderbar - but you don't say _why_ it is better for that documentation purpose. But I'm guessing its because you look at this little bit of doc as essentially a footnote - hiding `text-quoting-style' in plain sight. Now you see it; now you don't. Calling reverting curly-quoting just a "fire escape" suggests a desire not to have to offer `text-quoting-style' at all - thinking of it reluctantly as a perhaps necessary eyesore and bother, fit only for the back alley. That's not the way I look at `text-quoting-style' or its doc. I don't see user control over pandemic curly-quotitis as being just a fire escape - something to use only in case of emergency. The first question to decide is whether `text-quoting-style' should be a user option. I say yes (as does Paul himself, apparently). When the whole city is on fire little is more important that finding a formerly inconspicuous fire escape or fire hydrant - a welcome eyesore, if ever there was one.