On Fri, Jul 22, 2022, 20:52 Lars Ingebrigtsen <larsi@gnus.org> wrote:

> João Távora <joaotavora@gmail.com> writes:
>
> > Right.  Adding anything to the load path is "dangerous".  The default
> > "./" is a good compromise, as it enables developing packages with
> > multiple .el files that require each other in the same dir, which is a
> > very common thing IME.
>
> I'm not sure that's a good compromise at all -- the user has surely set
> up the correct load path to use, and overriding that with "./" sounds
> like a recipe for disaster.
>

We seem to be regressing. I thought we had established that the subprocess
elisp load path has no useful relation to the load path of the session.
This is how one achieves consistency  of diagnostics in the same file, but
across sessions.

I've never had disaster struck because of load paths. What disaster are you
thinking about?

> Here's a very minimally tested patch:
>
> [...]
>
> > +(defcustom elisp-flymake-byte-compile-use-elpa-dirs nil
> > +  "If non-nil, add ELPA package dirs to elisp Flymake load path."
> > +  :type 'boolean
> > +  :group 'lisp)
>
> I think it would make more sense to have an option to use the load path
> from the current Emacs incantation also in the flymake Emacsen.
>

For reasons already explained, i completely disagree. My proposal would fix
exactly this bug report. But you can add other options, as long as you
don't break the current default. Do you use Flymake mode for elisp? I've
been using it for many years, and the current default is very good. I don't
use ELPA or develop against it, though, as the bug reporter fired. We could
also see what Flycheck does in this regard. It also has an elisp checker.

João

>