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

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

[-- Attachment #1: Type: text/plain, Size: 2565 bytes --]

On Thu, Oct 17, 2019, 20:21 Eli Zaretskii <eliz@gnu.org> wrote:

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

The class can informally be described by "functionality not applicable and
thus harmful to the manipulation of non-code lisp data files."

What misdesign is that?
>

A failure to correctly model the differences between lisp code and lisp
data. It's not a giant flaw, tho: inheritance is available and this is a
textbook example of where it should used.

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

I haven't checked, but if I had to guess, I would say it tries to invoke
the byte-compiler on the file, which doesn't make any sense, as you know.
As a result, bogus diagnostics are produced.

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

No. Simply no. We might be miscommunicating, but when a change happens in
Flymake, the new mode proposed by Stefan need not be changed. At all.

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

Exactly. Stefan's patch doesn't change anything related to Flymake and
indeed solves the problem (or as i said, the class of problems where this
one related to Flymake happens to be included). And that is why it is very
good and you should take it! Indeed it answers your very legitimate
concerns about maintenance.

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

The least bad one  has code duplication, is less maintainable is specific
to Flymake.

You are basically saying that emacs-lisp-mode should do for these
> files.
>

No. I'm saying that it does a superset of what it should do. And that the
surplus is harmful. You can see exactly what that surplus is: it's whatever
is left in emacs-lisp-mode in Stefan's patch.

João

>

[-- Attachment #2: Type: text/html, Size: 4722 bytes --]