In the future we might adopt a different naming scheme, maybe something like -32- instead of [32].
But like I say to those that really want links, using the standard Markdown link, instead of the WikiMedia syntax, is the way to go.
That said, when I find myself frequently using an alias, I will add it to the metadata because Obsidian will give me a box to quickly select the alias as I write. Saves oodles of time and reduces friction as I write. Does this give you a new perspective on linking in Obsidian?
I would still call that the “display text” part of a URL, not an “alias”, but semantics aside, maybe what I’m missing is that this only makes sense to those that use the editor mode that hides your markup aggressively? Otherwise I don’t see why you would want to bulk up the link markup with more text.
But, I’ll also admit I don’t really use Obsidian for its linking at all, so I’m kind of outside of its thought zone to begin with. I have my own link markup I’ve been using for ages, that works better for me (and is capable of traditional aliasing, where we can link to ‘x’ with nothing by ‘y’, not ‘x+y’).
On the RegEx replacement: yup that looks robust to me, if you want to capture the second part of the link in preference to the first part, and fall back to the first part if there is no second part.
Other non-sync alternatives, like compile, I think you exhausted all of the potential problems there, but here are some further tips that might still yet be useful to you at some point, even if not for this.
Amber, the issue with the built-in file-name protocol using brackets has me heading down another rabbit hole. Am I correct that I could use the compile function instead of just using the sync folder function in Scrivener (which is what’s producing those file-name single brackets that Obsidian just hates)?
You can certainly, in a Markdown or TXT-based workflow, compile to multiple files. The main issue with any kind of compile-based round trip workflow though is no efficient means of getting those files back into the original binder items. It hugely limits your ability to use the software since you would no longer be able to use Scrivener’s bookmarks, metadata, custom section types, collections, the very outline hierarchy itself (in most cases). I.e. you’d be down to a flat list of files in the Draft that do nothing other than title+mainText.
It’s barely even using Scrivener at that point, at least in my opinion.
Aeon Timeline automatically labels…
Ah, and forget about any of that, since Aeon uses custom metadata on the original binder items to orchestrate its integrated feature set. Importing what had been compiled, as a replacement hierarchy, would lose all the original Aeon markup.
Also, I found no way to get scene-ordering data inside Scrivener into a Scrivener metadata field, either (a shot in the dark, that).
I’m not 100% on what that means, but this kind of sounds like the sort of thing you would do by adding <$n> (or <$n:scene>, if you want multiple counters) to the Section Layout for each scene. Or if not that, if you were using a file splitter setup like I linked to above, the numbering could very easily be handled at that stage.