Internal links are very unreliable

Home Forums cherrytree Internal links are very unreliable

This topic contains 9 replies, has 3 voices, and was last updated by  Klaas Vaak 11 months ago.

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
  • #124489

    Klaas Vaak

    Internal links, i.e. the green ones, referring to another location within the same Cherrytree file, are not reliable. I have found that, for unknown or untraceable reasons, those links get broken. If they refer to a named Anchor, the name of the Anchor gets dropped. This is extremely annoying & also worrisome.

    Can you please tell me why this happens and how I can avoid it?
    If it is a bug, please fix it a.s.a.p. because this really messes up an extremely useful network of cross-references.



    Hi Klaas,

    In my several years old database I use many internal links, but no anchors. I cannot confirm the problem. So I believe, that Giuspen needs more details. Does the problem only happen for you with anchors or also with other internal links?


    Klaas Vaak

    Cosmo, first of all, thank you for your quick reply 🙂

    I am not sure what you mean by other internal links, but if you mean just a reference to another node, rather than to a specific location within a node, then my answer is NO, it does not happen with references to other nodes, it only happens with references to Anchors.



    Klaas, you understood me correctly. I meant internal links without anchor. So I understand you, that those are not affected, only anchors.

    I don’t use anchors, so it is not surprising, that I did never encounter this issue. Can you tell a little bit more? Do the links break at once or after a new session of CT gets launched or after rebooting?

    I think that Giuspen will also need to know, which OS you are using, Linux (which?) or Windows? In case of Windows: Installed desktop-version or portable? You should also confirm, that you are running the latest build of CT.


    Klaas Vaak

    Cosmo, my OS is Win 8.1/64-bit installed desktop version, CT version 0.38.2 portable.

    The links break while I am working with CT. So, let’s say I insert an Anchor & give it a name, I the save CT immediately (CTRL+S), but I keep CT open. Then I carry on working, adding more text to the same node, or another node, then when I come back to the named Anchor, the name is gone.
    It does not happen all the time, but it does happen regularly. Also, once I have named the Anchor for the 2nd time, it keeps the name.

    And what still works is that, even though the Anchor name is gone, clicking on the text linked to the Anchor does take me to the right node, it just does not take me to the right location within that node of course.



    I am on Linux and just did a quick test, but I cannot reproduce it.

    You might create a new database and see, if the problem is reproducible there.


    Klaas Vaak

    Comparing Linux & Windows is not the same of course.
    With me the problem persists even with a new database.



    I’m running CT on both Linux and Windows 8.1 Pro. I can’t reproduce the problem with broken anchor links either (three day test) on any of my systems.


    Klaas Vaak

    Thank you for jumping Sisyfos.
    So let me tell you my procedure with anchors.

    I put my cursor where I want to have the anchor, then with Alt+E+A I insert an anchor. I then right click on the anchor, Edit Anchor, give it a name in the dialog box, click OK to close the dialog box.

    As far as I know, that’s all there is to it, or have I left something out?


    Klaas Vaak

    It just happened again. I have a TOC in a node (actually in most of my nodes) and renamed an anchor, which was there when the TOC was made, from h3-2 to “singer”, refreshed the TOC, then pressed CTRL+S. BTW, the anchor is not in the TOC itself but in the text below.

    Then I renamed another TOC-created anchor from h2-1 to “donor”. But when I wanted to link this part of the text to the previous anchor (“singer”), the name “singer” had disappeared and the anchor was a general h anchor again.

    OK, I think I know what the problem is. If you rename a header anchor, then running the TOC again (Alt+E+O), the named anchor will get renamed to the general format

    So, the solution is to NOT rename anchors created by the TOC (unless you don’t change the TOC anymore) but to insert a separate anchor that is not affected by TOC activity.

    I just tested it & it works.
    So it would be useful to make a comment about this in the Manual.

    • This reply was modified 11 months ago by  Klaas Vaak.
Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.