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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> gmail.com>
Cc: 57972 <at> debbugs.gnu.org
Subject: bug#57972: 29.0.50; Autoloaded function raises (void-function org-element-cache-reset) when called within major-mode body
Date: Wed, 21 Sep 2022 15:46:13 +0300

> From: Ihor Radchenko <yantar92 <at> gmail.com>
> Cc: 57972 <at> debbugs.gnu.org
> Date: Wed, 21 Sep 2022 19:41:46 +0800
> 
> Eli Zaretskii <eliz <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.