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: Fri, 22 Jul 2022 22:09:32 +0100 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> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000d7185d05e46b404d" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39017"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Max Brieiev , 48452@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jul 22 23:10:13 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 1oEzuX-0009um-JI for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 22 Jul 2022 23:10:13 +0200 Original-Received: from localhost ([::1]:34798 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oEzuV-0006FD-Ro for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 22 Jul 2022 17:10:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35592) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oEzuM-0006F4-Bz for bug-gnu-emacs@gnu.org; Fri, 22 Jul 2022 17:10:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52824) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oEzuM-0001KI-2g for bug-gnu-emacs@gnu.org; Fri, 22 Jul 2022 17:10:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oEzuL-0006HX-T8 for bug-gnu-emacs@gnu.org; Fri, 22 Jul 2022 17:10:01 -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: Fri, 22 Jul 2022 21:10:01 +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.165852419224121 (code B ref 48452); Fri, 22 Jul 2022 21:10:01 +0000 Original-Received: (at 48452) by debbugs.gnu.org; 22 Jul 2022 21:09:52 +0000 Original-Received: from localhost ([127.0.0.1]:42573 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oEzuB-0006Gy-RT for submit@debbugs.gnu.org; Fri, 22 Jul 2022 17:09:52 -0400 Original-Received: from mail-oa1-f51.google.com ([209.85.160.51]:44982) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oEzu9-0006Gm-L1 for 48452@debbugs.gnu.org; Fri, 22 Jul 2022 17:09:50 -0400 Original-Received: by mail-oa1-f51.google.com with SMTP id 586e51a60fabf-10bd4812c29so7713501fac.11 for <48452@debbugs.gnu.org>; Fri, 22 Jul 2022 14:09:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KxOznuQs78JeZEsBsACdMofdv+JlzddEbgjmf82UN/Y=; b=ic5pn0mDOnLBE8meX5yPkHjHXCQr+scjR5DlQLrzKljXlmkJcCzG8y8axZCCodLLrr SEBJcI5CmvwQ7CBFAYmNtMD9kdAWVInBhFR9YviE9MEsmxw6bHWK8e9iQPEB6J9kX7q9 xSgHqkWhYkh7YfMpnBLE/UwaLWrof/jGeWvRHMnhuvBRqv9DyTo4IbQc87/USNe2MDyg XR0B3XN2gtAj7Wr/5ETYgHEsGl/fe2nyyThkhKN1jVpBLayZgPgrvFxjfY9utOYMM0gd K4N27uaXvkIK6HD/6FFXg7rpq+67Y5tdMx73sWz4WGi6YsBmsAIXf7Je4dn+sP1uP0Ir gz2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KxOznuQs78JeZEsBsACdMofdv+JlzddEbgjmf82UN/Y=; b=CeOp1+Tre5Sfn3Ijl8eyUYAWMvBbMZuPoXRXq7wj9aGUZBHi2qpVa5QvzC33BPn6W/ L9zfACOA2xiox3dzMc0G6WX9NDP3G5Bqs9KvG/wWRaFrrquuFXJUQhGUscuHru+7JwEH ZQDTxv/AV88iheInJMYFNpl9NEE43ciswuKlMFc/OEzdJ+54k13zUl3+e1mpO1RBXY74 ZX9hw0zaIK8ZD+IJhmfxJr5pxOBwaKjaTzYsCuieVp4flMumomNP/9Jup+QzvWBJzYzI B4cZdjKdVK1oeZP5ie9u4EZt/N6pqoiQ66yHZNrcGyz1WkAKOtcV9covkMuuDOAIB34V IYcA== X-Gm-Message-State: AJIora8P94vMAmUBRRa3cu9uLnaN8Fis/mu+vU68NwcyDy4KeM2HHmV+ MJVJhSLbWeW7zHpJFJaqjrjQbxYph3eEENWlJ4Y= X-Google-Smtp-Source: AGRyM1u6qf0YjivVyAtyLT9PpOQ2qnV0TZm4yhL2mIw6w5InrgwyZLk/5gbfniY0U0zYds/7o9SBsz6Btc44QBcKZAU= X-Received: by 2002:a05:6870:8925:b0:fe:4638:dc01 with SMTP id i37-20020a056870892500b000fe4638dc01mr9015232oao.209.1658524184023; Fri, 22 Jul 2022 14:09:44 -0700 (PDT) In-Reply-To: <87r12d9b8f.fsf@gnus.org> 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:237650 Archived-At: --000000000000d7185d05e46b404d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 22, 2022, 20:52 Lars Ingebrigtsen wrote: > Jo=C3=A3o T=C3=A1vora writes: > > > Right. Adding anything to the load path is "dangerous". The default > > "./" is a good compromise, as it enables developing packages with > > multiple .el files that require each other in the same dir, which is a > > very common thing IME. > > I'm not sure that's a good compromise at all -- the user has surely set > up the correct load path to use, and overriding that with "./" sounds > like a recipe for disaster. > We seem to be regressing. I thought we had established that the subprocess elisp load path has no useful relation to the load path of the session. This is how one achieves consistency of diagnostics in the same file, but across sessions. I've never had disaster struck because of load paths. What disaster are you thinking about? > Here's a very minimally tested patch: > > [...] > > > +(defcustom elisp-flymake-byte-compile-use-elpa-dirs nil > > + "If non-nil, add ELPA package dirs to elisp Flymake load path." > > + :type 'boolean > > + :group 'lisp) > > I think it would make more sense to have an option to use the load path > from the current Emacs incantation also in the flymake Emacsen. > For reasons already explained, i completely disagree. My proposal would fix exactly this bug report. But you can add other options, as long as you don't break the current default. Do you use Flymake mode for elisp? I've been using it for many years, and the current default is very good. I don't use ELPA or develop against it, though, as the bug reporter fired. We could also see what Flycheck does in this regard. It also has an elisp checker. Jo=C3=A3o > --000000000000d7185d05e46b404d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jul 22, 2022, 20:52 Lars Ingebrigtsen <larsi@gnus.org> wrote:
Jo=C3=A3o T=C3=A1vora <joaotavora@gmail.com> w= rites:

> Right.=C2=A0 Adding anything to the load path is "dangerous"= .=C2=A0 The default
> "./" is a good compromise, as it enables developing packages= with
> multiple .el files that require each other in the same dir, which is a=
> very common thing IME.

I'm not sure that's a good compromise at all -- the user has surely= set
up the correct load path to use, and overriding that with "./" so= unds
like a recipe for disaster.
<= br>
We seem to be regressing. I thought we had estab= lished that the subprocess elisp load path has no useful relation to the lo= ad path of the session. This is how one achieves consistency=C2=A0 of diagn= ostics in the same file, but across sessions.

I've never had disaster struck because of load pa= ths. What disaster are you thinking about?


= For reasons already explained, i completely disagree. My proposal would fix= exactly this bug report. But you can add other options, as long as you don= 't break the current default. Do you use Flymake mode for elisp? I'= ve been using it for many years, and the current default is very good. I do= n't use ELPA or develop against it, though, as the bug reporter fired. = We could also see what Flycheck does in this regard. It also has an elisp c= hecker.

Jo=C3=A3o
<= div dir=3D"auto">
--000000000000d7185d05e46b404d--