[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dmitry Gutov
Subject: Re: Add a separate mode for .dir-locals.el
Date: Sun, 20 Oct 2019 23:21:11 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]