@WhiteNoise you are already very close to providing the functionality that is needed. Consider that in order to provide the WikiLinks, Obsidian now does this:
Creating WikiLinks Internal Links
- user types a trigger (
[[) which activates the system
- system offers user with a dropdown to choose from internal files, from which it will derive the link path
- system allows the user to extend the path with an internal document link, by watching for another trigger ("
#"). If trigger is used, show possible internal headings, adding link to the path.
- last of all, system allows the user to define the link text, by watching for another trigger ("
|"). If the trigger is used, then any text that follows will be used as the clickable text for the link.
- once everything is entered, Obsidian automatically creates and enters the WikiLink
In order to create an internal link using standard markdown, however, the only help the user needs is in entering the file path - as the user will manually enter the link text anyway. So, all we need is a shortcut help for adding internal file paths., in the standard syntax. Here is a possible workflow:
Creating an Internal Link with Standard Markdown
- user types in the link text (e.g.,
[my link]() or link reference (e.g., [link]:) stopping just before a path needs to be entered.
- The user types in a trigger - something like “
((”, or “\\”, or even “[[[”,
- Obsidian shows a dropdown menu allowing user to choose files - just like it does now for WikiLinks
- Once the file (and optionally the heading) have been selected, Obsidian outputs the path - in standard format (so a file titled “my file.md” would be output as “my%20file.md” automatically).
This makes Obsidian super helpful also in building standard markdown links. Obsidian would still continue to make sure, that if the user decides to change the filename, such paths would be updated automatically, too (as it already does now).
Longevity vs Convenience
Most users are going to be very thankful that Obsidian provides such great features, which go beyond what is supported by the standard markdown syntax - or even by MultiMarkdown - such as WikiLinks, links to headers, and file embeds. These features are, indeed, extremely useful and convenient.
There are many users that are finding Obsidian when looking for a good Zettelkasten app. A key principle of Zettelkasten is to strive for longevity in our notes, and this is why many “Zettelkasten pro users” advocate using the simplest tools we can find - like text files, and nothing more than standard markdown for text structuring. There are, indeed, a myriad of other ways to keep our notes, which would indeed be much more helpful than just plain text - e.g., rich text, or full-blown HTML, .docx or even proprietary file formats offered by other apps. But from the Zettelkastener perspective, all these formats are ‘a risk’ of sorts, because we don’t know how much they will change (or whether they will even exist) 10 or 20 years from now.
So, while it’s awesome that Obsidian offers great ‘extended’ features, the most important feature of all, for a Zettelkastener, is longevity of their notes. And that means full support to the standard markdown syntax, as first-class citizen, and not as an optional afterthought. As soon as the app starts encouraging users to adopt non-standard syntax, it’s encouraging dependency and vendor lock-in.
I believe this is not the intention of Obsidian, because you guys go through great lengths to show users that one of your core values is that “the user should own their own data”. But what you might not realise, is that by encouraging non-standard syntax as a primary feature of your system, you are actually encouraging users to lock-in, and going against your own principle.
Non-Standard Syntax for Basic Features vs Add-On Extras
You are right in stating that markdown is limited - it is so by design. It is intended as a human-readable format, meant to be understood even if not parsed at all. Its intention is to provide essential structuring (h1-h6, lists, quotes, images), highlighting (bold, code) and a way to provide hyperlinking in plain text documents. It is reasonable for any user to expect that a program that ‘supports markdown’ would support these basic features well, and work with them in a reliable way, and with very little surprises.
If an app offers extended features that go beyond the basic markdown, those features will necessarily require their own syntax. By using them, the user understands that they are choosing to lock themselves into an app, and that specific feature set. If my notes absolutely NEED tables, I know that I’ll need to use multimarkdown syntax - and I’m going to be locked-in to apps that support it. If I cannot live without embeds, I’ll use Obsidian’s ‘embed’ syntax - and I’m willingly and happily locking myself into it.
Using proprietary syntax for ‘extended’, non-standard features is expected - and the user does it at their own peril. This is significantly different to encouraging the user to use non-standard syntax for basic markdown features, such as images and links. This is encouraging lock-in - and simply not necessary.
IMMHO, an app that has the motto “the user should own their own data” as its core, should encourage users to avoid lock-in, by encouraging the use of standard syntax whenever possible. I’m pretty sure that this is still Obsidian’s intention, but in the effort of being ‘as helpful as possible’ to the user, perhaps this principle is being forgotten - or, at least, ‘diluted’…