GNU bug report logs - #48452
28.0.50; flymake for elisp does not respect `load-path`

Previous Next

Full log

Message #64 received at 48452 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: João Távora <joaotavora <at> gmail.com>
Cc: Max Brieiev <max.brieiev <at> gmail.com>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 48452 <at> debbugs.gnu.org
Subject: Re: bug#48452: 28.0.50; flymake for elisp does not respect `load-path`
Date: Sat, 23 Jul 2022 10:26:45 -0400

> At some point in the past, Stefan was working on a "sandboxed" Emacs
> that could, in theory, pave the way for automatically enabled Elisp
> Flymake, but I haven't heard of that effort lately.

I need to get back to that indeed :-)

>> It seems to me that there's two useful values for load-path in the
>> Flymake backend: Either just the standard load-path (so that you
>> actually get the same results as when doing a batch byte-compile) or the
>> current running load-path (so that you get the same results as when you
>> `require' the file from your .emacs, say).  Altering the load-path to
>> also include the ELPA directories doesn't really help much, because
>> people have all kinds of code that's not in ELPA (but is in their
>> load-path).

AFAIC, it's not just `load-path`: the set of autoloaded functions (and
a few other similar things) is also relevant.

> I think we have to ask ourselves: what is Flymake used for?  The most
> useful answers will come from the people who actually use it, though
> potential uses are also interesting.

I don't think we can hope to make flymake-elisp work correctly in all
existing cases, because there are conflicting requirements there.

So, we should take it for granted that some use-cases will be considered
as "unsupported", and the important thing is to figure out what behavior
to provide such that all(?) use-cases can be adapted (and such that the
behavior is sane enough to be described, understandable, and
predictable).

> Having './' in the default load-path for elisp-flymake-byte-compile is
> fundamental for the accuracy of this prediction.  Why?  Because the
> clients of my packages -- regardless if they use package.el,
> straight.el, etc or just simply using a git checkout -- will always have
> the the files I have in some directory in some other directory in their
> machines, and _that_ directory will be in the load-path.

BTW, while the GNUmakefile of `elpa-admin` also adds `.` to the
`load-path`, there are cases where this is harmful.
E.g. the "pcase benchmark" in `elisp-benchmarks` used to be in the file
.../benchmarks/pcase.el and it (of course) required Emacs to load
`pcase.el` (the other one).

This required the hideous workaround:

    (eval-and-compile
      ;; ¡FIXME!  The GNUmakefile of elpa.git uses:
      ;;
      ;;    ... -L $(dir $@) -f batch-byte-compile $<
      ;;
      ;; to compile each file.  This is handy for some cases such as files in
      ;; `contrib' subdirectories but for this `pcase.el' file it causes this
      ;; `pcase.el' to hide the *real* `pcase.el'.  So we workaround this problem
      ;; here by removing the offending element from `load-path'.  Yuck!
      ;;
      ;; We should probably change GNUmakefile instead so it doesn't forcefully
      ;; add the directory to `load-path', e.g. make this dependent on the
      ;; presence of special file like `.dont-add-to-load-path'. 
      (when load-file-name
        (setq load-path (remove (file-name-directory load-file-name) load-path))))

We have several files in `lisp` whose directory is not in `load-path`
(most of them under `lisp/cedet`).

But, note that I decided to use the above hack (later replaced by
the simpler solution of renaming the file to `elb-pcase.el`) in
preference to changing the GNUmakefile not to add `.` to `load-path`.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.