From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#48452: 28.0.50; flymake for elisp does not respect `load-path` Date: Sat, 23 Jul 2022 10:26:45 -0400 Message-ID: References: <8735unafob.fsf@gmail.com> <877d4hs084.fsf@gnus.org> <87v8s1untg.fsf@gmail.com> <874jzlp12v.fsf@gnus.org> <87wnchc75r.fsf@gmail.com> <87ilnzaa49.fsf@gnus.org> <87cze7780j.fsf@gmail.com> <87r12mogh9.fsf@gnus.org> <87fsj1tlgn.fsf@gnus.org> <87sfmy1b95.fsf@gmail.com> <87r12d9b8f.fsf@gnus.org> <87k08497in.fsf@gnus.org> <87wnc474xt.fsf@gnus.org> <87y1wkmba4.fsf@gmail.com> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27762"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Max Brieiev , Lars Ingebrigtsen , 48452@debbugs.gnu.org To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jul 23 16:27:11 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oFG62-0006yU-Q8 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 23 Jul 2022 16:27:10 +0200 Original-Received: from localhost ([::1]:52952 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oFG61-0005Tr-Sf for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 23 Jul 2022 10:27:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41950) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oFG5u-0005Rr-Nn for bug-gnu-emacs@gnu.org; Sat, 23 Jul 2022 10:27:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56228) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oFG5u-0002YO-FZ for bug-gnu-emacs@gnu.org; Sat, 23 Jul 2022 10:27:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oFG5u-00063T-7r for bug-gnu-emacs@gnu.org; Sat, 23 Jul 2022 10:27:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 23 Jul 2022 14:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48452 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 48452-submit@debbugs.gnu.org id=B48452.165858641923264 (code B ref 48452); Sat, 23 Jul 2022 14:27:02 +0000 Original-Received: (at 48452) by debbugs.gnu.org; 23 Jul 2022 14:26:59 +0000 Original-Received: from localhost ([127.0.0.1]:45977 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oFG5q-00063A-Jt for submit@debbugs.gnu.org; Sat, 23 Jul 2022 10:26:58 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:20838) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oFG5m-00062m-6f for 48452@debbugs.gnu.org; Sat, 23 Jul 2022 10:26:57 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3C74A10027D; Sat, 23 Jul 2022 10:26:48 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 83A9F100120; Sat, 23 Jul 2022 10:26:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1658586406; bh=Pzy6VUgR+BYRol2Me0iLLIXqioxCU9m6mrgLMd4JM+M=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=UNxp0VXGYl7Veh+DDZ2Zj8YOAcy5OIonqOrKjN3cb+cOL7gaR38YAfODf0bqDEz6e 8RkEthJYptuZVvbe0LbNbmoYb3DBYEZKaWrNP0zSo/DuSzMei2EKw/78NI7vlLflLJ jRPn+66VKy44Oud+nvF091ggaK6wPKaUyHGLHCgHfHPyfmbJoLc8G0ZTFnnHxublEL Uc2QHLYr8g6bofhGfs00+Iqp/f7pYjQlOFcrWEeXBFB/Sr0UY6RpvcPD4Ze6TNwmek HmT0MPDhf42Jt95f77LnjYsS7KbNAxcHBfJLJagu9WPc1tMrE1eWsrO5OQRDn7EvTY gFvqWqPQFsM5Q== Original-Received: from pastel (unknown [45.72.195.111]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4CEBD12025D; Sat, 23 Jul 2022 10:26:46 -0400 (EDT) In-Reply-To: <87y1wkmba4.fsf@gmail.com> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Sat, 23 Jul 2022 10:24:51 +0100") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:237747 Archived-At: > 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 ;; =A1FIXME! 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 th= is ;; `pcase.el' to hide the *real* `pcase.el'. So we workaround this p= roblem ;; here by removing the offending element from `load-path'. Yuck! ;; ;; We should probably change GNUmakefile instead so it doesn't forcef= ully ;; add the directory to `load-path', e.g. make this dependent on the ;; presence of special file like `.dont-add-to-load-path'.=20 (when load-file-name (setq load-path (remove (file-name-directory load-file-name) load-p= ath)))) 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