[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: João Távora
Subject: Re: Add a separate mode for .dir-locals.el
Date: Thu, 17 Oct 2019 22:35:33 +0100

On Thu, Oct 17, 2019, 20:21 Eli Zaretskii <address@hidden> 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

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

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]