all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Nonax <nonax@posteo.net>
To: Alan Mackenzie <acm@muc.de>, Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 43116@debbugs.gnu.org, emacs-devel@gnu.org
Subject: Re: Recursive Fload and eval-after-load forms. (See bug #43116.)
Date: Mon, 31 Aug 2020 22:27:36 +0200	[thread overview]
Message-ID: <2edcfc59-59b4-4609-93d5-aba610e2c541@posteo.net> (raw)
In-Reply-To: <20200831184526.GB4176@ACM>

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 <mode>-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.
> 



  parent reply	other threads:[~2020-08-31 20:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-31 18:45 Recursive Fload and eval-after-load forms. (See bug #43116.) Alan Mackenzie
2020-08-31 18:54 ` Stefan Monnier
2020-08-31 19:42   ` Alan Mackenzie
2020-09-01  3:18     ` Stefan Monnier
2020-09-01 19:42       ` Alan Mackenzie
2020-09-01 23:42         ` Stefan Monnier
2020-08-31 20:27 ` Nonax [this message]
2020-08-31 20:27 ` bug#43116: " Nonax

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2edcfc59-59b4-4609-93d5-aba610e2c541@posteo.net \
    --to=nonax@posteo.net \
    --cc=43116@debbugs.gnu.org \
    --cc=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.