From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Richard M. Stallman" Newsgroups: gmane.emacs.devel Subject: Re: risky local variable mechanism Date: Sun, 12 Feb 2006 23:40:02 -0500 Message-ID: References: <200602101313.13663.jyavner@member.fsf.org> <200602110319.k1B3Jhv15827@raven.dms.auburn.edu> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: sea.gmane.org 1139805703 21609 80.91.229.2 (13 Feb 2006 04:41:43 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 13 Feb 2006 04:41:43 +0000 (UTC) Cc: jyavner@member.fsf.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 13 05:41:42 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1F8VWn-0000FV-4N for ged-emacs-devel@m.gmane.org; Mon, 13 Feb 2006 05:41:33 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F8VWm-0007vJ-Gh for ged-emacs-devel@m.gmane.org; Sun, 12 Feb 2006 23:41:32 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1F8VVQ-0007MX-Ao for emacs-devel@gnu.org; Sun, 12 Feb 2006 23:40:08 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1F8VVO-0007Lq-TB for emacs-devel@gnu.org; Sun, 12 Feb 2006 23:40:07 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F8VVO-0007Le-7E for emacs-devel@gnu.org; Sun, 12 Feb 2006 23:40:06 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.52) id 1F8VZh-0002Sv-Qs; Sun, 12 Feb 2006 23:44:33 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1F8VVJ-0007N3-WF; Sun, 12 Feb 2006 23:40:02 -0500 Original-To: Luc Teirlinck In-reply-to: <200602110319.k1B3Jhv15827@raven.dms.auburn.edu> (message from Luc Teirlinck on Fri, 10 Feb 2006 21:19:43 -0600 (CST)) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:50442 Archived-At: unsafep.el (used by SES) calls risky-local-variable-p with NIL as the second argument, because it doesn't know yet what value will be assigned. If the current risky-local-variable-p is too unreliable for `enable-local-eval' to such a degree that an urgent fix is needed, is it really reliable enough for unsafep? Maybe it isn't. However, it is not necessary for unsafep to be completely as strict as the local variable criteria in all ways, because unsafep checks for function values. Meanwhile, as regards the special meaning of nil as the second arg to risky-local-variable-p, we could instead have a variable risky-local-variable-token, whose value is a particular cons cell, and give that cons cell the special meaning of "unspecified value". The value that hack-one-local-variable produces is made by `read' so it will never be eq to risky-local-variable-token.