GNU bug report logs -
#48452
28.0.50; flymake for elisp does not respect `load-path`
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
On Fri, Jul 22, 2022, 20:52 Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
> João Távora <joaotavora <at> 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
>
[Message part 2 (text/html, inline)]
This bug report was last modified 2 years and 299 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.