Testing version: 2.0 (10084)
What were you doing:
note1 with link
- Follow link from
note1 to header in
note2: it works
- Rename header in
What feature did you use: internal links to headers
What happened: link wasn’t updated and partially broken now
What did you expect to happen:
[[note2/header]] should be automatically changed to
- Just like
[[note2]] link will change to
[[note3]] when you rename
Can confirm that this is still an issue. We are still being brought to the note, but because the header cannot be found, we land at the top (of the note).
At least none of the worst two things happen: cannot even navigate to the note, or that new notes or headers are created.
Bumping this up as I still experience the same behavior. Not to push and I know this might be of lower priority among other things. But would be nice if can get a confirmation from the dev team that this is noted.
I support you with this. This seems to be not-so-important issue for developers, however IMO when they provided this functionality (links to headings), they should assure that it is not easily broken by renaming the headings. It is probably not used by so many users, so the user voice is not so strong here… I hope it will be solved in the end.
For the time being, before it is implemented, I use this workaround: I (first) add a special character (^) to each heading to which I want to link. (e.g.
This is heading XY (^) (Of course, first I add this character, then I link to this heading). This is an indication for me then I should not change (or delete) the heading and if I would like still to change it, I should go to respected links and change them too.
Ah that’s a good workaround for now, thanks for sharing!
It’s still too much of a hassle if such workaround is needed in order to really take advantage of linking to headers without potential broken links. For now, I’m fine without linking to headers, but absolutely agree if the software provides such feature, it should be complete and not half-baked.
I must say, Bear for the 95% time, does really well on shipping polished features, and that’s why I always come back to Bear… And I’m confident that they will get to it, and I’ll just hold off using this feature for now.
I use that feature quite often. I just rarely rename my headings. Now I have a reason more not to do so No doubt, that should be solved sooner or later
This is still happening. Is fixing this at least on the roadmap? Thanks!
Wishing for this to be addressed as well.
I would like to add a +1 to this as a serious issue in my workflow. A pity nobody from the team spoke out on this thread so far. Hope it’s on their radar.
That‘s indeed a serious issues and goes against all expectations
To solve this issue in a good way we need to set the CRDT first because headers right now are identified by just their text. This means that if more than 1 header is modified and/or changes position in the text in a single “editing session” we might not be able to associate old and new headers and rename links in other notes.
Thanks for providing that insight. I understand this means this is not a trivial change and would require some development effort.
The question is: what are your thoughts about it? Is it something you’re at least entertaining the thought of? Or does it feel like too big an investment?
Well, yes. We have the CRDT part but needs to be integrated and tested (a lot). Once it works we can track how headers move or change inside a note and modify the header links to them. Considering our primary focus at the moment is Bear Web and Panda I can’t tell when will have this but we worked on the CRDT for other requested features such as note history and automatic conflict resolution so it will be part of Bear at some point.