GNU bug report logs -
#64281
[Feature Request] Recognize “#” syntax when reading local-variables
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 64281 in the body.
You can then email your comments to 64281 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64281
; Package
emacs
.
(Sun, 25 Jun 2023 12:00:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Shynur Xie <one.last.kiss <at> outlook.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sun, 25 Jun 2023 12:00:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
For example, if I want to use UTF-8-UNIX only for files directly under
directory DIR, and those under DIR/SUBDIR/ or its subdirectories, I
can write this way:
((nil . ((subdirs . nil)
. #1=((coding . utf-8-unix))))
("SUBDIR" . ((nil . #1#))))
If “#” can be recognized when reading local-variables, we can write
“((coding . utf-8-unix))” only once. Thanks.
--
shynur
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64281
; Package
emacs
.
(Sun, 25 Jun 2023 13:54:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 64281 <at> debbugs.gnu.org (full text, mbox):
It seems that this is a intentional behavior:
<https://www.gnu.org/software/emacs/manual/html_node/elisp/File-Local-Variables.html>:
> For additional safety, read-circle is temporarily bound to nil when
> Emacs reads file-local variables.
No further question; can be closed now.
(I wonder if we can treat ~/.emacs.d/.dir-locals.el specially, or tell
Emacs which files can be treated specially -- enable read-circle.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64281
; Package
emacs
.
(Sun, 25 Jun 2023 15:09:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 64281 <at> debbugs.gnu.org (full text, mbox):
> From: Shynur Xie <one.last.kiss <at> outlook.com>
> Date: Sun, 25 Jun 2023 13:53:30 +0000
> msip_labels:
>
> It seems that this is a intentional behavior:
>
> <https://www.gnu.org/software/emacs/manual/html_node/elisp/File-Local-Variables.html>:
>
> > For additional safety, read-circle is temporarily bound to nil when
> > Emacs reads file-local variables.
>
> No further question; can be closed now.
>
> (I wonder if we can treat ~/.emacs.d/.dir-locals.el specially, or tell
> Emacs which files can be treated specially -- enable read-circle.)
Stefan, any comments before we close this?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64281
; Package
emacs
.
(Sun, 25 Jun 2023 15:47:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 64281 <at> debbugs.gnu.org (full text, mbox):
>> It seems that this is a intentional behavior:
>>
>> <https://www.gnu.org/software/emacs/manual/html_node/elisp/File-Local-Variables.html>:
>>
>> > For additional safety, read-circle is temporarily bound to nil when
>> > Emacs reads file-local variables.
>>
>> No further question; can be closed now.
>>
>> (I wonder if we can treat ~/.emacs.d/.dir-locals.el specially, or tell
>> Emacs which files can be treated specially -- enable read-circle.)
>
> Stefan, any comments before we close this?
file/dir-local variables are dangerous enough as it is, I think. If you
want to do better, you can use an actual ELisp file.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64281
; Package
emacs
.
(Sun, 25 Jun 2023 16:17:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 64281 <at> debbugs.gnu.org (full text, mbox):
> >> It seems that this is a intentional behavior:
> >> .../File-Local-Variables.html:
> >>
> >> > For additional safety, read-circle is temporarily bound
> >> > to nil when Emacs reads file-local variables.
> >>
> >> No further question; can be closed now.
> >>
> >> (I wonder if we can treat ~/.emacs.d/.dir-locals.el specially, or tell
> >> Emacs which files can be treated specially -- enable read-circle.)
> >
> > Stefan, any comments before we close this?
>
> file/dir-local variables are dangerous enough as it is, I think. If you
> want to do better, you can use an actual ELisp file.
1. That Elisp manual node (`File Local Variables')
doesn't say what danger is avoided by disabling
`read-circle', but it seems to suggest that that
danger is pointed out in node `Read Syntax for
Circular Objects':
For additional safety, read-circle is temporarily
bound to nil when Emacs reads file-local variables
(see Input Functions). This prevents the Lisp reader
from recognizing circular and shared Lisp structures
(see Read Syntax for Circular Objects).
Yes, that's what it does, but why? What's the
"additional safety" about? What danger's involved?
Node `Read Syntax for Circular Objects' says nothing
about any possible danger (security/safety problem)
circular objects can introduce. Can we please say
something about the danger in that node?
2. Wouldn't it make sense (be useful) to let users
and code decide whether to allow this for particular
file-local variables?
A question from ignorance - see #1, above. Is it
helpful to talk about danger and avoiding it,
without giving readers some idea of what's involved?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64281
; Package
emacs
.
(Mon, 26 Jun 2023 10:22:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 64281 <at> debbugs.gnu.org (full text, mbox):
To: Drew
> drew> Node `Read Syntax for Circular Objects' says nothing about any
> drew> possible danger (security/safety problem) circular objects can
> drew> introduce.
I guess that “.dir-locals.el” _isn’t_ read by ELisp syntax, so if you
visit a “.dir-locals.el” file, Emacs will choose “Lisp-Data mode” for
it. And (info "(elisp)Circular Objects") _is_ about Elisp read
syntax.
> stefan> To: Eli
> stefan> If you want to do better, you can use an actual ELisp file.
^^^^^^^^^^^^^^^^^^^^
Seems like it is indeed not now, though uses a “.el” postfix.
____________________
To: ALL
> drew> Wouldn't it make sense (be useful) to let users and code
> drew> decide whether to allow this for particular file-local
> drew> variables?
Agree.
There have already been numerous potential dangerous behaviors,
perhaps one more won’t make much of a difference. I think as long as
users are provided with appropriate warnings, it should suffice. For
instance, the following code snippet can cause Emacs to crash
instantly, but we still shouldn’t deprive users of their right to
execute it:
(clear-string (symbol-name t))
Luckily, manual contains a corresponding warning.
--
shynur
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Mon, 26 Jun 2023 12:22:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Shynur Xie <one.last.kiss <at> outlook.com>
:
bug acknowledged by developer.
(Mon, 26 Jun 2023 12:22:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 64281-done <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Shynur Xie <one.last.kiss <at> outlook.com>, 64281 <at> debbugs.gnu.org
> Date: Sun, 25 Jun 2023 11:46:13 -0400
>
> >> It seems that this is a intentional behavior:
> >>
> >> <https://www.gnu.org/software/emacs/manual/html_node/elisp/File-Local-Variables.html>:
> >>
> >> > For additional safety, read-circle is temporarily bound to nil when
> >> > Emacs reads file-local variables.
> >>
> >> No further question; can be closed now.
> >>
> >> (I wonder if we can treat ~/.emacs.d/.dir-locals.el specially, or tell
> >> Emacs which files can be treated specially -- enable read-circle.)
> >
> > Stefan, any comments before we close this?
>
> file/dir-local variables are dangerous enough as it is, I think. If you
> want to do better, you can use an actual ELisp file.
Agreed.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 25 Jul 2023 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 324 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.