From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Ken Manheimer" Newsgroups: gmane.emacs.devel Subject: Re: allout patch - more safe-local-variables, plus autoloads Date: Fri, 21 Apr 2006 11:02:51 -0400 Message-ID: <2cd46e7f0604210802t28837d4r7aef3d3231a26ea3@mail.gmail.com> References: <2cd46e7f0604171211s5ef0e820gebc4e68b2ce2606d@mail.gmail.com> <8764l7m40w.fsf-monnier+emacs@gnu.org> <87r73uji3b.fsf-monnier+emacs@gnu.org> <87u08oqhq3.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1145631829 855 80.91.229.2 (21 Apr 2006 15:03:49 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 21 Apr 2006 15:03:49 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 21 17:03:39 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 1FWxA4-0000Pk-5D for ged-emacs-devel@m.gmane.org; Fri, 21 Apr 2006 17:03:09 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FWxA3-0001lo-Kk for ged-emacs-devel@m.gmane.org; Fri, 21 Apr 2006 11:03:07 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FWx9s-0001lZ-4j for emacs-devel@gnu.org; Fri, 21 Apr 2006 11:02:56 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FWx9p-0001kt-Jf for emacs-devel@gnu.org; Fri, 21 Apr 2006 11:02:54 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FWx9p-0001km-Eb for emacs-devel@gnu.org; Fri, 21 Apr 2006 11:02:53 -0400 Original-Received: from [64.233.182.185] (helo=nproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FWxBP-0006WO-1G for emacs-devel@gnu.org; Fri, 21 Apr 2006 11:04:31 -0400 Original-Received: by nproxy.gmail.com with SMTP id i2so379601nfe for ; Fri, 21 Apr 2006 08:02:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cCG3YY4IeKDIrUDNPDuDyiARAVIjCRQyBN04pgOBYaiHQGXlhixOGg/XvEmueTOH97zswqLyTqdOWH8mdRM6R12KfogU8U/o0F3cc9gZVWOWFxxNfXiayhln15wBZrXgPehABbRoF+uX3Gv3Y8N8nVhyaFb9aAkbVqSl9AOy4SY= Original-Received: by 10.49.17.9 with SMTP id u9mr1410135nfi; Fri, 21 Apr 2006 08:02:51 -0700 (PDT) Original-Received: by 10.49.51.17 with HTTP; Fri, 21 Apr 2006 08:02:51 -0700 (PDT) Original-To: "Stefan Monnier" In-Reply-To: <87u08oqhq3.fsf-monnier+emacs@gnu.org> Content-Disposition: inline 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:53193 Archived-At: in many cases, the qualifying criteria is already present, in the form of the custom-type information: On 4/20/06, Stefan Monnier wrote: > > If we disallow t and want a quick&dirty replacement predicate for b= oolean > > values, we can either introduce booleanp (seems like a good predica= te to > > have around anyway) or just use symbolp. > [...] > > 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 us= e, > in the hope it will reduce the number of cases where the safe-local-varia= ble > predicate ends up accepting unsafe values as well. seems to me we're heading down the road of duplicating the mechanisms of the custom type system, and that we should be using it. i strongly suspect that the custom types of customizable variables are appropriate as safety criteria in many cases, as well. we wouldn't want to assume that, but i suspect it would be very useful to make it easy for authors to use the custom-type criteria for this purpose. i'm thinking something along the lines of: (defun qualify-value-by-custom-type (symbol value) "True if SYMBOL's type constraint is satisfied by VALUE." (let ((custom-type (get symbol 'custom-type)) type) (when custom-type (setq type (widget-convert custom-type)) (widget-apply type :match value)))) and have that function used when the `safe-local-variable' property value is `t'. the author can still specify alternate criteria if the custom-type criteria is not suitable, or if the variable is state rather than a customized. this scheme would work just right for my allout safe-local-variables - 14 are customizable, where the custom-type criteria are just right for the safety spec, and 3 are state vars, where i need to designate the criteria. when i do need to designate the criteria, i would like to be able to use the expressiveness of the custom type system. (it already provides a boolean criterion, and everything else you could need, like composition, etc.) the one catch is that the customizable variables would have to be autoloaded to have the custom information to test against - that seems like the right thing to do, but would require code changes. what do you think? -- ken manheimer ken.manheimer@gmail.com http://myriadicity.net