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 19:45:14 -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="33977"; 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 02:51:25 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 1qDaRx-0008er-3e for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 26 Jun 2023 02:51:25 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qDaRc-0005wt-LQ; Sun, 25 Jun 2023 20:51: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 1qDaRa-0005we-8l for bug-gnu-emacs@gnu.org; Sun, 25 Jun 2023 20:51: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 1qDaRZ-0008UG-WF for bug-gnu-emacs@gnu.org; Sun, 25 Jun 2023 20:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qDaRZ-0004EI-RP for bug-gnu-emacs@gnu.org; Sun, 25 Jun 2023 20:51:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: LdBeth Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 26 Jun 2023 00:51:01 +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.168774064116232 (code B ref 64272); Mon, 26 Jun 2023 00:51:01 +0000 Original-Received: (at 64272) by debbugs.gnu.org; 26 Jun 2023 00:50:41 +0000 Original-Received: from localhost ([127.0.0.1]:43996 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qDaRF-0004Dk-7r for submit@debbugs.gnu.org; Sun, 25 Jun 2023 20:50:41 -0400 Original-Received: from out203-205-221-155.mail.qq.com ([203.205.221.155]:47860) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qDaR9-0004DM-PV for 64272@debbugs.gnu.org; Sun, 25 Jun 2023 20:50:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foxmail.com; s=s201512; t=1687740319; bh=YJPeulPMBc77Mr84AWjn9VHrVL9LVqGSDRSxviFo1pU=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=Ym4Y0hmczlB9lYsM+jcKZ91L5/dvIAnb9h0TGpd79VBEUQG0kGxxdViO6ENZEqeL5 YxhQW3fAF8x5NXEtNL16Y8xgSQ1oTucNoxZw+w4CPKySiAa7irz2UYb8LWuQGkoqd6 LWoPAKqR3NLHKbevMv6zqyghL24zuhIf+w8IYNlw= Original-Received: from 172-12-5-160.lightspeed.sgnwmi.sbcglobal.net ([68.117.253.197]) by newxmesmtplogicsvrszb1-0.qq.com (NewEsmtp) with SMTP id B4F9821B; Mon, 26 Jun 2023 08:45:15 +0800 X-QQ-mid: xmsmtpt1687740315tjj7hvolz X-QQ-XMAILINFO: M/NR0wiIuy70KdOUu3RMLrIqjyYZdwyKAsCnhJlc9Qi9pUZtYFyv9nIwGN2CGY ou5BZq7h9fg4ODTSVB1v6z9qi+ml5rE0vfAjs86I82+vB6q7zWbuVlY23U12W28agbt3caOoBeOm CEhRjBWxGLiFXCDUZpJqQi5FKEiEasjNSwuRXM9F5sQjZWBcJeOvbljvE7sHdEv9GrDbZUdE4opG FBDyG4SiLOPUbV1wfL1jTskz5fWjCbNLM53rJ3xtE367M324UtHAilkNhZAFtL7K4UsYbYsByxsw 2uUnKcw1FHY2YIQ1sBtMUvL0hSrgo/dpTkAodMQLjbMCdV2M9lwVNsi+YwSe5zJ1fFA4Yt6h7oJ6 lEua8Et5auF/Qp5mB1B3ASXMLQnNlb4wTgIC5TgH2352Mo6d/ZEtsKdhONz5slM1Lna7+eZHafnT VSz9qJw58UHe/ycM46bpm9WpgaEVNhK+pPDYx3EZ+UcSlyRFJFBWBKJLj5zem83VNa++pb6BTV9S WyJL50M8ZYSyWlMD18h+ipZkzldhQTz8KlX9MoMDIo7mFNC89Y8QVYHcQYcuA7K0G5N3xDUOkcwk LBRHkDf5ItpE1lWdkMB+hansQQ4HQ/CzmQZZsk6Gg6V8jUedKbNchTA0SUB2QCeS5Eu3+RfWbf+4 gRI3ec3XsdpHYV7DzbvP38ZGmr42T8enaM5e4k15usMqVgHX9mLG3Q1lClP6Y1U0/sVgRhXFW8II zmU+ntZgzxT8qwLVY+YzpvqaaFcHcA/XmpAyabo4T5o76e5F7fqDhAvlVe3Gr9fU6WTCenr9uRin 0O7R0RpWIf+pmXTLupn+UG6LdT/ROW8b3D3AyL83 X-QQ-XMRINFO: M0RWTeBkoNRBR1Uh12iQNRvA1CSLhD8+1Q== Original-Received: by 172-12-5-160.lightspeed.sgnwmi.sbcglobal.net (Postfix, from userid 501) id 4CBC72055154B3; Sun, 25 Jun 2023 19:45:14 -0500 (CDT) X-OQ-MSGID: In-Reply-To: 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-Now-Playing: =?UTF-8?Q?=E4=B8=AD=E5=8E=9F_?= =?UTF-8?Q?=E9=BA=BB=E8=A1=A3?= - =?UTF-8?Q?=E4=BA=BA=E5=BD=A2=E8=A8=80=E8=AA=9E?= 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:264077 Archived-At: >>>>> In >>>>> LdBeth wrote: ldb> So as I continue digging into lread.c and trying to find alternative ldb> solutions, I find these: ldb> DEFSYM (Qget_file_char, "get-file-char"); ldb> /* Used instead of Qget_file_char while loading *.elc files compiled ldb> by Emacs 21 or older. */ ldb> DEFSYM (Qget_emacs_mule_file_char, "get-emacs-mule-file-char"); ldb> While `get-file-char` is exposed to emacs lisp, ldb> `get-emacs-mule-file-char' is not even a defined lisp function. ldb> There are multiple places in `lread.c` that handles ldb> `Qget_emacs_mule_file_char`. Which I believe it time to consider ldb> them as dead code and remove them. Sorry, I misread on how `Qget_emacs_mule_file_char' is been used. It is still been used internally in `lread.c' because of how READCHAR works. ldb> For the only two functions that calls `lisp_file_lexically_bound_p`, ldb> `load` is hard coded to use `get-file-char` which is a wrapper around ldb> `getc()`, and `eval-buffer` uses the `BUFFERP (readcharfun)` ldb> branch in `readchar`. I think both case can be changed to ldb> use a more flexible way to test file local variables ldb> rather than stick to the READCHAR UNREAD api. I think this still holds valid. --- ldb