Re: Add a separate mode for .dir-locals.el

[Dmitry Gutov <dgutov@yandex.ru>]

On 20.10.2019 8:38, Eli Zaretskii wrote:

>> xref-backend-functions and project-external-roots-functions come to mind
>> as well. And they all will have to duplicate the check.
> 
> What check did you have in mind? 

The "does this file contain an Elisp program" check.

> AFAIK, the hooks you mention don't
> need to byte-compile the file, so the issue at hand is not relevant
> for them.  And at least for Xref, I don't see why it should handle
> ELisp data files differently from any other ELisp files.

That depends on how we want to treat those files in general. If each 
such file is an "opaque" Lisp form, there's no reason to expect even 
normal Elisp variables here. So Xref could simply show/do nothing.

But okay, we can assume that such files will contain symbols 
corresponding to variables/functions/etc in the current Emacs session. 
Seeing feature names there is highly unlikely, though, so Xref could 
filter out those in the search results. *If* the current file is in 
elisp-data-mode.

project-external-roots-functions, again, would probably return nil in 
such files.

And elisp-completion-at-point, as people mentioned already, would have 
to special-case them as well. So we might as well write a new completion 
function, for a new major mode.

So we have several features that, somewhere in the implementation, will 
need to make that check and act differently because of that. A new major 
mode will do that nicely.

Speaking of no-brainers, I don't see why you're fighting this one.

Major modes are one of our methods of extensibility. Someone somewhere 
will create a new package/file-name/use-case for such files. They'll 
only have to add a new entry to auto-mode-alist, and voila, the new 
Elisp Data file buffer behaves as expected. They won't have to wait 
until Emacs hardcodes the new file name somewhere as well.