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

[Eli Zaretskii <eliz@gnu.org>]

> From: João Távora <joaotavora@gmail.com>
> Cc: monnier@iro.umontreal.ca,  cpitclaudel@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 17 Oct 2019 20:00:38 +0100
> 
> I'm truly very sorry you interpreted it this way, and for the record I
> think you're a great co-maintainer.  I didn't mean quotes to be meant in
> a way that belittled your statement: you'll just have to believe me, I
> meant them as in I was quoting you.  And I know "gross" has a precise
> technical meaning in this list (I've seen you use it more often).

OK.

> > "Gross" means that it solves the problem not where it is caused, and
> > thus makes the maintenance harder by spreading information far from
> > where it should be.  Who will remember that we introduced this mode
> > to fix that particular problem,
> 
> No need: we introduce this change to fix a class of problems, not a
> particular one.

Which class of problems is that?  I see only one problem that was
clearly identified and described: the .dir-locals.el file, and the
problem is that Flymake erroneously reports problems in that file.

What other problems are clearly described like this one?

> The particular situation regarding the flymake-diagnostic-functions
> local happens to fit in that class.  It's a symptom of misdesign,
> not a cause.

What misdesign is that?

> But others have suggested more situations.  I don't think the same
> xref-backend-functions apply to .dir-locals or ~/.emacs.d/recentf
> files for example.

I don't think I understand what you are saying here.  Can we step back
a notch and start by describing the problem in more detail?  What
diagnostics does Flymake produce in the case of .dir-locals.el, and
why does it produce that diagnostics?

> > and who will know that it may need to be updated or removed, depending
> > on the future development of Flymake?  No one will remember.
> 
> I don't understand: the exact same maintenance effort motivated by a
> that hypothetical change to Flymake will be exerted whether we do this
> change or don't.

No, because this new mode is defined in a place that is not Flymake.
So when some change is done in Flymake that affects that mode, someone
needs to remember to update an unrelated mode in an unrelated source
file.

> That's easy to see from Stefan's patch: the same
> number of mentions (2) to flymake-diagnostic-functions persist in the
> exact same places where they did before, which is the major mode
> function emacs-lisp-mode.  There is no duplication, inheritance is
> linear and models "is a".

Stefan's patch doesn't mention anything related to Flymake, so I don't
understand what you are trying to say here.

> Other than that, I really don't see drawbacks to this.  And, to state
> the obvious, since I see drawbacks to the other solutions, I am for this
> one.

What drawbacks do you see in the other solution?  I see only
advantages.

> > I suggested to look at the other similar files and try to describe
> > their common traits as a means to arrive at the decision whether we
> > might need some variant of ELisp mode for such files.
> 
> One common trait is being lisp data that is READable.

I don't think I see how this is relevant to major modes.  Emacs major
modes don't care whether the text is readable by some interpreter or
not (and any Emacs Lisp is also readable, btw).  Emacs major modes
care about syntax.

> Another common trait is being structured data, so syntax is the
> same, sexp navigation automatically applies, as does
> electric-pair-mode, etc.  Basically, whatever is in
> lisp-mode-variables, as someone pointed-out.  I think the proposed
> name, emacs-lisp-data-mode, sums it up well.

You are basically saying that emacs-lisp-mode should do for these
files.  Which is what we use now.