Saving an Org file expands the TOC header

[wasamasa]

This results in involuntary scrolling if it is still in the viewport.

[wasamasa]

Must be the (org-show-entry) in the code. Perhaps remember the original state of the heading and restore it later?

I've also noticed that point isn't restored properly. Apparently this is due to the way save-excursion is implemented. It works perfectly when the buffer it's used in isn't modified, however you are deleting and inserting the TOC, so this anomaly can be observed. I'm currently writing a replacement for it that does restore point properly even for this scenario.

[snosov1]

Actually, I believe, that's because I call (org-show-entry) when inserting the toc :smile:

It was a recent change. I did this to make TOC look prettier, because it was kind of messed up - the TOC is inserted, but the heading is collapsed, so it results in a clunky look (the "collapsed dots" are there and the first line appears on the same line as the heading).

I think it shouldn't be too hard to fix this.

[snosov1]

I removed org-show-entry call, but it didn't fix it. Apparently, you were right - this seems to be a matter of save-excursion. Do you think it can be easily worked around?

[wasamasa]

Stepping through the interactive debugger revealed that even without (org-show-entry), the heading is expanded after the last insert call and before the excursion is done.

[bradyt]

Not sure if this adds to clues, but expansion of :TOC: tree also happens on first time opening file. Even if there is #+STARTUP: overview. Whereas, C-u C-u TAB will subsequently fold these trees.

[wasamasa]

This even happens when I just use (insert "Foo\nBar"). Digging into Org to find out why.

[wasamasa]

OK, I've figured it out.

Org is using an overlay wth the invisible property to hide the contents of a heading. Further inspection revealed that this overlay has the evaporate property set as well. This means that the deletion portion of the command will reduce the text covered by the overlay to nothing and the overlay will simply vanish. In other words, inserting text at the position where the overlay was will result in not hidden text.

So, what can be done about this rather silly issue? My initial idea was to determine the folding state of the heading before doing anything special, unfolding if it wasn't done already, doing the manipulation, then restoring the folding state if it did change. However it looks like Org does not provide something as basic as this and instead org-cycle-internal-local (which is over a hundred lines of code) and anything else redoes this effort in an ad-hoc manner.

[snosov1]

Not sure if this adds to clues, but expansion of :TOC: tree also happens on first time opening file. Even if there is #+STARTUP: overview. Whereas, C-u C-u TAB will subsequently fold these trees.

I took care of it by eliminating the (org-show-entry) call. Does it still happen?

So, what can be done about this rather silly issue?

Let me make sure I get this straight. The only issue is that if the TOC is partly visible, the scrolling can change upon saving (to make the first TOC entry visible) and that's it. Right?

[wasamasa]

The first issue is that scrolling/point can change. The second is that even without org-show-entry the heading is expanded if it wasn't expanded before. I've explained the why behind the second change in my previous post and a possible fix.

[snosov1]

Ok, thanks. I see, there are 2 issues.

And did I understand you correctly that you didn't find a clean solution to the "unfolding" one?

[wasamasa]

Yes, that's right.

[wasamasa]

Turned out it's way simpler than Org's sources suggest.

[snosov1]

Fixed for the case when TOC is unchanged. Won't fix for the opposite case (see https://github.com/snosov1/toc-org/pull/9)

[wasamasa]

Thanks! I didn't realize you fixed this for the common case of an unchanged TOC two years ago. Perhaps this is enough for me to finally add a TOC to my init.org...

[snosov1]

Sorry for hiding this from you for so long =)