On Fri, Jul 15, 2022 at 10:47 AM Lars Ingebrigtsen wrote: > João Távora writes: > > > I think elisp-flymake-byte-compile-load-path is relevant here. > > I think the question here was -- why doesn't that just default to > `load-path'? I'd expect the flymake environment to be similar to the > environment in my running Emacs. > When I was first coding this backend, I had that expectation too. But it's not very useful, as you normally, when developing an elisp file in a package, you want to be made aware of the potential compilation problems arising when compiling that file in a much simpler environment, very often the Emacs -Q environment where Makefiles usually byte-compile files. It's really not very useful, in my opinion and experience, if the same elisp file in the same project visited from two different Emacs sessions shows different sets of errors. And there's also the question of security. Flymake runs compile-time code every time by simply modifying the buffer. So being conservative here is also a good idea because of that. Once I was working on a macro and I temporarily put a `delete-file` in there, which I later deleted because I had given it the wrong argument. The macro was being expanded at top level. The file was gone. Anyway, because the directories under ~/.emacs.d/elpa are somewhat special and/or security-vetted it _could_ make sense to add them to the default value of the variable. This would amount to more or less the same as calling the underlying process with `-f package-initialize` I think. But I'm still not sure this should be the default, or merely an option to the flymake-elisp-byte-compile backend. I think the second is safer. BTW, this is very similar to other "on-the-fly" backends like C/C++ checkers which add some "system" things to the include path considered when checking, but still need to know about the user's include paths. Google compilation_commands.json or "compilation database". These are normally files checked into the repository, or very easy to generate. Of course in Elisp, we probably don't need such complexity: merely adjusting the variable I gave and/or putting that in the repo's dir-locals.el suffices. João