Re: mark .dir-locals.el buffer or file as safe instead of variables as safe

[Phil Sainty]

A useful enhancement may be the ability for the user to confirm a
value as trusted only for particular contexts.  If the context was the
directory of the .dir-locals.el file (or dir-locals-directory-cache
entry), then the user could confirm (once) a trusted value for
anything covered by that .dir-locals.el and have it automatically
accepted in future for other files covered by the same .dir-locals.el;
but they would still need to confirm/trust an identical value for the
variable when specified in another .dir-locals.el file elsewhere.

(This is of course different to trusting the .dir-locals.el file
itself.)

This functionality is facilitated to an extent by the user's ability
to assign a custom safe-local-variable predicate to a variable (in
which they could test whatever contexts they wish, and return non-nil
if the context and value are agreeable).  Arguably the `eval' pseudo-
variable also gives them free rein to achieve such goals.

Still, I can see utility in supporting such functionality in a more
direct manner.


Beyond that, I've often wished I could make a particular dir-local
value "ignored" for a particular .dir-locals.el file from some
codebase that I'm working with, without necessarily ignoring it
elsewhere; so I'm now wondering whether as well as callback functions
for "safe", there should be support for callback functions for
"ignored" and "risky" as well?  And similarly, if the aforementioned
direct support for contextually-trusted values were to be added, it
would make sense to allow contextual ignore/risky there too.

(I'm not sure whether contextual-risky makes as much sense, but it
would seem odd to exclude it.)

As it is, unless I've missed something, there are cases where I must
either continually answer "no" to the prompt for accepting local
values (each time I visit a file associated with that .dir-locals.el),
or else get fed up and edit or delete the .dir-locals.el file (which
of course might be under version control, which is then awkward if I
don't actually want my change to be committed).

There are also cases when I'd like to mark *some* of the values as
permanently trusted, but might want to ignore others.

Perhaps as well as the y/n/! options, there could be a new binding to
invoke a more advanced UI for deciding what to do with the values on a
per-variable basis.  Contextual behaviour options could be exposed in
that UI.


-Phil