João Távora <joaotavora@gmail.com> 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.