bug#58506: Use ".dir-locals.eld" and ".dir-locals-2.eld" when they exist

[Philip Kaludercic]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> As Philip points out, "hard to write" is circumvented by
>> `add-dir-local-variable`.
>
> My ever-reliable statistics team is informing me that 99.74% of
> .dir-locals files are written by hand.

Really?  I guess by virtue of participating in this very discussion I'm
not the average Emacs user, but I'd be surprised if
`add-dir-local-variable' is that unknown.

>> We should either make it use a proper subset of ELisp, or make it use
>> a syntax that's sufficiently different.
>>
>> Maybe something like:
>>
>>     (c-mode
>>      (:set c-file-style "GNU")
>>      (:set treesit-thing t)
>>      (:set odd-list (cons 3 odd-list))
>>      (:minor-mode indent-tabs-mode -1) ;; Disable
>>      (:minor-mode blink-parentheses-mode))

And I assume that if you don't wrap the block in a (foo-mode ...)
construct, that the settings will apply to all modes, right?

> Yes, that's much better than my initial suggestion.  But I like the
> safe-lisp approach better.

... why not both?  I can imagine that safe-lisp will take a while before
it becomes usable, just because something like `safe-eval-p' has to be
quite exhaustive, and at the very least handle all special forms.  Elisp
isn't a Scheme so that means that a number of methods have to be
implemented...

Meanwhile .dir-locals.eld with Stefan's syntax seems like a good
improvement over the current syntax -- especially if you are right about
how many people write these files from hand.

>> [ I dropped the "set-early" because I still haven't heard any good
>>   reason why we'd need that nor what that would really mean (e.g. how it
>>   could be implemented).  ]
>
> Some major modes react to variables to change how they work.  So
> you'd say
>
> (setq org-thingamabob-syntax-version 2)
> (org-thingamabob-mode)
>
> And this has to be set before the mode is called, because the mode is
> very expensive and re-interpreting the file afterwards is ungood.
>
>>> `safep' would have to be a bit adjusted -- a `safep' for `odd-list'
>>> would be (cl-every #'oddp) etc.
>>
>> Sorry, I don't know what problem you're alluding to.
>> Why would `safep` need to be adjusted?
>
> It's not necessary, but it'd be nice to be able to say "this element is
> safe to add to the list" instead of saying "after adding this element to
> the list, the resulting list is safe".

I have seen a lot of packages that either forget or don't bother to
specify safe values even if they are applicable.  Making it easier to do
so could help motivate maintainers to specify these.