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

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: joaotavora@gmail.com,  cpitclaudel@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 17 Oct 2019 16:32:59 -0400
> 
> > elisp-flymake-* at least have the advantage of having "flymake" in
> > their names, so some relation is evident.
> 
> Just because the original description of the problem talked about
> flymake doesn't mean the problem is specific to flymake.

Then maybe we should step back and describe the problem better.  I
already suggested that a few emails ago.  Until now, the only problem
that triggered this discussion was with Flymake.

> > Differences that are important for an Emacs major mode?
> > What differences are those?
> 
> To quote the email to which you reply:
> 
>    ... 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?  If we care about the latter, it can be handled by being
sensitive to 'no-byte-compile: t' instead.  Or even compare with the
file name, as bytecomp.el already does, as do other places.

> These probably aren't that important, admittedly.

Exactly.

> But completion in .dir-locals.el doesn't work very well right now,
> because the data has the form (VAR . VAL) but the completion
> function presumes this is Elisp *code* where the head of a list
> should be a function rather than a variable, so it will give you
> bogus completions when trying to complete the variable names.  We
> couldn't cleanly fix this completion in a generic
> emacs-lisp-data-mode, tho: we'd need something more specific like a
> dir-locals-mode.
> 
> > And why not make emacs-lisp-mode recognize these differences and
> > support them accordingly?
> 
> As I said "I don't care if we make it a separate major mode or not".
> 
> Tho I was partly lying: I do think a separate major mode is a better
> choice down the line (e.g. it makes it easier to use auto-mode-alist
> and -*-...-*- to specify the behavior to use for .dir-locals.el,
> ~/.emacs.d/bookmarks, ~/.emacs.d/tramp, ~/.emacs.d/ecomplterc, ...), but
> that's a fairly minor detail compared to the fact that the issue goes
> much further than "flymake in .dir-locals.el".

This all sounds to me like "arguments from the future": we don't yet
have any substantial reasons to define a major mode, but we are trying
hard to think of any potential reason we might have in the future.

If someone wants to work on such a comprehensive elisp-data-mode, with
all the bells and whistles presented above, then by all means please
do.  When the job is done, let's look at the result and decide whether
we want this in core, in ELPA, or not at all.  But until that happens,
all we have is this one minor problem, so the only urgent part is to
solve that problem.  And I consider adding a new major mode for that
as uneconomical, inelegant, and potentially a maintenance burden (if,
as I presume, the more general mode will never materialize).

Please bear with me.  We need to start pretesting Emacs 27 as soon as
possible, and adding unnecessary new features is the wrong way of
making this happen sooner rather than later.

TIA