From: Chong Yidong <cyd@stupidchicken.com>
Cc: jyavner@member.fsf.org, emacs-devel@gnu.org
Subject: Re: risky local variable mechanism
Date: Mon, 13 Feb 2006 16:03:28 -0500 [thread overview]
Message-ID: <87r767ug2n.fsf@stupidchicken.com> (raw)
In-Reply-To: <E1F8jwf-0007v1-FR@fencepost.gnu.org> (Richard M. Stallman's message of "Mon, 13 Feb 2006 15:05:13 -0500")
> it is not clearly right for unsafep to reject binding all variables
> that would be rejected in a local variables list, given that unsafep
> can detect giving functions as values.
The commentary section of unsafep.el says:
;; A temporary binding is unsafe if its symbol:
;; 1. Has the `risky-local-variable' property.
;; 2. Has a name that ends with -command, font-lock-keywords(-[0-9]+)?,
;; font-lock-syntactic-keywords, -form, -forms, -frame-alist, -function,
;; -functions, -history, -hook, -hooks, -map, -map-alist, -mode-alist,
;; -predicate, or -program.
This is exactly the definition of risky variables in my patch. In
fact, the *current* definition of risky-local-variable-p does not
match this definition exactly, since it also checks
`safe-local-property'. (The way it checks it is rather inconsistent,
BTW, there is no way to distinguish between VAL=nil meaning "any value
of the variable" and VAL=nil meaning "the value nil is supplied" when
`safe-local-property' is a function. So if unsafep.el relied on this,
it was relying on a bug).
Maybe the commentary section of unsafep.el is wrong, and the latter
definition is intended. But according to the docstring of
`unsafep-variable', it is supposed to detect if a variable is "safe as
a let-binding" -- no mention of file local variables there.
To clarify this issue, I'd like to ask: what's the specific goal of
unsafep.el? Can anyone come up with a precise example of a problem
with using unsafep.el resulting from the proposed changes to the file
local variables code? With a specific example, we can look into how
to adapt unsafep.el; otherwise, we're just going around in circles.
(Since SES seems to be the only package that uses unsafep.el, it looks
like the example will have to come from there.)
next prev parent reply other threads:[~2006-02-13 21:03 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-10 18:13 risky local variable mechanism Jonathan Yavner
2006-02-11 3:19 ` Luc Teirlinck
2006-02-13 4:40 ` Richard M. Stallman
2006-02-11 17:08 ` Chong Yidong
2006-02-11 20:27 ` Jonathan Yavner
2006-02-11 20:46 ` Chong Yidong
2006-02-12 19:29 ` Richard M. Stallman
2006-02-12 19:52 ` Chong Yidong
2006-02-13 20:05 ` Richard M. Stallman
2006-02-13 21:03 ` Chong Yidong [this message]
2006-02-12 1:10 ` Luc Teirlinck
2006-02-12 19:29 ` Richard M. Stallman
-- strict thread matches above, loose matches on Subject: below --
2006-02-02 8:14 Risky " LENNART BORGMAN
[not found] <E1F46oA-0005O8-FC@monty-python.gnu.org>
2006-02-01 15:24 ` Jonathan Yavner
2006-02-01 17:00 ` Stefan Monnier
2006-02-01 23:31 ` Kim F. Storm
2006-02-02 5:05 ` Stefan Monnier
2006-02-01 23:12 ` Chong Yidong
2006-02-02 16:21 ` Richard M. Stallman
2006-02-02 17:00 ` Stefan Monnier
2006-01-31 23:09 Richard M. Stallman
2006-02-01 0:37 ` Stefan Monnier
2006-02-01 0:41 ` Luc Teirlinck
2006-02-01 2:39 ` Stefan Monnier
2006-02-02 4:17 ` Richard M. Stallman
2006-02-02 12:42 ` Kim F. Storm
2006-02-03 23:43 ` Richard M. Stallman
2006-02-04 4:34 ` Luc Teirlinck
2006-02-05 17:34 ` Richard M. Stallman
2006-02-06 6:00 ` Luc Teirlinck
2006-02-07 6:07 ` Richard M. Stallman
2006-02-07 2:47 ` Luc Teirlinck
2006-02-07 16:45 ` Chong Yidong
2006-02-08 1:49 ` Luc Teirlinck
2006-02-08 2:09 ` Chong Yidong
2006-02-08 2:18 ` Luc Teirlinck
2006-02-08 4:30 ` Chong Yidong
2006-02-08 4:56 ` Chong Yidong
2006-02-08 5:02 ` Luc Teirlinck
2006-02-08 5:00 ` Luc Teirlinck
2006-02-08 5:28 ` Chong Yidong
2006-02-08 3:13 ` Stefan Monnier
2006-02-08 4:51 ` Chong Yidong
2006-02-08 5:07 ` Stefan Monnier
2006-02-08 5:25 ` Chong Yidong
2006-02-08 6:00 ` Stefan Monnier
2006-02-08 13:35 ` Chong Yidong
2006-02-08 21:41 ` Stefan Monnier
2006-02-08 6:06 ` Luc Teirlinck
2006-02-08 6:49 ` Stefan Monnier
2006-02-08 5:48 ` Luc Teirlinck
2006-02-08 6:08 ` Stefan Monnier
2006-02-08 6:17 ` Luc Teirlinck
2006-02-08 6:48 ` Stefan Monnier
2006-02-09 17:47 ` Richard M. Stallman
2006-02-09 17:47 ` Richard M. Stallman
2006-02-10 23:57 ` Luc Teirlinck
2006-02-08 9:21 ` Juri Linkov
2006-02-08 15:45 ` Drew Adams
2006-02-09 3:58 ` Luc Teirlinck
2006-02-09 17:48 ` Richard M. Stallman
2006-02-10 5:34 ` Chong Yidong
2006-02-10 17:03 ` Stefan Monnier
2006-02-10 17:54 ` Chong Yidong
2006-02-11 0:31 ` Luc Teirlinck
2006-02-12 1:00 ` Stefan Monnier
2006-02-12 4:30 ` Richard M. Stallman
2006-02-11 3:31 ` Luc Teirlinck
2006-02-12 1:02 ` Stefan Monnier
2006-02-12 1:15 ` Luc Teirlinck
2006-02-11 16:44 ` Richard M. Stallman
2006-02-14 1:33 ` Chong Yidong
2006-02-14 2:50 ` Luc Teirlinck
2006-02-14 22:17 ` Richard M. Stallman
2006-02-14 3:16 ` Luc Teirlinck
2006-02-14 3:32 ` Luc Teirlinck
2006-02-14 3:38 ` Luc Teirlinck
2006-02-14 3:48 ` Chong Yidong
2006-02-14 4:11 ` Luc Teirlinck
2006-02-14 4:26 ` Chong Yidong
2006-02-02 12:47 ` Kim F. Storm
2006-02-01 2:30 ` Chong Yidong
2006-02-02 4:15 ` Richard M. Stallman
2006-02-02 9:54 ` David Kastrup
2006-02-02 14:54 ` Kim F. Storm
2006-02-03 5:04 ` Richard M. Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r767ug2n.fsf@stupidchicken.com \
--to=cyd@stupidchicken.com \
--cc=emacs-devel@gnu.org \
--cc=jyavner@member.fsf.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).