bug#55811: 29.0.50; No flymake diagnostics for no-byte-compile files

["João Távora" <joaotavora@gmail.com>]

Hi Stefan,

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> That's a slightly different case from mine: the `no-byte-compile` is
> often used either because the user really only ever wants to load the
> `.el` or because the compilation is known to fail (e.g. because it
> requires macros defined in a package that's not marked as a strict
> dependency, very common in tests).

By this you mean that the provider of such macros is not `require`d?
Then I don't understand what Flymake's byte-compilation backend could do
about this either...  As far as I understand it would just red-underline
all the unknown macro-using forms, their bodies wouldn't be checked.  Is
this what you want?  To check the rest of the file regardless?

Of course you know this -- but just to clarify -- the byte-compilation
backend works by launching a Emacs -Q which is asked to byte-compile
only a file containing the current buffer's contents.  During that
byte-compilation nothing more is loaded apart from what is preloaded or
explicitly loaded by the file at compile-time (via require or
eval-when/and-compile stuff).

A related issue is that when there _is_ an explicit require, then the
load-path support is pretty poor: only the current directory is added to
it.  If the `require`'d file lives somewhere else, there's no way to
hint that to the byte-comp backend, with a particular load-path.

Anyway, maybe you could give small example of such a file containing
such a cookie where you think Flymake's "I refuse to lint this" behavior
could be improved.

João