I wholly disagree with this after using markdown for everything for a few reasons, but it may work for some people if you really love operating from a basic CLI. Some people also get by with storing everything in plain-text files as well. Why not, plain-text will still be supported as well.
Markdown, especially CommonMark, will likely never provide what you want. Is it convenient when you have hundreds or thousands of files to manually manage? Most likely you’ll constantly be searching for ways to make markdown work more like a word processor & CMS, because what you really want is a powerful WYSIWYG content management platform.
I’m not going to judge someone if they are content with basic markdown. It isn’t my place to. But to make a statement like, “if it is worth keeping, save it in Markdown” is preaching from a bubble.
Agree and disagree. There is a place for sophisticated management tools but when they stop getting supported or they’re purchase by a company you hate, you’re left scrambling to convert everything.
Best case for me anyway are sophisticated tools that use markdown as the basis of their files like Obsidian. So I know if they disappear I still have all my data in a universal format without any effort on my end.
The articles point was that markdown (or other similar utf-8 text based documents) is the best guarantee you have for the files being usable into the indefinite future. As you get into the complicated formats of things like word processors the less likely that format will be meaningfully usable in 10,20,50 years time, good luck reading a obsolete word processor file from the 80s today.
Like I said, the files are in a standardized format. You can literally extract & view the content yourself. Do you want extensively structured data in 10, 20 or 50 years, or do you want only the most basic? If something is important enough for you to save for that long, you prob should put some effort into making it useful. I’m not saying word processors are perfect, but almost every markdown editor out there is essentially trying to recreate a word processor.
CommonMark includes like 6 levels of headings, blockquotes, code blocks, bold, italics, hyperlinks, HRs, and lists? At what cost though? Which heading is the title, which one is the subtitle? Now you want to add frontmatter, which is not part of the CommonMark spec. What if you don’t want a thousand files, will your editor support multiple pages in a single file with multiple frontmatter declarations? Now you want a table, guess you’re going to deviate to GFM. What if you want to use callouts, etc.
I’d rather have a single SQLite file that has my entire knowledgebase in a useful CMS than having a thousand markdown files that I have no clue what I titled them 10 or 20 years ago. So much easier to manage, rename things, etc.
The important thing is that it needs to be in a human-readable format encoded as unicode text. Beyond that, any reasonable markup (plaintext, markdown, org-mode, HTML, etc.) is fine.
The problem with Markdown is it kind of sucks. CommonMark didn’t even defragment the markdown world, since there are numerous incompatible extensions. It seems like gfm is the best among them, or at least the most featureful.
I know there are other options like RST or AsciiDoc, but I don’t know which among them is actually “the best.”
WYSIWYG, Word Processors and CMSs are the kind of thing I don’t even want for my current content (or any content I made in the last 25+ years), why would I want any of them as an archive format?
Why not just use plain text then? I mean if your important content can be summarized into the most basic structure, why not just create your own markup format that makes sense to you? Makes no sense why you’d limit yourself to CommonMark.
I wholly disagree with this after using markdown for everything for a few reasons, but it may work for some people if you really love operating from a basic CLI. Some people also get by with storing everything in plain-text files as well. Why not, plain-text will still be supported as well.
Markdown, especially CommonMark, will likely never provide what you want. Is it convenient when you have hundreds or thousands of files to manually manage? Most likely you’ll constantly be searching for ways to make markdown work more like a word processor & CMS, because what you really want is a powerful WYSIWYG content management platform.
I’m not going to judge someone if they are content with basic markdown. It isn’t my place to. But to make a statement like, “if it is worth keeping, save it in Markdown” is preaching from a bubble.
Agree and disagree. There is a place for sophisticated management tools but when they stop getting supported or they’re purchase by a company you hate, you’re left scrambling to convert everything.
Best case for me anyway are sophisticated tools that use markdown as the basis of their files like Obsidian. So I know if they disappear I still have all my data in a universal format without any effort on my end.
The articles point was that markdown (or other similar utf-8 text based documents) is the best guarantee you have for the files being usable into the indefinite future. As you get into the complicated formats of things like word processors the less likely that format will be meaningfully usable in 10,20,50 years time, good luck reading a obsolete word processor file from the 80s today.
LibreOffice opens my old WordPerfect documents just fine. What didn’t last was the compact diskettes that some of them were lost to.
Like I said, the files are in a standardized format. You can literally extract & view the content yourself. Do you want extensively structured data in 10, 20 or 50 years, or do you want only the most basic? If something is important enough for you to save for that long, you prob should put some effort into making it useful. I’m not saying word processors are perfect, but almost every markdown editor out there is essentially trying to recreate a word processor.
CommonMark includes like 6 levels of headings, blockquotes, code blocks, bold, italics, hyperlinks, HRs, and lists? At what cost though? Which heading is the title, which one is the subtitle? Now you want to add frontmatter, which is not part of the CommonMark spec. What if you don’t want a thousand files, will your editor support multiple pages in a single file with multiple frontmatter declarations? Now you want a table, guess you’re going to deviate to GFM. What if you want to use callouts, etc.
Things like Lexical is promising:
https://playground.lexical.dev
I’d rather have a single SQLite file that has my entire knowledgebase in a useful CMS than having a thousand markdown files that I have no clue what I titled them 10 or 20 years ago. So much easier to manage, rename things, etc.
The important thing is that it needs to be in a human-readable format encoded as unicode text. Beyond that, any reasonable markup (plaintext, markdown, org-mode, HTML, etc.) is fine.
The problem with Markdown is it kind of sucks. CommonMark didn’t even defragment the markdown world, since there are numerous incompatible extensions. It seems like gfm is the best among them, or at least the most featureful.
I know there are other options like RST or AsciiDoc, but I don’t know which among them is actually “the best.”
WYSIWYG, Word Processors and CMSs are the kind of thing I don’t even want for my current content (or any content I made in the last 25+ years), why would I want any of them as an archive format?
Why not just use plain text then? I mean if your important content can be summarized into the most basic structure, why not just create your own markup format that makes sense to you? Makes no sense why you’d limit yourself to CommonMark.
Sure does; other people understand it too.
Your kids in 20 years trying to find your will, will love you.