From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Recursive Fload and eval-after-load forms. (See bug #43116.) Date: Mon, 31 Aug 2020 19:42:38 +0000 Message-ID: <20200831194238.GC4176@ACM> References: <20200831184526.GB4176@ACM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16578"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, Nonax To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 31 21:43:29 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 1kCpiD-0004Ej-CJ for ged-emacs-devel@m.gmane-mx.org; Mon, 31 Aug 2020 21:43:29 +0200 Original-Received: from localhost ([::1]:44744 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kCpiC-0003WJ-Ea for ged-emacs-devel@m.gmane-mx.org; Mon, 31 Aug 2020 15:43:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54934) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kCphU-00031c-W5 for emacs-devel@gnu.org; Mon, 31 Aug 2020 15:42:45 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:48559 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1kCphS-0006VB-SB for emacs-devel@gnu.org; Mon, 31 Aug 2020 15:42:44 -0400 Original-Received: (qmail 73384 invoked by uid 3782); 31 Aug 2020 19:42:40 -0000 Original-Received: from acm.muc.de (p4fe15b2d.dip0.t-ipconnect.de [79.225.91.45]) by localhost.muc.de (tmda-ofmipd) with ESMTP; Mon, 31 Aug 2020 21:42:39 +0200 Original-Received: (qmail 17710 invoked by uid 1000); 31 Aug 2020 19:42:38 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/31 14:45:28 X-ACL-Warn: Detected OS = FreeBSD 9.x or newer [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_MSPIKE_BL=0.001, RCVD_IN_MSPIKE_L3=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:254456 Archived-At: Hello, Stefan. Thanks for such a rapid reply! On Mon, Aug 31, 2020 at 14:54:54 -0400, Stefan Monnier wrote: > > The cause of the double evaluation is a custom-menu-create form in > > fortran.el, which causes a recursive evaluation of (load "fortran"). > That sounds like a misfeature we should address. Yes. The idea of a recursive load left me a bit shocked. Fload bails out with an error if the nesting of files it's loading has a file more than three times in the stack. > > 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. > I think it would only hide the problem and would make the specification > of `eval-after-load` needlessly more complex. I suppose it would. > Recursive loading of a file should be rare and should always be > considered as a bug/misfeature in itself, so I don't think we should > take extra steps to try and better support it. Maybe instead we could modify custom-menu-create such that it will only require its target file if that file isn't currently being loaded. If it is currently being loaded, then we only include the customisable variables that have already been defined. This shouldn't be too much of a hardship, since custom variables tend to be defined near the start of a .el file, and the higher level functions which create the custom menu tend to be nearer the end of the file. What do you think? > Stefan -- Alan Mackenzie (Nuremberg, Germany).