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

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Date: Fri, 18 Oct 2019 09:11:19 -0400
> Cc: address@hidden, address@hidden, address@hidden
> 
> >>    ... other things we may want to fix such as the M-C-x binding which
> >>    makes no sense in .dir-locals.el, or the presence of "Byte-compile
> >>    this file" in the menu, ...
> >
> > The former might make sense, because .dir-locals.el can include 'eval'
> > forms, right?
> 
> No, because those forms won't start in column 0, so C-x C-e might work,
> but C-M-x won't.

But 'eval' forms could also include a defun, could they not?

> > If we care about the latter, it can be handled by being
> > sensitive to 'no-byte-compile: t' instead.
> 
> You really want to have to add `no-byte-compile: t` to every
> .dir-locals.el instead of adding an auto-mode-alist rule?

How is it different from adding 'mode: elisp-data' to every relevant
file?  You did say there were files whose names are not
.dir-locals.el, right?

> > Or even compare with the file name, as bytecomp.el already does, as do
> > other places.
> 
> Yes, we can come up with all kinds of hacks, of course.

You can call those "hacks", but we've been doing them for quite some
time, and evidently didn't consider them to be such bad hacks.
Suddenly one more of them makes them unbearable?

> Not sure why you'd want to do that instead of using the clean&simple
> approach of a separate major mode so you can rely on standard
> mechanisms like auto-mode-alist.

Because I don't consider it clean.

> This then lets us solve the original problem by adding a single line
> to auto-mode-alist which can be trivially shown to only affect those
> files that happen to match the regexp we choose to use there.

It isn't a single line, see above.

> Creating a major mode is cheap and easy.  No need to be afraid.  Even if
> it inserts itself inside a pre-existing part of the hierarchy as is the
> case here.

Creating a major mode for this issue is like shooting sparrows with
cannons.  Why not extend emacs-lisp-mode to DTRT with
data-that-doesn't-make-sense-as-code instead?