From: "Ken Manheimer" <ken.manheimer@gmail.com>
Cc: rms@gnu.org, emacs-devel@gnu.org
Subject: Re: allout patch - more safe-local-variables, plus autoloads
Date: Fri, 21 Apr 2006 11:02:51 -0400 [thread overview]
Message-ID: <2cd46e7f0604210802t28837d4r7aef3d3231a26ea3@mail.gmail.com> (raw)
In-Reply-To: <87u08oqhq3.fsf-monnier+emacs@gnu.org>
in many cases, the qualifying criteria is already present, in the form
of the custom-type information:
On 4/20/06, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> > 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.
> [...]
> > 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.
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
next prev parent reply other threads:[~2006-04-21 15:02 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-17 19:11 allout patch - more safe-local-variables, plus autoloads Ken Manheimer
2006-04-18 12:57 ` Richard Stallman
2006-04-18 13:18 ` Stefan Monnier
2006-04-19 4:17 ` Richard Stallman
2006-04-19 4:39 ` Stefan Monnier
2006-04-19 21:12 ` Richard Stallman
2006-04-20 2:47 ` Luc Teirlinck
2006-04-20 17:34 ` Stefan Monnier
2006-04-21 13:07 ` Richard Stallman
2006-04-21 15:02 ` Ken Manheimer [this message]
2006-04-21 15:09 ` David Kastrup
2006-04-21 15:39 ` Ken Manheimer
2006-04-21 17:15 ` Stefan Monnier
2006-04-24 21:19 ` Ken Manheimer
2006-04-19 23:08 ` Ken Manheimer
2006-04-20 10:35 ` Richard Stallman
2006-04-20 18:49 ` autoloads for safe-local-variables (was: allout patch - more safe-local-variables, plus autoloads) Reiner Steib
2006-04-20 19:52 ` autoloads for safe-local-variables (was: allout patch - moresafe-local-variables, " Stuart D. Herring
2006-04-21 13:07 ` autoloads for safe-local-variables (was: allout patch - more safe-local-variables, " Richard 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=2cd46e7f0604210802t28837d4r7aef3d3231a26ea3@mail.gmail.com \
--to=ken.manheimer@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=rms@gnu.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).