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