Since the 1.1.0 update (I believe), Obsidian prevents changing the title of a note when the edit contains link-breaking characters such as ], # etc.
Even if it appears reasonable to prevent a distracted user to rename a note that way, using link-breaking character while renaming a note, like:
title note A]] - [[title note B
is the only possible way to update every link to note A, to a link to note A and note B.
This is an important (probably non intended) feature since splitting a note into two is a common use case, and being able to do it within Obsidian and not via another tool like Notepad++ greatly reduces workflow friction.
Proposed solution
Allow editing of a title even when link-breaking characters are present. Show a “are you sure” message instead as a toggleable feature in the option menu.
Current workaround (optional)
Renaming the title using link-breaking characters is still possible via the “rename” option in the note menu.
Splitting a note is probably somewhat common, but this sounds like an unusual use case to me (or at least, I’ve never wanted to do it when splitting notes).
Maybe not many people think of this workaround, but, if you can do it, why wouldn’t you want to update the old links to include the new relevant notes too? It’s the only way to transfer the backlinks from the old note to the new notes.
Would you be able to show a screenshot of an actual example?
Are you talking about a plugin that does splitting refactoring like Note Refactor? I see you mention “Note Composer” in another thread.
Also, your example is a bit ambiguous. “note A and note B”. Are you trying to make a link to two separate notes “note A” and “note B”, or is your note called “note A and note B” after refactoring or splitting? Again I think a screenshot or an actual example would be helpful.
(Also, if you’re using a plugin, it might be a matter of making a request for that plugin on the Github page.)
“still possible” - That was recently changed. All cross-platform symbols used to be forbidden. Now they are allowed if it’s allowed on your operating system. (As far as I understand.) But they still break links, as you say. I’m testing on MacOS, and I can make files that contain some of those characters. (I almost moved your post to Help, but I can see how this might need consideration with the new way file names work.)
I have to disagree, on my end up to at least 1.0.0 a red warning popped up, but Obsidian did not actively prevent the note title from being modified. The behaviour was identical to the one in the screenshots, but step 3 would work as well as step 4. Now only step 4 works.
Nope, I used to do this (and still do it) without a plugin of any sort. As far as I know note refactor does not behave in the same way as this workaround does.
Example of use-case
Let’s start with a “note A” containing a link to “note B”
Obviously “note B” contains a backlink to “note A”.
Imagine “note B” has a interesting subtopic which warrants its own note. The new note will be called “note C”. Since the topic of note C used to be part of note B, I wish that the backlinks of “note B” are automatically inherited in “note C”. The way I used to do this was renaming the title as below. New versions of obsidian will ignore any change
It is still possible to rename via the “rename” command on the note option menu.
Once the note is renamed, backlinks will be addressed to “Note B” and “Note C”.
The new file: Note C has now every backlink of Note B, “Note A” now contains a link to: [[Note B]] #split [[Note C]]
(the #split tag is just a way to keep track of this automated action when I review in future note A)
Again, I’ve been using obsidian for like two years this way, and I’ve always been able to rename the title with characters if they were allowed by the OS (Windows 10), even if link-breaking.
Why I need to do this? I handle more than 10k notes in an evergrowing environment, backlinks are extremely helpful in keeping the puzzle connected. Splitting a note without splitting the links to that note will eventually result in a loss of connections.
All things considered I’m ok with the current behaviour, it’s a minor inconvenience. It would become a major problem for me should the rename function follow the same behaviour in future, completely preventing the workaround.
