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

["João Távora" <joaotavora@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

> We already handle this in several places by explicitly exempting
> .dir-locals.el from some operations that make no sense with it.  Why
> ios this problem different?

It's not.  It's a symptom of the same problem we've been avoiding by
sprinkling explicit exemption of a particular data-type in several
places.

> There is no difference, not in general, not in Lisp.

But there is.  As Richard put it, code is data, but data not necessarily
code.

> The byte compiler already knows to ignore .dir-locals.el, at least in
> one of its commands.  If this is the only problem, maybe we need to
> add that exemption in a couple of more places.

That's a worse solution because sprinkling exceptions around the code
creates exactly the "fragmentation" problems that you and Alan seem
intent on avoiding (and rightly so, I add).

Now maybe in those other situations you mentioned, you didn't have a
powerful enough abstraction already in place to avoid the sprinkling.
But in this case you do: derived major modes and buffer-local values.

> I don't think I agree.  If Flymake is modified to do some meaningful
> checks of .dir-locals.el, we may wish to remove this special major
> mode as not needed anymore.

As an aside, I'd like to point out that while you object to Stefans'
"arguments from the future", you provide the same kind of arguments.
Which is perfectly fine for me: anticipating the future is what good
design is about.

To your point: no, no not really.  First, Flymake does **not** need to
be modified to do meaningful checks of .dir-locals.el, or any other type
of file for that matter.  That is a fundamental misunderstanding that I
don't think we've cleared yet.  Like xref.el, project.el, and many
others, it's designed in such a way that extending it to work with a new
data type doesn't require touching the base library in any way.

But, to your concrete example: say you installed Stefan's patch and you
happen to write a Flymake backend (as per the manual/docstrings) for
meaningful dir-locals checks, call that backend
'elis-dir-locals-checker'.  You take this line:

  (add-to-list 'auto-mode-alist '( ".dir-locals.el" . emacs-lisp-data-mode))

And change it to read:

  (add-to-list 'auto-mode-alist '( ".dir-locals.el" . dir-locals-mode))

Then you add these lines

  (define-derived-mode dir-locals-mode emacs-lisp-data-mode "dir-locals"
    (add-to-list 'flymake-diagnostic-functions 'elis-dir-locals-checker nil t))

> Anyway, I think this discussion needs to have a detailed description
> of the problem, before we can continue talking about solutions.

I've done by best.

But I agree like 90% with you when you say "a serious problem didn't
start this thread".  It's true, but that problem is a symptom of bad
design.  Emacs lisp has the exact tool for the job here, we should use
it.  Perhaps you are thinking: "Why just not add the (if (string=
(buffer-file-name) dir-locals-file) ...) wherever and go on with your
life?"  But I am thinking exactly the same about Stefan's patch.

João