From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: LdBeth Newsgroups: gmane.emacs.bugs Subject: bug#64272: 28.1; lisp_file_lexically_bound_p behavior mismatches file local variables Date: Sun, 25 Jun 2023 18:16:36 -0500 Message-ID: References: <83zg4oy9ow.fsf@gnu.org> <83wmzsxedw.fsf@gnu.org> <83mt0ny47z.fsf@gnu.org> <83h6qvxv8q.fsf@gnu.org> Mime-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="838"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?Q?Goj=C5=8D?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.1 (x86_64-apple-darwin21.4.0) MULE/6.0 (HANACHIRUSATO) Cc: 64272@debbugs.gnu.org, LdBeth , monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jun 26 01:23:13 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 1qDZ4a-000Aav-M8 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 26 Jun 2023 01:23:13 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qDZ4S-0000XA-Cd; Sun, 25 Jun 2023 19:23:04 -0400 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 1qDZ4Q-0000Wz-OD for bug-gnu-emacs@gnu.org; Sun, 25 Jun 2023 19:23:02 -0400 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 1qDZ4Q-0001dQ-FR for bug-gnu-emacs@gnu.org; Sun, 25 Jun 2023 19:23:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qDZ4Q-0001uY-AG for bug-gnu-emacs@gnu.org; Sun, 25 Jun 2023 19:23:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: LdBeth Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 25 Jun 2023 23:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64272 X-GNU-PR-Package: emacs Original-Received: via spool by 64272-submit@debbugs.gnu.org id=B64272.16877353227255 (code B ref 64272); Sun, 25 Jun 2023 23:23:02 +0000 Original-Received: (at 64272) by debbugs.gnu.org; 25 Jun 2023 23:22:02 +0000 Original-Received: from localhost ([127.0.0.1]:43952 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qDZ3S-0001sn-9M for submit@debbugs.gnu.org; Sun, 25 Jun 2023 19:22:02 -0400 Original-Received: from out162-62-57-210.mail.qq.com ([162.62.57.210]:44263) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qDZ3M-0001sM-Tf for 64272@debbugs.gnu.org; Sun, 25 Jun 2023 19:22:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foxmail.com; s=s201512; t=1687735002; bh=qtOFILShwqTq/7xD8QEqf6SfuzFxSJr3NczECZsqQ80=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=v/PshsrLneRvPbtBMlrKkl/mIVpEV5y3zzdwiimjfcGz6yz9HL/UiM5jOONJ2HIio y94RiIKQ7HgHlwlcMS1ht2H373xrunjZ+c8ArQy9zgXhSzSha5PJEBYYbXPgonu6wy TusC64PQxAhmPqh8VW6iBtzzV85f8qhQOA+o3xlI= Original-Received: from 172-12-5-160.lightspeed.sgnwmi.sbcglobal.net ([68.117.253.197]) by newxmesmtplogicsvrsza10-0.qq.com (NewEsmtp) with SMTP id 426AB82D; Mon, 26 Jun 2023 07:16:38 +0800 X-QQ-mid: xmsmtpt1687734998t23ih8vuy X-QQ-XMAILINFO: M/NR0wiIuy70KdOUu3RMLrKdB+8wrPM/nAV2LtRtjEDpJkKX35WVlE4TRrezZo E3JcwiKKn+urLF0UR1O4JZqcDEWZXKyeZpukgVK3hPedvCsL8xjLmBGBR6mec7Lyr6YxwaN8Beow R3+BLCzHnmqlm6EQ8GNDu5yZARibOXh5AXoTpqarunb6pdIOqX8Tsok5f8e6DpQMfj7X/GoXRGNV cCf8QsX6FW6+sMsPeslE4YJsd8wnOcAkBbXHagX/cT343N9upw18FFbF5EXNEFnSldgOj8PtiBjf SOFZ0H3rZksDgp19eCpxXbvin2L2FfTb6u5OjjEj0LbVeXrZ2LJPsUpUlSC5DZlfewA0jlV3QkoO 52sUxgKXjIws7/NFKoJVI18bkvAlNeW8g/qbyXCDa21TyjboNdDmfuyhqeRu3PCq8jkcw/+cz+xy cQmszlhC7HqLSLbFMGYgXylQifUCMxDBGG5NgQ7H8GLWmbvu0vo4DM1tWBxmDB5xa09XG1CfNrA/ +9eJA177dwmta0QQ/TGCv5FQc6PPoSqw/1ngaYdvFNzb0Um6iZdX7XMzIyhs0puedybCiplxutqh PvWls+m2AQB+aBlsm/i3VwO36XK1Fu+jCTQhMOnWNHVNf09uDOcR41AS2NXhY5ebdp49IKk1XalD 3rD/ko29MoaFRnEKMCbihWs3wyrZIXX6TRfDZ0pnKmA8QQEsASykjAT9J+jIAZm4z5L/saGJ8qKy e7Zy28N4z1s3HwEFekkQaG0+5RLVonfQpbUliaTlVW59epkefiNG6LsRcY/2spHYKgHvotoKPnL1 26TlJp+8hizREkILGGLKu0vHP0Lloz/QUADFQMSm X-QQ-XMRINFO: NT0eAOK/sSMcVWZR8HXaz7ha97UQQ6B0Jg== Original-Received: by 172-12-5-160.lightspeed.sgnwmi.sbcglobal.net (Postfix, from userid 501) id 65D0F205513946; Sun, 25 Jun 2023 18:16:36 -0500 (CDT) X-OQ-MSGID: In-Reply-To: <83h6qvxv8q.fsf@gnu.org> X-Face: %[!P\u/BKFRGn_9h9|yO"ho?C0ej^LmM}WMb-`Jfj8OsS^^AKmHYGlD@^|7SEA3UzOGPFbB"OFczY?'\JtJ\lR'@&Y5j; s8{$&|3D>^i.U4l2h?1qpD.+{[$~j]vBeHZf^|BGyL8{/`4 X-Attribution: ldb 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:264076 Archived-At: >>>>> In <83h6qvxv8q.fsf@gnu.org> >>>>> Eli Zaretskii wrote: ldb> If first line is lisp code, and we want to keep the similar ldb> behavior of `hack-local-variables-prop-line`, there needs a mean ldb> to buffer the content of the first line. (Or reset file position ldb> but I don't think there is a way to do that without ldb> substantially change lread.c) Eli> There isn't. We can only unread one character at a time. ldb> But it would be easier to only handle the extra whitespace at ldb> beginning of file. Eli> So now let me turn the table and ask: if we are only going to support Eli> whitespace before the semicolon, then what exactly are we gaining Eli> here? Haha, we would gain pretty much nothing useful if the issue not resolved. So as I continue digging into lread.c and trying to find alternative solutions, I find these: DEFSYM (Qget_file_char, "get-file-char"); /* Used instead of Qget_file_char while loading *.elc files compiled by Emacs 21 or older. */ DEFSYM (Qget_emacs_mule_file_char, "get-emacs-mule-file-char"); While `get-file-char` is exposed to emacs lisp, `get-emacs-mule-file-char' is not even a defined lisp function. There are multiple places in `lread.c` that handles `Qget_emacs_mule_file_char`. Which I believe it time to consider them as dead code and remove them. For the only two functions that calls `lisp_file_lexically_bound_p`, `load` is hard coded to use `get-file-char` which is a wrapper around `getc()`, and `eval-buffer` uses the `BUFFERP (readcharfun)` branch in `readchar`. I think both case can be changed to use a more flexible way to test file local variables rather than stick to the READCHAR UNREAD api. --- ldb