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 18:49:08 +0300

> From: Ihor Radchenko <yantar92 <at> gmail.com>
> Date: Wed, 21 Sep 2022 22:51:16 +0800
> Cc: 57972 <at> debbugs.gnu.org
> 
>  And another thing: do you have any clue (or maybe more than a clue)
>  what changes in Org wrt what's on the Emacs master branch could have
>  caused this?  If you do, can you show those changes, or point to the
>  specific places in Org files where those changes can be eye-balled?
> 
> I bisected Org repo and found the first bad commit. Unfortunately, it is not very useful.
> 
> The commit changed the order function calls in org-mode. Before the commit, 
> `org-setup-filling' got called prior to `org-element-cache-reset' and
>  `org-setup-filling' has an explicit (require 'org-element) statement, which
>   made autoloading unnecessary in the past. 

OK, that explains the problem, I think.

> I can generate an alternative backtrace using debug-on-entry org-mode.
> The debug buffer right before error is below

Thanks.  However, even before I look deeper into the backtrace, it
sounds like the problem looks us right in our face.  The snippet from
org.el I posted earlier, i.e.

  (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))))

explicitly avoids loading org-loaddefs.el if org.el was loaded via
eval-buffer.  Which is exactly the case here, isn't it, and explains
why the loaddefs aren't loaded?

So now the question becomes: why does org.el treat eval-buffer in this
special way?  Perhaps because of byte-compilation or something?

Previous Next

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