[Sorry for the double mail, Eli] On Thu, Oct 17, 2019 at 2:16 PM Eli Zaretskii wrote: > > > From: João Távora > > Date: Thu, 17 Oct 2019 13:21:37 +0100 > > Cc: emacs-devel@gnu.org > > > > I don't know who proposed it, or what it meant exactly, but solving this > > in Flymake directly sounds like hack. > > Why is that a hack? Shouldn't Flymake "understand" the file it is > working on, including its syntax etc.? In fact, no. Not the new Flymake at least (and even in the old one I have my doubts). That is a job for mode-specific functions that hook onto Flymake's interfaces. They are known as Flymake backends and usually place themselves in the local value of the flymake-diagnostic-functions hook. For lisp/elisp-mode.el, there are two backends: elisp-flymake-byte-compile and elisp-flymake-checkdoc. Maybe I misunderstood your suggestion: if you meant changing _those_ two backends so that they notice they are in a dir-locals file and disable themselves, then it's less bad. But I you'd probably be adding more complexity to progmodes/elisp-mode.el than you would (to the same file, I guess) by setting up a trivial derived dir-locals-mode. And having a function that silently becomes a noop (the so-called "maybe" idiom) is slightly hacky IMO. But sometimes it's half-decent, I guess. João BTW, and on a tangent, a derived dir-locals-mode isn't the bestoption. In OO, a derivation that _removes_functionality is a no-no,it breaks "is a". A better option would be to have a base `lisp-prog-mode` and hen derive emacs-lisp-mode from it. But that is maybe impractical for other reasons and not justified by this case. On Thu, Oct 17, 2019 at 2:16 PM Eli Zaretskii wrote: > > From: João Távora > > Date: Thu, 17 Oct 2019 13:21:37 +0100 > > Cc: emacs-devel@gnu.org > > > > I don't know who proposed it, or what it meant exactly, but solving this > > in Flymake directly sounds like hack. > > Why is that a hack? Shouldn't Flymake "understand" the file it is > working on, including its syntax etc.? > -- João Távora