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.devel Subject: Re: 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@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="4331"; 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: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 31 22:53:48 2020 Return-path: Envelope-to: ged-emacs-devel@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 1kCqoG-000146-2K for ged-emacs-devel@m.gmane-mx.org; Mon, 31 Aug 2020 22:53:48 +0200 Original-Received: from localhost ([::1]:46384 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kCqoF-0004Z9-4K for ged-emacs-devel@m.gmane-mx.org; Mon, 31 Aug 2020 16:53:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36028) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kCqP3-0004gv-Lt for emacs-devel@gnu.org; Mon, 31 Aug 2020 16:27:45 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]:60828) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kCqP0-0003PZ-VB for emacs-devel@gnu.org; Mon, 31 Aug 2020 16:27:45 -0400 Original-Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 92B36160062 for ; 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 Received-SPF: pass client-ip=185.67.36.65; envelope-from=nonax@posteo.net; helo=mout01.posteo.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/31 16:27:38 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -48 X-Spam_score: -4.9 X-Spam_bar: ---- X-Spam_report: (-4.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-2.13, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Mon, 31 Aug 2020 16:53:10 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:254458 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. >