#1

POLL 1

  • I’ve experienced the pain of software lock-in
  • I haven’t experienced the pain of software lock-in

0 voters

POLL 2

If you experienced the pain of software lock-in…

  • I experienced lock-in pain in Evernote
  • I experienced lock-in pain in a different app
  • The pain of software lock-in is a major reason why markdown is so important to me

0 voters

POLL 3

Why is markdown important to you…

  • Markdown is important to me because it is future-proofed
  • Markdown is important to me because “exporters are not to be trusted”
  • Markdown is important to me because I really don’t think I’ll be using one company’s proprietary software 5-10 years from now
  • Markdown is important to me because I can use multiple pieces of software to read my markdown library right now

0 voters

What did these polls not cover that’s meaningful to you?

1 Like
#2

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.

5 Likes
#3

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.

6 Likes
#4

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.

13 Likes
#5

Yes, if text files are no longer supported then this current civilization is gone from this planet.

PS: Introduction of Unicode was the last big feature we needed for text files.

3 Likes
#6

That’s why Commonmark exists.

9 Likes
#7

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.

1 Like
#8

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! :smiley:

3 Likes
#9

If developers were able to integrate the features of Mark Text with Obsidian, it would be by far the best markdown editor! :star_struck:

1 Like
#10

It’s in their development roadmap, so it sounds like you’ll both be very happy soon

2 Likes
#11

The other alternative is Microsoft introducing plaintext as an option in Word. Their flavour would quickly drown all the others.

1 Like
#12

The adoption of Commonmark would seem to be a good choice.

1 Like
#13

The problem is that it’s insufficient. Competing flavours that do the same thing can be resolved but insufficiency always invites extensions.

#14

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.

#15

Commonmark or markdown in general? What benchmark are you using to determine if a flavor of markdown or other markup is sufficient?

#16

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.

#17

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.

1 Like
#18

My main reason for using this tech is [[backlinks]]. I don’t know any other software which makes back linking as fluid as what obsidian provides.

Although i agree that markdown files in itself are future proof, I’m afraid that the [[backlinks]] handling will be broken outside obsidian.

I’ve tried fiddling with md files in VScode, and i realise that backlinks pointing to notes in other folders or sub folders are broken.

1 Like
#19

?
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.

#20

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.