unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#43116: Recursive Fload and eval-after-load forms. (See bug #43116.)
       [not found] <20200831184526.GB4176@ACM>
@ 2020-08-31 20:27 ` Nonax
  0 siblings, 0 replies; only message in thread
From: Nonax @ 2020-08-31 20:27 UTC (permalink / raw)
  To: Alan Mackenzie, Stefan Monnier; +Cc: 43116, emacs-devel

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





^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2020-08-31 20:27 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20200831184526.GB4176@ACM>
2020-08-31 20:27 ` bug#43116: Recursive Fload and eval-after-load forms. (See bug #43116.) Nonax

Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).