snosov1 / toc-org

toc-org is an Emacs utility to have an up-to-date table of contents in the org files without exporting (useful primarily for readme files on GitHub)
GNU General Public License v3.0
287 stars 29 forks source link

Missing new line before TOC #47

Closed ghost closed 6 years ago

ghost commented 6 years ago

This is how it looks like when I save the file. When I cycle the visibility of the table of contents subtree, the issue is gone and the first item - Foo is on the next line. This happens every time, when it is generated. A quick fix would just be to insert a new line before the very first element, this wouldn't be that harmful.

* Table of Contents                        :TOC_3:noexport:...- Foo
- Bar
- Baz

* Foo
* Bar
* Baz
snosov1 commented 6 years ago

Hey!

This is, actually, a known and long-standing issue. If you're interested, you can read starting at https://github.com/snosov1/toc-org/issues/4

But long story short - there doesn't seem to be a nice fix for this. So we ended up fixing it only for the cases when the table of contents is not updated (i.e. most of the time, since the structure is not supposed to change often). After this fix - it doesn't seem to be a big problem anymore.

As for your suggested change, I don't believe it fixes the issue. As a matter of fact, the package used to have a 1-line break right after the heading and, if I recall it correctly, it looked the same. (https://github.com/snosov1/toc-org/issues/41)

ghost commented 6 years ago

@snosov1 How about to do a (org-cycle) twice every time the toc gets updated? This also solves the issue for me.

snosov1 commented 6 years ago

I only vaguely recall the implementation details about this. I think there was a number of problems with org-cycle.

  1. I think, special handling is needed for the cases when the TOC is unfolded (and worse yet - partially unfolded). There doesn't seem to be a reliable way to save and restore this state.
  2. I think, it behaves differently when used interactively and from the code
  3. I think, it prints stuff to the minibuffer all the time

Do you see any problems like this with your workaround?