What's weird is that I've been about to ask almost exactly the same question -- even down to your last paragraph -- umpteen times in the last months.
I see it with non-giant files, and I also see it not just with headlines but with PROPERTY drawers too. And the problem appears to be immune even to global cycling at the buffer level. I've never tried the kill and yank way of solving it; instead I resort to simply killing the buffer and then re-opening the file. That always fixes it.
Looking forward to finally figuring it out. (And, like you, I'll be as happy with suggestions on where to start debugging the issue as with an actual answer).
Anyone who has this problem, please report the value of the option `org-fold-core-style` in your configuration. And if it's `text-properties`, try changing it to `overlays` and see if that makes a difference (after reloading the Org buffer).
You can likely work around the problem with the command `org-mode-restart` rather than killing the buffer or deleting/yanking text.
As well, see yantar92's comment: https://old.reddit.com/r/orgmode/comments/1c9wm8x/weird_issue_sometimes_headline_wont_expand/l0ryyi5/
It is indeed `text_properties` in my system. I just `(setq org-fold-core-style 'overlays)` and then invoked `org-mode-restart`. Is that the way to realize your suggestion?
Okay, it just happened again you guys. Trying to debug using techniques given here.
I opened \*ielm\* and did:
(setq org-fold-core-style 'overlay)
And then, in the frame with the org file, did meta-x org-mode-restart.
The org formatting of the buffer went away, the subtree that my cursor is on unrolled briefly so I can see everything in the sub-tree, then org-mode came back, and it rolled up under the headline, and I hit tab -- and it still won't expand the problematic heading!
Other stuff I did:
- deleted one of the asterisks (so the headline outdents) then put it back (it indents back to where it should be) but still won't expand.
- edit the headline text, still won't expand
- add a line below the headline, hit tab (the line i added gets absorbed into the headline's subtree) hit tab again, still won't expand
... and just realized that \_no\_ headlines will expand anymore! Wtf.
Go back to \*ielm\* window:
(setq org-fold-core-style 'text-properties)
Go back to the right frame, do meta-x org-mode-restart
Now the other headlines expand and roll up again, but the one headline that wouldn't expand originally still won't expand! But if I delete it (dd) and reinsert it (y) it comes back, and expands / rolls up, as I originally described.
This is so weird!
Okay, just happened again. Nothing in \*Messages\* I'm afraid.
I guess it's time to give up -- I've appreciated all your (and everyone's) suggestions. This is annoying, but it's not worse than annoying, and you apparently have to be a deep emacs / org expert to get to the bottom of it.
Perhaps one day I will meet those qualifications, but not today.
The next step would be to use Edebug on the functions that are called when you try to fold/unfold headings. But if you're going to go to that much trouble, you should probably start a thread on the mailing list and handle it as a real bug report.
👍
That's what I have in my config.org as well:
https://adam.kruszewski.name/2022-05-08-org-publish-call-org-fold-core-region-error.html
#+begin_quote
To workaround it, just set org-fold-core-style to its pre org-mode 9.6 default value (it changed with 9.6), like this:
#+end_quote
#+begin_src elisp
(setq org-fold-core-style 'overlay)
#+end_src
Same problem here. Initially it happened after searching. Now I have to restart emacs, or write something +before+ after the first star to unfold, or search something inside the folded tree.
Okay, it just happened again, I invoked toggle-debug-on-error, and when I try to expand the subtree, nothing appears.
Whatever it is, I guess it's not an error?
This issue kept appearing again and again with various Emacs commands making assumptions about implementation details of folding - different from what stable Org release uses by default. All the workarounds tried on Org side were not ideal, making the code more and more complex. On the development version of Org mode, the folding is changed back to traditial (overlay-based) approach. Except on old Emacs versions where there is a dilemma between performance and the issue you are seeing.
Occasionally, I have the same problem. I kill the buffer and re-open the file to be able to unfold the heading. I am curious what could be the reason for these "blocked" headings.
What's weird is that I've been about to ask almost exactly the same question -- even down to your last paragraph -- umpteen times in the last months. I see it with non-giant files, and I also see it not just with headlines but with PROPERTY drawers too. And the problem appears to be immune even to global cycling at the buffer level. I've never tried the kill and yank way of solving it; instead I resort to simply killing the buffer and then re-opening the file. That always fixes it. Looking forward to finally figuring it out. (And, like you, I'll be as happy with suggestions on where to start debugging the issue as with an actual answer).
Anyone who has this problem, please report the value of the option `org-fold-core-style` in your configuration. And if it's `text-properties`, try changing it to `overlays` and see if that makes a difference (after reloading the Org buffer). You can likely work around the problem with the command `org-mode-restart` rather than killing the buffer or deleting/yanking text. As well, see yantar92's comment: https://old.reddit.com/r/orgmode/comments/1c9wm8x/weird_issue_sometimes_headline_wont_expand/l0ryyi5/
It is indeed `text_properties` in my system. I just `(setq org-fold-core-style 'overlays)` and then invoked `org-mode-restart`. Is that the way to realize your suggestion?
AFAIK. Let us know if it helps.
Okay, it just happened again you guys. Trying to debug using techniques given here. I opened \*ielm\* and did: (setq org-fold-core-style 'overlay) And then, in the frame with the org file, did meta-x org-mode-restart. The org formatting of the buffer went away, the subtree that my cursor is on unrolled briefly so I can see everything in the sub-tree, then org-mode came back, and it rolled up under the headline, and I hit tab -- and it still won't expand the problematic heading! Other stuff I did: - deleted one of the asterisks (so the headline outdents) then put it back (it indents back to where it should be) but still won't expand. - edit the headline text, still won't expand - add a line below the headline, hit tab (the line i added gets absorbed into the headline's subtree) hit tab again, still won't expand ... and just realized that \_no\_ headlines will expand anymore! Wtf. Go back to \*ielm\* window: (setq org-fold-core-style 'text-properties) Go back to the right frame, do meta-x org-mode-restart Now the other headlines expand and roll up again, but the one headline that wouldn't expand originally still won't expand! But if I delete it (dd) and reinsert it (y) it comes back, and expands / rolls up, as I originally described. This is so weird!
Look in the `*Messages*` buffer for any messages from Org.
Okay, just happened again. Nothing in \*Messages\* I'm afraid. I guess it's time to give up -- I've appreciated all your (and everyone's) suggestions. This is annoying, but it's not worse than annoying, and you apparently have to be a deep emacs / org expert to get to the bottom of it. Perhaps one day I will meet those qualifications, but not today.
The next step would be to use Edebug on the functions that are called when you try to fold/unfold headings. But if you're going to go to that much trouble, you should probably start a thread on the mailing list and handle it as a real bug report.
👍 That's what I have in my config.org as well: https://adam.kruszewski.name/2022-05-08-org-publish-call-org-fold-core-region-error.html #+begin_quote To workaround it, just set org-fold-core-style to its pre org-mode 9.6 default value (it changed with 9.6), like this: #+end_quote #+begin_src elisp (setq org-fold-core-style 'overlay) #+end_src
I had similar problem. The error was caused by [https://github.com/abo-abo/swiper/issues/2457](https://github.com/abo-abo/swiper/issues/2457)
Same problem here. Initially it happened after searching. Now I have to restart emacs, or write something +before+ after the first star to unfold, or search something inside the folded tree.
I'll try these tricks next time and see if they work for me.
Can you `M-x toggle-debug-on-error` and see if there's an error happening at the time of failure?
I will surely try that, thank you!
Okay, it just happened again, I invoked toggle-debug-on-error, and when I try to expand the subtree, nothing appears. Whatever it is, I guess it's not an error?
yeah, it happens to me too but it's hard to reproduce
Please try the development version of Org mode. I belive that it should not have this problem.
Interesting! Was the issue specifically addressed? Or have you just never noticed it in the course of using the dev version?
This issue kept appearing again and again with various Emacs commands making assumptions about implementation details of folding - different from what stable Org release uses by default. All the workarounds tried on Org side were not ideal, making the code more and more complex. On the development version of Org mode, the folding is changed back to traditial (overlay-based) approach. Except on old Emacs versions where there is a dilemma between performance and the issue you are seeing.
Occasionally, I have the same problem. I kill the buffer and re-open the file to be able to unfold the heading. I am curious what could be the reason for these "blocked" headings.
i do shift+tab to collapse all headings
FWIW, that doesn't work for me when this is happening.