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#62767: 29.0.90; [PATCH] *lisp/emacs-lisp/package.el: set variables after info package Date: Mon, 17 Apr 2023 12:30:19 -0400 Message-ID: References: <1181651021.466162.1581309285621.ref@mail.yahoo.com> <1181651021.466162.1581309285621@mail.yahoo.com> <87sfd2ns6d.fsf@posteo.net> <833551ecb2.fsf@gnu.org> <87ttxh4e9i.fsf@posteo.net> <87bkjmiqtz.fsf@posteo.net> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11441"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 62767@debbugs.gnu.org, lin Sun , Eli Zaretskii To: Philip Kaludercic Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 17 18:31:14 2023 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 1poRl3-0002mb-Rt for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 17 Apr 2023 18:31:14 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1poRkt-0007od-AF; Mon, 17 Apr 2023 12:31:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1poRks-0007oU-Pb for bug-gnu-emacs@gnu.org; Mon, 17 Apr 2023 12:31:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1poRks-0007wi-Cs for bug-gnu-emacs@gnu.org; Mon, 17 Apr 2023 12:31:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1poRkr-0003HD-Pc for bug-gnu-emacs@gnu.org; Mon, 17 Apr 2023 12:31:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 17 Apr 2023 16:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62767 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 62767-submit@debbugs.gnu.org id=B62767.168174903012554 (code B ref 62767); Mon, 17 Apr 2023 16:31:01 +0000 Original-Received: (at 62767) by debbugs.gnu.org; 17 Apr 2023 16:30:30 +0000 Original-Received: from localhost ([127.0.0.1]:55918 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1poRkL-0003GQ-Vi for submit@debbugs.gnu.org; Mon, 17 Apr 2023 12:30:30 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:47374) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1poRkJ-0003G9-Jg for 62767@debbugs.gnu.org; Mon, 17 Apr 2023 12:30:28 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id E692F1000BF; Mon, 17 Apr 2023 12:30:21 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7AFC61000A3; Mon, 17 Apr 2023 12:30:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1681749020; bh=8qxFY6FQ0/M6AnWhjof28nGz3BZvMROZzZy+GFegSG0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=k7PGDm2S1luhPrppqEWdXS9hc1mjDXjzVpRK7vYYla8rLCdcHNqbmwe+nCx3aMkrT QYtqdbs8KmQJZ8ODStxZFJsitNKp6icGqnXZ1ilLtVkW7nfjYdT3B7S/UKPjPWq3xu teBsLMhXotXraZmtw5DyddWgff3kB+TefNYUdl8ifphdG3AvCD+wR/OnwNtDEH+B+y Z26dUV/PhDpoBC1478DZtqhY6blh5gR8Gwi1LvA6NjQJ+GTRyvsgzguFe8JAFiksij eWIh0Q9PyZAhniMRgw9iKQu29vcyoiusKNpMrpSdA9Da65quW6Di7p8ADdBLGYTGcD bxFCKbDbMMtMw== Original-Received: from alfajor (unknown [45.44.229.252]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 526951203D4; Mon, 17 Apr 2023 12:30:20 -0400 (EDT) In-Reply-To: <87bkjmiqtz.fsf@posteo.net> (Philip Kaludercic's message of "Mon, 17 Apr 2023 13:24:56 +0000") 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:260189 Archived-At: > OK, then we still have to find out if these changes are safe. As > mentioned before, I hesitate in using `with-eval-after-load', probably > because of the complicated history of `eval-after-load'. I suppose that > Stefan might know more (as it is due to him that I am careful here), so > I have added him to the thread. The problem with eval-after-load is not the history but the fact that it has various corner-case caveats. (with-eval-after-load "compile" ...) for example makes it unclear exactly when it should be executed, e.g.: (load "compile") => yes clearly. (load "compile.el") => probably, yes. (load "srecode/compile.el") => probably not. (load "/foo/bar/lisp/compile.el") => hmm... yeah, I think so. (load "/foo/bar/lisp/srecode/compile.el") => hmm... nah, maybe not. The next game is to try and guess what the code does, to see when it matches expectations. The use (with-eval-after-load 'info ...) is much better in this respect because it's not linked to the file name but to the feature name, which is precise. But there's still the issue of exactly when this is executed. Should it be executed just the next time the file is loaded (usually what's wanted), or every other time after that as well (what actually happens)? Also the implementation for the good case where we provide a feature name rather than a file name is a bit roundabout/fiddly. This is an internal problem, so any bug there can be fixed, thus it's probably not a good reason not to use it, but it still makes me prefer to avoid it :-) I wish there was an easier way to add to `Info-directory-list`. That variable is set in a fairly delicate manner, so I think Eli would be better placed to come up with a better long term solution. Maybe we should just add a (preloaded) `Info-extra-directory-list`? In the mean time, Lin Sun's patch is probably "as good as it gets" if you want to load `info.el` lazily (which I obviously didn't bother to do when I wrote that code :-) Stefan