On Sat, Oct 19, 2019 at 12:56 PM Eli Zaretskii <
address@hidden> wrote:
> I thought it was just a guess, and I wanted us to be sure. Are we
> sure the problem is triggered by an attempt to invoke the byte
> compiler on the file?
It was a guess because another Flymake backend, such as checkdoc, could
have been producing similar bogus data. I also didn't try Flycheck.
Anyway the guess is confirmed for Flymake, though apparently for
Flycheck the problem also extends to its checkdoc checker.
Here, "checker" ~== "backend" BTW.
> > > Creating a major mode for this issue is like shooting sparrows with
> > > cannons. Why not extend emacs-lisp-mode to DTRT with
> > > data-that-doesn't-make-sense-as-code instead?
> > That is _exactly_ what Clément proposed in his original patch.
> My understanding is that Clément proposed a new major mode.
Yes, he did. By "extension" (to a major mode) I understood
"derivation", as in basic OO's "Dog extends Mammal extends Animal", so a
new major mode. Now I see you didn't mean that.
If you mean just putting if-guards in emacs-lisp-mode, then I would't
call it an "extension", really. But never mind nomenclature, the point
is that, it (1) doesn't avoid Clément's need to put the very same
if-guards in his Flycheck code, (2) isn't reusable to work for other
file types (3) just doesn't work for other stuff that people put in
emacs-lisp-mode-hook, for which we have no possible way to if-guard
against. It is an anti-pattern, precisely the one that simple
inheritance is designed to avoid.
João