From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "J.P." Newsgroups: gmane.emacs.bugs Subject: bug#60730: 29.0.60; Free variable with :buffer keyword in ert-with-temp-file Date: Sun, 29 Jan 2023 06:08:01 -0800 Message-ID: <87lelll9ha.fsf@neverwas.me> References: <87o7r5ji3q.fsf@neverwas.me> <874jsazqzz.fsf@neverwas.me> <83edreaehg.fsf@gnu.org> <87k016y7o9.fsf@neverwas.me> <838rhmab8f.fsf@gnu.org> <874jsaumk7.fsf@neverwas.me> <875ycqt0t8.fsf@neverwas.me> <83k015976p.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35074"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: stefankangas@gmail.com, 60730@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jan 29 15:09:34 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pM8NC-0008wz-0d for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 29 Jan 2023 15:09:34 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pM8Ml-0006Ne-Cn; Sun, 29 Jan 2023 09:09:07 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pM8Mh-0006GS-CO for bug-gnu-emacs@gnu.org; Sun, 29 Jan 2023 09:09:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pM8Mh-0000Y2-1a for bug-gnu-emacs@gnu.org; Sun, 29 Jan 2023 09:09:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pM8Mg-00058N-L5 for bug-gnu-emacs@gnu.org; Sun, 29 Jan 2023 09:09:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 29 Jan 2023 14:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60730 X-GNU-PR-Package: emacs Original-Received: via spool by 60730-submit@debbugs.gnu.org id=B60730.167500129319674 (code B ref 60730); Sun, 29 Jan 2023 14:09:02 +0000 Original-Received: (at 60730) by debbugs.gnu.org; 29 Jan 2023 14:08:13 +0000 Original-Received: from localhost ([127.0.0.1]:42491 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pM8Lt-00057G-78 for submit@debbugs.gnu.org; Sun, 29 Jan 2023 09:08:13 -0500 Original-Received: from mail-108-mta236.mxroute.com ([136.175.108.236]:38259) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pM8Lr-00056y-FS for 60730@debbugs.gnu.org; Sun, 29 Jan 2023 09:08:12 -0500 Original-Received: from mail-111-mta2.mxroute.com ([136.175.111.2] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta236.mxroute.com (ZoneMTA) with ESMTPSA id 185fddb460a000011e.001 for <60730@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Sun, 29 Jan 2023 14:08:04 +0000 X-Zone-Loop: ebbdc384f4aa6290e0fe462f3152ffca4e667fc407f4 X-Originating-IP: [136.175.111.2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me ; s=x; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=cmsiMl8y7WQ7OyrZZ2z+RHzmVB3UN0q4oNXsTRIjFFM=; b=TLP5dA9d7oFLZsSgQ8/xmkgeo/ w+8eeTfNUCQ16Y803VDo87c6rdAqw4iVFUOSx6ma7vAQT+ObMjcuTIj1R16X0zu/d/cINJu3MajCN chrjolWc4U7lMx3llrRkvotmOuJvaPENEuwQ6YwDz7U0dUN88xHyN/Pg5Jcw/uyzhBtIOYUDkJR5l ubzJf89QQykP4PihUZJjrIrvqstCav4+CxSnXA8nhcbhGYenTfrDWz6efNE88dZgjJ1AiSBlDRMRn Bw+yqzDLE15kHTDb/tNPuzTCT9GFU6cu07e/L9h+BIKICGh8mzQgj2If6ldD6djP1lQSoIs8OMVvD 7D5Zb0CQ==; In-Reply-To: <83k015976p.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 29 Jan 2023 08:38:22 +0200") X-Authenticated-Id: masked@neverwas.me X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:254355 Archived-At: Eli Zaretskii writes: >> "J.P." writes: >> >> If, as you say, an argument to `:coding' should only ever be quoted, e.g., >> >> :coding 'raw-text >> >> then `coding' will end up quoted as well, so something like this might >> be enough: > > If you say so. The `', stuff looks strange to me, but the backticks > in Emacs Lisp have always been black magic. > > What we need to ensure that both > > :coding 'raw-text > > and > > :coding some-coding-variable > > do work as expected, including when coding-system-for-write's value is > a non-nil symbol of a coding-system. Right, whatever the solution, it should cover those bases. Although, if `some-coding-variable' evaluates to nil, the change I proposed would not fall back on `coding-system-for-write'. (But perhaps it should? [1]) Also, thinking about this in earnest (for once), I'm unsure why we need to capture the value of `coding-system-for-write' at expansion time. Wouldn't it be preferable to defer evaluation until the test actually runs? IOW, when the `:coding' keyword is absent, shouldn't the final form contain -> (let* ((coding-system-for-write coding-system-for-write) ... or even -> (let* (... (meaning nothing)? If this "deferred" approach makes sense, perhaps something like this will suffice: diff --git a/lisp/emacs-lisp/ert-x.el b/lisp/emacs-lisp/ert-x.el index 98a017c8a8e..2605fc22ddf 100644 --- a/lisp/emacs-lisp/ert-x.el +++ b/lisp/emacs-lisp/ert-x.el @@ -475,7 +475,7 @@ ert-with-temp-file (:directory (setq directory (pop body))) (:text (setq text (pop body))) (:buffer (setq buffer (pop body))) - (:coding (setq coding (pop body))) + (:coding (setq coding (list (pop body)))) (_ (push keyw extra-keywords) (pop body)))) (when extra-keywords (error "Invalid keywords: %s" (mapconcat #'symbol-name extra-keywords " "))) @@ -484,7 +484,7 @@ ert-with-temp-file (suffix (or suffix ert-temp-file-suffix (ert--with-temp-file-generate-suffix (or (macroexp-file-name) buffer-file-name))))) - `(let* ((coding-system-for-write ,(or coding coding-system-for-write)) + `(let* (,@(and coding `((coding-system-for-write ,(car coding)))) (,temp-file (,(if directory 'file-name-as-directory 'identity) (make-temp-file ,prefix ,directory ,suffix ,text))) (,name ,(if directory Note that with this change, `coding-system-for-write' would only be bound when the user supplies a `:coding' argument, even if that argument is nil [2]. Anyway, if this "deferred" stuff is simply wrongheaded, please forget I ever mentioned it. Thanks. [1] If incorporating such "fallback" behavior into the "deferred" approach mentioned above is desirable, we could try something like diff --git a/lisp/emacs-lisp/ert-x.el b/lisp/emacs-lisp/ert-x.el index 98a017c8a8e..3439aacf1ab 100644 --- a/lisp/emacs-lisp/ert-x.el +++ b/lisp/emacs-lisp/ert-x.el @@ -484,7 +484,7 @@ ert-with-temp-file (suffix (or suffix ert-temp-file-suffix (ert--with-temp-file-generate-suffix (or (macroexp-file-name) buffer-file-name))))) - `(let* ((coding-system-for-write ,(or coding coding-system-for-write)) + `(let* ((coding-system-for-write (or ,coding coding-system-for-write)) (,temp-file (,(if directory 'file-name-as-directory 'identity) (make-temp-file ,prefix ,directory ,suffix ,text))) (,name ,(if directory [2] My main concern with the "fallback" route is that the user loses a rather convenient means of ignoring whatever value of `coding-system-for-write' exists in their testing environment. IOW, they cannot easily opt to favor the default selection procedure mentioned in the doc string (for `c-s-f-w'). As a user of this macro, I feel it might be handy to have the option of supplying a literal nil (or a variable evaluating to nil) to signal such intent.