Renaming a page does not update certain links of its children
This is somewhat related to the two previous bugs that I've submitted (both have been fixed), the most recent being #511481. I am running Zim 0.48 on Debian.
I've noticed something potentially improper when renaming a page with children in the specific case that the contents of those children reference each other. Following the format for creating an example that I used in the aforementioned bug report, consider the following simple hierarchy:
* TheParent "Loves [+FirstChild] and [+SecondChild]
** FirstChild "Hates the [SecondChild]"
** SecondChild "Loves the [FirstChild]"
If you rename TheParent to anything else, all of the following happens:
* TheParent is renamed to the new name (that makes sense)
* The relative link from TheParent to Child1 is preserved (that makes sense)
* The relative link from TheParent to Child2 is preserved (that makes sense)
* The content of Child1 is transported to a new page underneath the renamed parent (that makes sense)
* The link from Child1 to Child2 is converted from a relative link into an absolute link that reflects the OLD hierarchy, which no longer exists (that doesn't make sense)
* The content of Child2 is transported to a new page underneath the renamed parent (that makes sense)
* The link from Child2 to Child1 is converted from a relative link into an absolute link that reflects the OLD, which no longer exists (that doesn't make sense)
While I can actually see some advantage to calling this behavior a feature rather than a bug, I think that this simple example suggests just how much havoc such functionality could bring to a well organized notebook. The simple act of renaming a page should not irreversibly break a notebook and its references.
I suspect that the issue may go even deeper. Using the same initial sample hierarchy outlined above, instead of renaming TheParent create a new page called NewParent. If you move Child1 underneath NewParent then the link from Child1 to Child2 is converted into an absolute link and the link from Child2 to Child1 is converted into an absolute link. This makes sense. If you then move Child2 underneath NewParent then the link from Child1 to Child2 is converted back into a relative one, and the link from Child2 to Child1 remains absolute but correct. Technically, this makes sense, but it's not really what you want. What you want in this case is for both links to be relative again at the end like they were in the beginning. However, I understand the limitation. You basically have to make a decision that all links are either going to be aggressively re-factored into relative links whenever possible or always expanded out into full, absolute links. However, this simple moving example doesn't really do either. One is link ultimately has its relativity preserved while there other has it destroyed. It's not consistent. Moreover, it doesn't change the fact that the page renaming issue outlined above is very unacceptable.