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 19:09:11 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 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 18:42:32 +0100
> >> 
> >> >> Indeed, quite nice.  Eli, would you also opposed to having .dir-locals.el
> >> >> buffers use emacs-lisp-data-mode by default?  We could reuse it for
> >> >> other things other than dir-locals.
> >> >
> >> > As I said, I don't want to introduce a major mode for this tiny
> >> > problem.  It's gross.
> >> 
> >> If the problem is small but the best solution is equally small and
> >> cheap, then I think you should consider it.  Stefan's solution isn't
> >> gross at all, it's the most correct way to reuse code in this situation.
> >
> > If you are going to disregard my opinion, why did you ask for it?
> 
> You asked summarily: "someone should do some research and find out what
> it entails".  I simple gave an answer to those questions: use the small
> patch by Stefan and add some entries to auto-mode-alist, starting with

See above: you asked whether I disagreed, I said I did, and you then
replied that you still think what I disagreed to was a good idea.

> So I didn't really disregard it, I simply advanced new arguments and am
> asking you to reconsider.

Stefan's patch is not a new argument, I've seen it before replying to
your question.

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

"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, 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 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.  Just pointing
out that the files exist is not enough, as that doesn't give us enough
information for discussing such a mode.