From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: allout patch - more safe-local-variables, plus autoloads Date: Thu, 20 Apr 2006 13:34:54 -0400 Message-ID: <87u08oqhq3.fsf-monnier+emacs@gnu.org> References: <2cd46e7f0604171211s5ef0e820gebc4e68b2ce2606d@mail.gmail.com> <8764l7m40w.fsf-monnier+emacs@gnu.org> <87r73uji3b.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1145554521 25696 80.91.229.2 (20 Apr 2006 17:35:21 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 20 Apr 2006 17:35:21 +0000 (UTC) Cc: ken.manheimer@gmail.com, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 20 19:35:15 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 1FWd3e-00045S-Mi for ged-emacs-devel@m.gmane.org; Thu, 20 Apr 2006 19:35:11 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FWd3e-0008P4-3U for ged-emacs-devel@m.gmane.org; Thu, 20 Apr 2006 13:35:10 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FWd3S-0008Oh-M1 for emacs-devel@gnu.org; Thu, 20 Apr 2006 13:34:58 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FWd3R-0008OV-12 for emacs-devel@gnu.org; Thu, 20 Apr 2006 13:34:58 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FWd3Q-0008OS-SN for emacs-devel@gnu.org; Thu, 20 Apr 2006 13:34:56 -0400 Original-Received: from [209.226.175.188] (helo=tomts25-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FWd4n-0003Wk-2v; Thu, 20 Apr 2006 13:36:21 -0400 Original-Received: from alfajor ([70.53.192.213]) by tomts25-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20060420173454.NTUQ28586.tomts25-srv.bellnexxia.net@alfajor>; Thu, 20 Apr 2006 13:34:54 -0400 Original-Received: by alfajor (Postfix, from userid 1000) id D04B9D91AB; Thu, 20 Apr 2006 13:34:54 -0400 (EDT) Original-To: rms@gnu.org In-Reply-To: (Richard Stallman's message of "Wed, 19 Apr 2006 17:12:25 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:53143 Archived-At: > If we disallow t and want a quick&dirty replacement predicate for boolean > values, we can either introduce booleanp (seems like a good predicate to > have around anyway) or just use symbolp. > symbolp is not correct; a boolean variable can have any Lisp object > as its value. If booleanp is mean to mean "is t or nil", that would > also be incorrect. The idea behind safe-local-variable, AFAIK, is to accept values which are known to be safe. It may reject valid values if they're not known to be safe and that's OK because the user still gets a chance to accept the value. In the case of boolean variables, history shows that they have a non-negligible chance of being extended in the future to give special meaning to some other values (typically some other symbol, or to values which are functions, ...). So it's better to only consider as safe the values nil and t which are least likely to change meaning (and become potentially unsafe) in the future. > I don't see any great need to eliminate t as a value, > and certainly not at the cost of any real annoyance. The intention is to force the author to think about which predicate to use, in the hope it will reduce the number of cases where the safe-local-variable predicate ends up accepting unsafe values as well. Stefan