On Sat, Oct 19, 2019 at 12:56 PM Eli Zaretskii <eliz@gnu.org> 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