From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#48452: 28.0.50; flymake for elisp does not respect `load-path` Date: Sat, 23 Jul 2022 18:45:04 +0100 Message-ID: <87h737n2ov.fsf@gmail.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4354"; 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: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jul 23 19:46:21 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 1oFJCm-0000wz-FK for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 23 Jul 2022 19:46:20 +0200 Original-Received: from localhost ([::1]:43736 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oFJCj-0004Ke-0F for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 23 Jul 2022 13:46:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44624) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oFJAY-0002M5-Ue for bug-gnu-emacs@gnu.org; Sat, 23 Jul 2022 13:44:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56481) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oFJAY-0002FE-MO for bug-gnu-emacs@gnu.org; Sat, 23 Jul 2022 13:44:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oFJAY-0005bf-Ho for bug-gnu-emacs@gnu.org; Sat, 23 Jul 2022 13:44:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 23 Jul 2022 17:44: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.165859823721531 (code B ref 48452); Sat, 23 Jul 2022 17:44:02 +0000 Original-Received: (at 48452) by debbugs.gnu.org; 23 Jul 2022 17:43:57 +0000 Original-Received: from localhost ([127.0.0.1]:46230 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oFJAT-0005bD-Ee for submit@debbugs.gnu.org; Sat, 23 Jul 2022 13:43:57 -0400 Original-Received: from mail-wr1-f51.google.com ([209.85.221.51]:40469) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oFJAR-0005ay-K6 for 48452@debbugs.gnu.org; Sat, 23 Jul 2022 13:43:56 -0400 Original-Received: by mail-wr1-f51.google.com with SMTP id m17so10163417wrw.7 for <48452@debbugs.gnu.org>; Sat, 23 Jul 2022 10:43:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :user-agent:mime-version:content-transfer-encoding; bh=uvG/avzmWQCXAmidziG/IaGp1QrYP/H1eSCV2chQ3ec=; b=fr8a9ANph/KfwWk9UQzK3jkz/TLmN8M3TFKD3TLEOpkcXBYX/hF/AIA4xa7XNU++cU +sAtwL8pAsa8Ei1+b8PBl2qp8sCguroioVm0eNQgqctkj+OOoD4XI7gLdJC5wMoq6FkY 6NpkkR32f0VzpXS9qYCk0N3qNlHhb5dOFWbNP7gFMQwXFRNk0qndGBUDiDfeUmAE/W3C T9Ei46RvWZeRHHcOCEocuE51FRcuyUyMwm6dCHZXnVmKMgn4ajGe2OAhFpYYgX9qfBxQ eWEN0oU1UtynMCmbDprUdMX8CAZ0tXvWRb0+kAXCH17IRD4Awfc9uD0v+2ePV6iFB1Nf nd8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:user-agent:mime-version:content-transfer-encoding; bh=uvG/avzmWQCXAmidziG/IaGp1QrYP/H1eSCV2chQ3ec=; b=N5lcbHSW+jihy5qSI3LVCeABLySoMcImeYcJtl4S7xFMlQpWZQQdvMJg2SPnfGzTFw GE94KthBH/Jv0cq9P8GjoAoscISwnLwBT352yAHRpUhpHJ9Qv4Zqxg3iY4aKMbgKIXkm RZG8rBdH/epVHdVitoEONETOl1r3Mkok8GOoY+iKFHnPJqisdtMktMV/xXSzwYMOPgxG EIWvoaLgdW51WBgbT2Bl/QZVt+m1UUKpOfiGmsgjsIWruk3CHsGlhEdwFp44xzgUW8V4 lQhFE31IOjyGxVrAHtNZ1APxuBQMDb/u5vo5L4dqCsdBz2CGBO0yelaJuUwqyNnunQ2H CKaQ== X-Gm-Message-State: AJIora8OeNPaSuWpOV/gbOz+nuf39Rsb+CZOIub2aJ0vo9oGBxI7s1tt ow3REWx2O5aox0tr422sAlvz2bDrEs8= X-Google-Smtp-Source: AGRyM1ua10izdEsDWwnAbF3sN42EqkyN5R13l4wqLx7XJ94EOI2AXCU0Foxdbdd97PFp9uPBeuD4zg== X-Received: by 2002:adf:f90f:0:b0:21e:7e3d:6af6 with SMTP id b15-20020adff90f000000b0021e7e3d6af6mr1490672wrr.183.1658598229140; Sat, 23 Jul 2022 10:43:49 -0700 (PDT) Original-Received: from krug ([62.28.191.198]) by smtp.gmail.com with ESMTPSA id f5-20020adff445000000b0021e5f32ade7sm4179211wrp.68.2022.07.23.10.43.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 23 Jul 2022 10:43:48 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Sat, 23 Jul 2022 10:26:45 -0400") 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:237781 Archived-At: Stefan Monnier writes: >> 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 presume those relevant things are setup by package-initialize, right? My proposed patch uses that. >> 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. I don't dispute that, but in my experience (and as far as I can see) it is _not_ functionally harmful to have ./ in the elisp-flymake-byte-compile-load-path for the use case that I described: developing package.el packages that can be distributed and installed through a number of ways. But is it potentially "dangerous/disastrous"? I don't think so either, but I haven't a clear picture of the disaster scenario. Lars mentioned "editing files in /tmp". Maybe Lars is worried about some user e.g. having /tmp/bad.el and opening some /tmp/good.el and slowly typing in (require 'badminton) By the time (require 'bad) is in the buffer, disaster strikes. But this disaster could just as well happen by simply visiting /tmp/bad.el to see what's in it. Except that malicious files don't advertise themselves like that in their file names... Or maybe -- again, I'm just guessing -- the danger is that that bad.el is disguised under /tmp/pcase.el and /tmp/good.el has a perfectly legitimate. (require 'pcase) Simply visitng /tmp/good.el with Flymake on would lead to disaster. If that's the case, it's as easy as applying this patch diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el index 0c4a9bfdbe..01c0679c76 100644 --- a/lisp/progmodes/elisp-mode.el +++ b/lisp/progmodes/elisp-mode.el @@ -2144,7 +2144,7 @@ elisp-flymake-byte-compile "-Q" "--batch" ;; "--eval" "(setq load-prefer-newer t)" ; for testing - ,@(mapcan (lambda (path) (list "-L" path)) + ,@(mapcan (lambda (path) (list "-L" (format ":%s" path)= )) elisp-flymake-byte-compile-load-path) "-f" "elisp-flymake--batch-compile-for-flymake" ,temp-file) Jo=C3=A3o