On Thu, Oct 17, 2019 at 2:16 PM Eli Zaretskii <
address@hidden> wrote:
>
> > From: João Távora <
address@hidden>
> > Date: Thu, 17 Oct 2019 13:21:37 +0100
> > Cc:
address@hidden> >
> > 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.