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, 15 Jul 2022 11:03:35 +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> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000b8d7bc05e3d51d09" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9001"; 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 15 12:03:35 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 1oCIAY-00028Q-Cb for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 15 Jul 2022 12:03:34 +0200 Original-Received: from localhost ([::1]:60400 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oCIAW-0007kN-VU for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 15 Jul 2022 06:03:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58590) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oCIAA-0007bC-7t for bug-gnu-emacs@gnu.org; Fri, 15 Jul 2022 06:03:10 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41722) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oCIA2-0006W3-Lj for bug-gnu-emacs@gnu.org; Fri, 15 Jul 2022 06:03:09 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oCIA2-0003F5-H6 for bug-gnu-emacs@gnu.org; Fri, 15 Jul 2022 06:03: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: Fri, 15 Jul 2022 10:03: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.165787935912432 (code B ref 48452); Fri, 15 Jul 2022 10:03:02 +0000 Original-Received: (at 48452) by debbugs.gnu.org; 15 Jul 2022 10:02:39 +0000 Original-Received: from localhost ([127.0.0.1]:39481 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oCI9f-0003ER-1v for submit@debbugs.gnu.org; Fri, 15 Jul 2022 06:02:39 -0400 Original-Received: from mail-oi1-f169.google.com ([209.85.167.169]:35465) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oCI9b-0003EB-JU for 48452@debbugs.gnu.org; Fri, 15 Jul 2022 06:02:38 -0400 Original-Received: by mail-oi1-f169.google.com with SMTP id r82so5541648oig.2 for <48452@debbugs.gnu.org>; Fri, 15 Jul 2022 03:02:35 -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=+kmNSKgzwPQjsDsv9kxENg9FWV8GDYRAQw6n1V8EJkM=; b=pKd2WE1dNUdIeVHqShE4RSaFRJAaT4d9KSH1tx0o7db3M6coZ1aSTdsOu2a59EEy0Z 70aCYSJo58i4qYT0o9VM9a3d7flEAXmfsaFx3+CveTL601cT7Rt4QLBGhuy/QIeF9Cow U6fld5r28JmjFNRoaXCRLUVxwqvgpfii+pFBQkCgt5zehIludBv7gLdM/5Kh1sF2y3Ki lOVNI2fnwIqW090B8/KqywV4BKWpRZFzW5G0h2zYDe2zv8uG7WHD6kgpXgTiuf4UDyYK RZCh4d2c34xLa06mb4v1X+HVpW/RTl141xM50YS0Rb3XLmnxvJEODnYP2SRbzyasOnqE 2mGQ== 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=+kmNSKgzwPQjsDsv9kxENg9FWV8GDYRAQw6n1V8EJkM=; b=XIZM5LyVkkY8P9ooSQbjGG5OAK0r9Ah3zv1BgrXVtHwrWn6dSZAC26MnFzHpn/HajW WLjvYPaNPlqCMtr9TdVJdRIL+9ww75zq1JtnqDWqwYVESeXR7emqUQFaHuRmgDNR05IM dmMR2SNLuklpLRa2Je28YKs6I+lnJnIfVxbGqESO73NV2IhtQwfV83LVSq7m/vIcWpNW ObIu+IQ2WDdZhbD2Gepcg6V9q3JDiMqaFtJCCxKdtme4FiDMeyC+M5TfiQBxetM/BijS xnE+08ZUTxzpN1oubTNQDgx1ntPUKadibPKCjlgREArBUkFBqFkUNYkW6cf+GbWrGhVd YxrQ== X-Gm-Message-State: AJIora/k1n4KQae8zPklFhrQw4iuxbXMqcMWOJp2bZg53JXAbh1GpLix 5sa87J4v3/oPn8xc/wKiilcN4Go10UBsOMRHGcyuZFAo8q8= X-Google-Smtp-Source: AGRyM1v4OXHqSXfGiKPJf8CXl784NHPO/y0OVK66+/xA1Y2leQmYT/vBL+ke+H8NAds+95WFHQkVQUR7+Uxk7Q/VUwo= X-Received: by 2002:aca:210e:0:b0:33a:3557:b224 with SMTP id 14-20020aca210e000000b0033a3557b224mr5157445oiz.209.1657879349743; Fri, 15 Jul 2022 03:02:29 -0700 (PDT) In-Reply-To: <87r12mogh9.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:237064 Archived-At: --000000000000b8d7bc05e3d51d09 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 15, 2022 at 10:47 AM Lars Ingebrigtsen wrote: > Jo=C3=A3o T=C3=A1vora 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 gav= e and/or putting that in the repo's dir-locals.el suffices. Jo=C3=A3o --000000000000b8d7bc05e3d51d09 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jul 15, 2022 at 10:47 AM Lars Ing= ebrigtsen <larsi@gnus.org> wrot= e:
Jo=C3=A3o T=C3=A1vora <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'?=C2=A0 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 i= t'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 envi= ronment,
very often the Emacs -Q environment where Makefiles usua= lly byte-compile
files.

It'= s really not very useful, in my opinion and experience, if the same elisp f= ile
in the same project visited from two different Emacs ses= sions shows different
sets of errors.

And there's also the question of security.=C2=A0 Flymake runs co= mpile-time
code every time by simply modifying the buffer.= =C2=A0 So being conservative
here is also a good idea because of = that.

Once I was working on a macro and I temporar= ily put a `delete-file` in there,
which I later deleted because I= had given it the wrong argument.
The macro was being expande= d at top level. The file was gone.

Anyway, bec= ause the directories under ~/.emacs.d/elpa are somewhat special
a= nd/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 shou= ld be the default, or merely an option to
the flymake-elisp-= byte-compile backend.=C2=A0 I think the second is safer.
BTW, this is very similar to other "on-the-fly" back= ends like C/C++ checkers
which add some "system" t= hings to the include path considered when checking,
but still nee= d to know about the user's include paths.=C2=A0 Google
c= ompilation_commands.json or "compilation database".=C2=A0 These a= re 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 t= hat in the repo's dir-locals.el suffices.


Jo=C3=A3o
--000000000000b8d7bc05e3d51d09--