Markdown itself is lock-in (as in, you’re locked–in with the format, not the app).
It has so many different flavors and extensions that are incompatible with each other. It lacks specification so there is no such thing as invalid Markdown. Once you have a considerably large amount of Markdown files you’re pretty much stuck with it.
Better than getting locked-in with an app but still locked-in to the format nevertheless.
This is one of the biggest problems I’m having right now in terms of creating a future-proof notetaking system.
The good thing about Markdown is it can easily be parsed, which means if you need a different Markdown style, you or someone you know can convert your text to something else. Indeed, using a programmers editor like Visual Studio Code, I could just with a command, replace all text matching a regular expression, in the entire vault, converting one mark style with a different mark style.
The only other alternative I see is to use .txt and ditch all formatting, which would work too. That’s essentially the trade-off between format lock-in and expressiveness.
Extending your argument, I would argue that writing in English is a language lock-in. Of course, very few people worry about English going away; Markdown is much newer. Sadly, I don’t think there’s a more future-proof format than Markdown right now, since it’s both popular and human readable.
The problem with Markdown is that most developers are too lazy to create WYSIWYG, it could be beautiful like Scrivener, but they leave us with this horrible design and most of the time with double window (edit / view).
Typora and Mark Text are the only ones I know who created WYSIWYG, Joplin is also getting there.
I think we’re in luck! The Mark Text editor is open source and looks easy to integrate (it looks like it runs with marked.js as the Markdown parser), so devs can be too lazy to create a WYSIWYG editor and eat their cake, too!
wrt the polls, I don’t think any of the issues are entirely true. Eg Evernote is easy to escape, Onenote less so. Physical storage formats are often the most intractable issue.
The huge advantage of plaintext, which is what has powered its expansion, is that it is much lighter on resources (space, processing, developer). This makes it desirable for phone apps, the web and search. It’s held back by the lack of common standards that are sufficient for all developers and users.
Both.
Easiest way is to look at the number of developers creating extensions for their own apps and the number of users expressing a desire to do something that isn’t possible. Nothing to do with benchmarks.
How so? When you have thousands of evernote links, please share your wisdom on how those can be converted to wiki-links? It won’t save me the hours lost trying to salvage those notes, but it may help others.
?
You must realise that markdown and document format has nothing to do with the ease, or otherwise, of exporting links.
A link is just a search function using unique identifiers. Virtually all programs using them have them in a database for speed. That’s not easy to export or import. I’d expect similar issues in Obsidian and other programs using markdown. I assume you’ve tested Obsidian to make sure you can easily export your links.
As it is, Evernote does export the links with its HTML export; the problem is that it’s a link within its database (ie cloud) so it is a slow process. But there’s no lock-in.
I’ve not probed at all but that’s what I’d expect. One way of trying to achieve it is possibly is to drop in a unique identifier at every link destination, but that won’t give you backlinks unless you also ensure you have the unique identifier for the starting point. Downside of that is that you lose the gain of using the program.
My own approach is a combination of adding unique headers where I think I might want them (usually x+timestamp), and a fast text editor with grep. I know this will always works and I can test it when I want. But a degree more effort and time, so I do it judiciously.
