From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs 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 Message-ID: <83v8pgu3rf.fsf@gnu.org> References: <87fsglxh24.fsf@localhost> <83k05xufhf.fsf@gnu.org> <8735clx8cl.fsf@localhost> <83edw4vqsq.fsf@gnu.org> <838rmcvphe.fsf@gnu.org> <8335ckvn5p.fsf@gnu.org> <83zgesu7jz.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4410"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 57972@debbugs.gnu.org To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Sep 21 17:51:00 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ob203-0000wn-Vh for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 21 Sep 2022 17:51:00 +0200 Original-Received: from localhost ([::1]:47126 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ob202-0005Po-MK for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 21 Sep 2022 11:50:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40272) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ob1z9-0005Ml-02 for bug-gnu-emacs@gnu.org; Wed, 21 Sep 2022 11:50:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35995) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ob1z8-0005jT-8t for bug-gnu-emacs@gnu.org; Wed, 21 Sep 2022 11:50:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ob1z7-0005gn-K8 for bug-gnu-emacs@gnu.org; Wed, 21 Sep 2022 11:50:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 21 Sep 2022 15:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57972 X-GNU-PR-Package: emacs Original-Received: via spool by 57972-submit@debbugs.gnu.org id=B57972.166377534721793 (code B ref 57972); Wed, 21 Sep 2022 15:50:01 +0000 Original-Received: (at 57972) by debbugs.gnu.org; 21 Sep 2022 15:49:07 +0000 Original-Received: from localhost ([127.0.0.1]:35073 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ob1yF-0005fR-6m for submit@debbugs.gnu.org; Wed, 21 Sep 2022 11:49:07 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:33212) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ob1yD-0005ev-QJ for 57972@debbugs.gnu.org; Wed, 21 Sep 2022 11:49:06 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40808) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ob1y8-0005eo-GK; Wed, 21 Sep 2022 11:49:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=ubYwy+bunYXZgReEbz7LUfDJ64+vox4qlQEhQTIYMww=; b=eomProg6Z/Iw LIr6suHGEj2hClIb5kTiKdCXCxQ9QjoF2TbyxDO9VCM5jhJaC7e94Pupo6P17UngrzjmF85xMo5/y tTzSvAYuymyUDGvtUlztmqpHnFpYdbWTEsxvJ4Hs1kK+SKMwdT8dEjTbBMAswBMm+2pmDfzLIcEVE S+up92crhRfvCqkT1MfjVng3cNA4KwYYIpwzIKZFmYsVzerVPHFe6584b/wRlNPh/AIDgOWBq+jEF Q4Q5tpwqK6LXhhGz/ki/uwQzbIFhchxnxfj4adDfA4TrxXoQ1hQN6d/pySJOrzV3L8hWcEgETkdVL L/3QuL3BFGKZhL+vyD9zzA==; Original-Received: from [87.69.77.57] (port=3132 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ob1y7-0000TR-UX; Wed, 21 Sep 2022 11:49:00 -0400 In-Reply-To: (message from Ihor Radchenko on Wed, 21 Sep 2022 22:51:16 +0800) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:243367 Archived-At: > From: Ihor Radchenko > Date: Wed, 21 Sep 2022 22:51:16 +0800 > Cc: 57972@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?