From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#67321: 29.1.90; Different parsing rules for -*- lexical-binding:t; -*- in different circumstances Date: Tue, 21 Nov 2023 14:43:12 +0200 Message-ID: <834jhfi8f3.fsf@gnu.org> References: <8734wzts37.fsf@whxvd.name> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16232"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 67321@debbugs.gnu.org To: Sebastian Miele Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 21 13:44:31 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 1r5Q7D-0003yI-48 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 21 Nov 2023 13:44:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r5Q6k-0003x5-34; Tue, 21 Nov 2023 07:44:02 -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 1r5Q6h-0003pD-VH for bug-gnu-emacs@gnu.org; Tue, 21 Nov 2023 07:44:00 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r5Q6h-0001Iz-Nc for bug-gnu-emacs@gnu.org; Tue, 21 Nov 2023 07:43:59 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r5Q6k-00045I-2L for bug-gnu-emacs@gnu.org; Tue, 21 Nov 2023 07:44:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 21 Nov 2023 12:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67321 X-GNU-PR-Package: emacs Original-Received: via spool by 67321-submit@debbugs.gnu.org id=B67321.170057061815648 (code B ref 67321); Tue, 21 Nov 2023 12:44:02 +0000 Original-Received: (at 67321) by debbugs.gnu.org; 21 Nov 2023 12:43:38 +0000 Original-Received: from localhost ([127.0.0.1]:55371 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r5Q6L-00044J-KZ for submit@debbugs.gnu.org; Tue, 21 Nov 2023 07:43:38 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55904) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r5Q6J-000441-Dt; Tue, 21 Nov 2023 07:43:36 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r5Q6A-0001Bo-CP; Tue, 21 Nov 2023 07:43:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=iJbkO3zBoC9kakwA+KNIexXN+/dDfk3pLmbhGs0Yids=; b=njRuhojRI9alzX69/HeB kynePl/qX8Z32s9H2j41el5dpaS09BfwplNJN/7OMLMVb6AYyK0cde8AMPuAkVIsMG2ru/GRowRYT 32g3MeDowOxJVXxkR05m0W+eiqfqEPPM3vJ50n1UFJI/SAVwwKm4N+zAnFVIzEWJPMp1Y1g9uD3gk /Z19JTfjXmzsi645GOgKr598rhJt5DVHJWrlxju9QyT0xD0odbOeuUrj4+3rHLDJmqwx9GYU21uji RrcPD7F2peaDPlJ5TpubU9YMF79VhEjK0ikSLtlMR3FuyMK56vE1WHPU1xs5mwCsMCfli69rPZ3K/ 10NmKTtfQgf9iQ==; In-Reply-To: <8734wzts37.fsf@whxvd.name> (message from Sebastian Miele on Tue, 21 Nov 2023 09:16:13 +0100) 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:274717 Archived-At: merge 67321 64272 thanks > From: Sebastian Miele > Date: Tue, 21 Nov 2023 09:16:13 +0100 > > Put the following into a file named, e.g., ‘test-script’, and ‘chmod +x’ > it. > > #!/bin/sh > : ; exec emacs --script "$0" -- "$@" #; -*- lexical-binding: t; mode: emacs-lisp; -*- > > (defmacro lexical-binding-p () > '(let* ((x t) > (f (lambda () x)) > (x nil)) > (funcall f))) > > (message "%s %s" lexical-binding (lexical-binding-p)) > > When the script is run, the output is "nil nil", signifying that lexical > binding is not enabled. > > Then find the file in an interactive Emacs session, and interactively > evaluate (C-x C-e) the two expressions. The output now is "t t", i.e., > lexical binding is in use. > > https://lists.gnu.org/archive/html/emacs-devel/2023-11/msg01041.html > contains more details, which are repeated here: > > > From: Jens Schmidt > > Date: Mon, 2023-11-20 21:10 +0100 > > > > I tried byte-compiling something similar yesterday, which also > > indicated that the byte-compiler compiles with lexical bindings. Only > > the scripting machinery sees dynamical bindings. > > > > […] It seems that the scripting machinery expects a semicolon in the > > very first column, without that the lexical-binding line is not > > recognized. Even a space before the semicolon breaks the recognition. > > > > The problem is in function `lisp_file_lexically_bound_p' from lread.c, > > which is indeed much more strict in its recognition of the -*- ... -*- > > stanza than the functions `set-auto-mode-1' and > > `hack-local-variables-prop-line' from files.el. The Emacs manual > > ((emacs) Specifying File Variables) only mentions that the stanza has > > to be in the first line (or the second one if the first is taken by a > > she-bang), without any restriction where the comment has to start. > > ((emacs) Specifying File Variables) states no restrictions on what must > (not) precede or follow a "-*- … -*-" on the first or second line of a > file. > > Expected: At least consistent behavior. Ideally, lexical binding > should be enabled in all cases. There's more here than meets the eye, see bug#64272.