Fixes part of issue #91 regarding nested headings

[fakedrake]

Fixed the combination of some breaking assumptions of org-transclusion-remove in the presence of nested transclusioins:

• the character right before the beginning of a transclusion is not necessarily an adjacent transclusion. It might be the parent transclusion.

• Using insert-before-markers to re-insert the #+transclude: ... element loses information about the text properties present before inserting the cloned text. This is still prone to bugs but using insert-before-markers-and-inherit instead avoids the common case errors.

[nobiot]

Thank you. I will need to spend a bit more time.

I didn't know that it was possible to manually call the add function on a transclusion within another transclusion. That itself is a bug -- discrepancy from my original design and should have been prevented in the first place.

Your PR tried to make this bug legitimate.

This might work but... From my own experience of developing the remove function, it is an area that would require a significant amount of regression if I were to accept your PR.

I hesitate to take it as it is for this reason but at the same time it might be a fruitful avenue to pursue...

[fakedrake]

Since yesterday I gave rubbed against at least a few of the problems you imply. The biggest problem seems to be that when the transcluded text is removed and the transclude keyword is insert-before-marks, it's hard to tell which marks will be moved. Consider the following case:

we have 3 consecutive transclusions:

#+transclude: A
#+transclude: B
#+transcude: C

then all of them are expanded.

then we try to remove B: The transcluded text is removed but before the keyword is reinserted we are in the unfortunate position to have the beginning of C and the end of A to coincide. Then there is no way to insert the keyword of B without doing something complex to distinguish between A and C.

I have a branch that has a few features I need that you may not necessarily want to add to master (see end). In there I mitigated this issue by including two newlines at the end of the transcluded text that do not get any of the overlays except the read-only ones. When a transclusion is removed the newlines are also removed. This way the end of a transclusion never coincides with the beginning of the next one.

Features you may not want:

• When transcluding an org file that has a #+title, the transcluded text is wrapped in a heading and headings internally are demoted.
• A variable org-transclusion-enable-recursive-add controls whether org-transclusion-add-all transcludes recursively
• Removing works as one might expect with nested transclusions.

[nobiot]

For now, I am putting a new check to prevent any case of transclusion in another with the new commit 330d761. Sorry that I am not prepared to spend time and efforts for regression at the moment.

I believe with this change this following case won't happen, and hopefully every character (if it's in a trascnslusion) right before the beginning of a transclusion is always an adjacent transclusion. No nesting, so no parent transclusion.

the character right before the beginning of a transclusion is not necessarily an adjacent transclusion. It might be the parent transclusion.

In addition... The current design deals with the case of three consecutive transclusion; I cannot reproduce it (this is one of the things I tested so I was hoping it won't happen).

#+transclude: A #+transclude: B #+transcude: C

[devcarbon-com]

Just wanted to pitch in to say that I'm quite interested in recursion as well. Thanks for looking into this!