Re: [PATCH] allow function values for `enable-local-eval'

[Karl Fogel]

address@hidden (Kim F. Storm) writes:
> Whatever we do to automate this, I don't think we will ever
> cover every possible hook that people would like to "accept
> by default".

Yes, that's very true.

I'll make one last case for the fully general solution, the
`enable-local-eval-functions' proposed earlier by Kim Storm, and if
not successful will retire gracefully from this thread :-).

Please consider the situation as a whole, in comparison to other
programs that face the same problem:

Naturally, setting `enable-local-eval' to `t' makes Emacs have the
same problem MS-Word (and Outlook?) used to have: it would run
possibly unsafe code, without giving the user a chance to say no.

So there's the option of setting the variable to non-nil, non-t.  This
makes Emacs behave like MS-Word & Outlook today: it asks you before
running the code.  This is certainly safer, but it involves an
interactive query of the user.  That's a pretty serious disadvantage,
because it means Emacs can behave inconsistently -- you can't predict
when it might prompt, nor do you get fine-grained control over whether
prompts or not.  The prompting can interfere with automated and
semi-automated processes, such as the tags-query-replace example from
my earlier mail.

But, there's a solution available to Emacs that is not available to
MS-Word.  Emacs has an fully general extension language.  By offering
a well-placed hook, we can allow the user to *delegate* the task of
deciding whether or not to run the code.  This gives people a whole
new level of control over how to treat received code, and therefore
control over the consistency of Emacs' behavior (to prompt or not to
prompt) when visiting files.

Meanwhile, all the other solutions we're discussing, some already
done, would still be available, implemented through this general
underlying mechanism where appropriate.  Thus, those users who want a
simpler method of customization will still have it available; but
those who want to go to the trouble of writing a custom decision
procedure will at least be able to do so.

This kind of customizability is what Emacs is all about.  The hook
won't interfere with those who don't go looking for it.  Emacs already
has plenty of specialized hooks, and people already know how to ignore
the ones they don't need.  But those who _do_ need this one will be
overjoyed to find it.

Thoughts?

-Karl

address@hidden (Kim F. Storm) writes:
> Whatever we do to automate this, I don't think we will ever
> cover every possible hook that people would like to "accept
> by default".
> 
> So I still propose that we provide a *simple* customization option
> safe-local-eval-forms which is just a list that contains verbatim
> copies of the eval hooks which the user considers as safe.
> 
> We could then enhance the functionality when the user is
> asked to "eval local hook (y/n)" to "eval local hook (y/n/s)"
> where "s" saves the hook in safe-local-eval-forms.
> 
> But just having the option would be great!