From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Nonax Newsgroups: gmane.emacs.bugs Subject: bug#43116: Recursive Fload and eval-after-load forms. (See bug #43116.) Date: Mon, 31 Aug 2020 22:27:36 +0200 Message-ID: <2edcfc59-59b4-4609-93d5-aba610e2c541__41080.5155102693$1598934620$gmane$org@posteo.net> References: <20200831184526.GB4176@ACM> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30968"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 Cc: 43116@debbugs.gnu.org, emacs-devel@gnu.org To: Alan Mackenzie , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Sep 01 06:30:16 2020 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 1kCxvz-0007yr-J0 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 01 Sep 2020 06:30:15 +0200 Original-Received: from localhost ([::1]:36434 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kCxvy-0006Za-KA for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 01 Sep 2020 00:30:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54706) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kCxvo-0006SL-UW for bug-gnu-emacs@gnu.org; Tue, 01 Sep 2020 00:30:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42959) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kCxvo-0004xE-KY for bug-gnu-emacs@gnu.org; Tue, 01 Sep 2020 00:30:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kCxvo-0008EG-Ez for bug-gnu-emacs@gnu.org; Tue, 01 Sep 2020 00:30:04 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Nonax Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Sep 2020 04:30:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43116 X-GNU-PR-Package: emacs Original-Received: via spool by 43116-submit@debbugs.gnu.org id=B43116.159893455831485 (code B ref 43116); Tue, 01 Sep 2020 04:30:04 +0000 Original-Received: (at 43116) by debbugs.gnu.org; 1 Sep 2020 04:29:18 +0000 Original-Received: from localhost ([127.0.0.1]:54503 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kCxv3-0008Bl-VI for submit@debbugs.gnu.org; Tue, 01 Sep 2020 00:29:18 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:41717) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kCqP2-0002ab-Pq for 43116@debbugs.gnu.org; Mon, 31 Aug 2020 16:27:45 -0400 Original-Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 91B382400FE for <43116@debbugs.gnu.org>; Mon, 31 Aug 2020 22:27:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1598905658; bh=vBlV6RxDJ2/uIhlGP8cy93xRJnlHK33Mb9m7UZS5EIw=; h=Subject:To:Cc:From:Autocrypt:Date:From; b=iEBL9Wi30tinW5q8JVzGyPtW5vfx+cjGsTLGbA04CrBwSEjlwAKoOmcUNe0hAs+jg kulxOKhF1NiO5fHBSAk/KMiiHZBmnd+as2FLP7RcuYExbNGzjULDvJ3pg5BkWS8V0a djjUvEyo1JEpLDrUaA8ufUFNokKNbK44yaJoaXk0YhIhfo0VRZe72FAM5Xu/0kvzM7 U3NTamc+56ri7/dTIpgXd5X6a+bsewYe4Ov6n8qZ6ZLBnKwMqjeBL5hv4Uu8Y22RHA EzgIyo1a2NgXIILQSY8J0nJq2R2ZraLDMW7kCpzpNNZVO3jCerU93ZCkUiqA67CUci 4FePBVumZ1/Zg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4BgMFj2zFGz9rxj; Mon, 31 Aug 2020 22:27:37 +0200 (CEST) Autocrypt: addr=nonax@posteo.net; prefer-encrypt=mutual; keydata= mQENBFuJVeEBCADAhVktqEkcI1afVu75HQXC0CBQA7O77a9MEFk0AHCS/3F69GBZ5uhoLFwL sidR383IhosUMhFK60k+lF5y+FqzrnCcgyos+aNpmpFxoAF1cyonZyyoqyqcKxwtwaBAs67c 6H9obPPBkP9kfAt40JEMNUXodcDiqJkZPtaS07yT+Ydud8JROX9pQpCUBikTZRsr0POU8Xi6 BBsNL3wmHF9OjRV8hAykmzWhUOJCdcgaWAqMAGfDdVEK/QLGN/WukIeCMykMpB3ft8rCtW7Y SfKegRkTMDjIewmHcAO1vxNKUylm3WMe/+VG0f4fHqdb/d0U7E1f8SEL+gbwDBoCW9V7ABEB AAG0GE5vbmF4IDxub25heEBwb3N0ZW8ubmV0PokBTgQTAQgAOBYhBIHKsVNWX9DYD0HK/jJY uORdjV2iBQJbiVXhAhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEDJYuORdjV2iGWAH /2lkSJIxllLP5Y6+JbQXSH7yjxeRCP7JrhAaNCR7NE0zerWh77Y/YnqWWPdbd/GnLL7C6Pqt qTzK/Wrh8jjbI9sPq6eITMoeLr11KyeKBMeEnyrLFu7OQAcVelavZuPZVKwcvNhgbk0Jk2cZ zOGhxkw/msuYJm/ShE8ENzm0Y0jJmpLykVBhLWtHYuYa+XIXfvxr+2pNsf/ARR//uYfCIeTY O7yNvoV2ueEv33uQvJK2rCEdlYF3H/GmTQ0w8fTtXpD6xoxWfBwJV+nB9I/KuKrEpj7fAzxD SE820WPfkI7HBh7KcIm In-Reply-To: <20200831184526.GB4176@ACM> Content-Language: en-US X-Mailman-Approved-At: Tue, 01 Sep 2020 00:29:16 -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:186816 Archived-At: Hi all, I looked into a matter a bit and, while I don't have a solution myself, noticed something very strange. You made me aware of the fact that the fortran modes (both fortran-mode and f90) use custom-menu-create directly. The thing I find exceptional about that is that absolutely no other major mode uses this function this way, period. A quick grep shows that the only other file in the lisp/ directory using it is eudc.el, and it uses it to bind the return value to a const. So it seems that it does a rather standard thing (setting up a menu for a major mode) in a very exceptional way. I am still quite new to writing modes, but I guess one could circumvent the direct usage of custom-menu-create entirely. I've also been poking around some more to see what modules use it indirectly, to see how they deal with potential issues. The function is used by two more functions in cus-edit: custom-group-menu-create (unused in the entire lisp/ subdir) and customize-menu-create, which is used by cus-edit itself once to create Custom-mode-menu. Almost all other modules using customize-menu-create (org.el, idlwave.el, reftex.el) define a function -create-customize-menu which calls it in return. The only other module using it differently is wid-browse.el, which uses it in a similar way cus-edit itself uses it. So all in all the hierarchy of files using custom-menu-create at all is quite small, and it seems the majority does not actually call it at evaluation time, but instead have it called as a function bound to a menu point (meaning it will be called upon user input when everything important already happened). I would have to do a lot more digging to really get what custom-menu-create and family really do, but I get the feeling that fortran-mode kind of (ab)uses it in a way that was not originally anticipated. I hope this information proves somewhat useful, but my pattern recognition tells me it does. Cheers, Nonax On 31/08/2020 20:45, Alan Mackenzie wrote: > Hello, Emacs. > > In bug #43116, the OP has rightly complained that on loading > fortran.elc, his eval-after-load forms get evaluated twice. > > The cause of the double evaluation is a custom-menu-create form in > fortran.el, which causes a recursive evaluation of (load "fortran"). > The eval-after-load-forms are evaluated both for the "inner" load and > the "outer" load. > > What do people think of the following proposal: that the eval-after-load > forms should be evaluated only after the outermost load has completed? > This would be a simple amendment to the function Fload. >