bug#57972: 29.0.50; Autoloaded function raises (void-function org-element-cache-reset) when called within major-mode body

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: 57972@debbugs.gnu.org
> Date: Wed, 21 Sep 2022 19:41:46 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Would it be possible to have more info about the details?  Like what
> > are org-element-cache-reset and org-element-citation-prefix-re, and
> > how do they enter the picture in the above scenario?
> 
> Let's forget about org-element-citation-prefix-re for now.
> 
> org-element-cache-reset is an autoloaded function defined inside
> org-element.el
> 
> Major mode body `org-mode' from org.el is calling
> `org-element-cache-reset' as part of Org mode loading.
> 
> org.el does not contain (require 'org-element).
> Instead, it is assumed that `org-element-cache-reset' is autoloaded by
> Emacs.

org-element-cache-reset's autoload form is in org-loaddefs.el.

The error message reported by the OP, viz.:

  File mode specification error: (void-function org-element-cache-reset)

comes from normal-mode when it calls set-auto-mode.  So something goes
wrong there, perhaps because org-element-cache-reset is called before
org.el loads org-loaddefs.el with this snippet:

  (or (eq this-command 'eval-buffer)
      (condition-case nil
          (load (concat (file-name-directory load-file-name)
                        "org-loaddefs")
                nil t nil t)
        (error
         (message "WARNING: No org-loaddefs.el file could be found from where 
org.el is loaded.")
         (sit-for 3)
         (message "You need to run \"make\" or \"make autoloads\" from Org lisp 
directory")
         (sit-for 3))))

I don't know what goes wrong, because I cannot reproduce the problem
here, if I just visit a (non-existent) foo.org.  After visiting the
file, (fboundp 'org-element-cache-reset) yields t.  So I have questions:

  . does this happen in "emacs -Q"?
  . does org-loaddefs.el exist on load-path, and is it being loaded by
    org.el?
  . could it be that user customizations somehow define file-local
    variables or directory-local variables or something else that
    attempts to use org-element-cache-reset too early?

Alternatively, a complete recipe (without referring to directories
that I definitely don't have here) to reproduce the problem could
answer all those questions succinctly and efficiently.