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

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

Eli Zaretskii <eliz@gnu.org> writes:
>> Also, with all due respect, your "opinion" is less important to me than
>> the material reasons that you advance to justify it.  I just though
>> "it's gross" wasn't a sufficiently developed reason.
> "Opinion", in quotes? really?  Thanks a lot, that's a great way to
> enhance my motivation to continue being a co-maintainer for this
> project.

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).

And I take the point that you don't like to be pressed and will not
insist beyond this point (except for a reply to your recent arguments,
of course).

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

> 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.  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".

The only quite far-fetched scenario I could think up is if some code out
there actually relies on the fact that emacs-lisp-mode is derived
_directly_ from prog-mode.

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.

> 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.  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.

João