If it is worth keeping, save it in Markdown
281 comments
·February 22, 2025tengwar2
zimpenfish
I remember, a long time ago, having to try and parse text out from RTF documents and I would rather have every internal organ pecked out by sparrows than try and deal with that abomination again.
> still text-based
The point about Markdown is that you don't need a complex parser[0] to be able to interpret the files - a simple human can read a Markdown file and get the gist of what is going on. RTF has a whole mess of control strings and codes going on that get in the way of a simple visual understanding.
> I can't express simple formatting such as "make this text red" in Markdown.
You can add raw HTML to Markdown which would accomplish this (at the expense of moving away from the "simple plain text", obvs.) There's a bunch of Markdown parsers with extensions for this kind of thing though (from what I can see, they're all not entirely "simple" either which is a shame.)
torstenvl
RTF is extremely easy to parse if you assume it isn't using an ancient code page. This is a pretty safe assumption since almost no modern software even supports all the code pages in the RTF standard. Word is far more likely store Arabic in default Windows-1252 with \u_____-specified code points than to use code page 708 or something.
Is it as easy as Markdown? No. But it should take about an afternoon for a halfway competent programmer to make an rtf2txt utility from scratch that correctly handles > 90% of the RTF files you're likely to encounter in practice.
hakaneskici
Interesting. Why not HTML? Browsers have native basic WYSIWYG editing built in, and almost every screen we look at is nowadays HTML, including the code editor.
On a `<div contenteditable=true> element, calling document.execCommand('bold') will make selected text bold in WYSIWYG mode. See https://jsfiddle.net/z0umpb3x/12/ for the concept.
The main idea here is that I don't want to know any syntax like RTF, nor I want to use any tools.
inetknght
> Why not HTML? Browsers have native basic WYSIWYG editing built in
Can you point me to a page in Firefox that I can use offline to WYSIWYG edit a hypertext document without needing to use the developer console to edit raw HTML?
oneshtein
You can use this bookmarklet to create new pages:
data:text/html,<html%20contenteditable>
You can use another bookmarklet to turn existing pages or files into editable pages.
hakaneskici
I believe it's technically possible, but I don't know if there's a tool.
Btw, genuinely asking, what's your offline scenario? Long loong time ago, I used TiddlyWiki for a brief time period for my temp offline scenarios. Single local HTML, can edit, but not WYSIWYG.
jenadine
If you want to do that offline, then you shouldn't use a browser but a HTML editor. There are plenty https://en.m.wikipedia.org/wiki/List_of_HTML_editors
null
lukeschlangen
I like this approach and I’m thinking I might agree. I’ve been starting with Markdown, but find myself going to HTML. At some point I end up wanting some specific thing that isn’t supported by Markdown so I need to leave Markdown for embedding a video or adding a tiny bit of interactivity (like show/hide), so sticking with HTML throughout is nice.
dangus
I'm not the parent commenter but I'm going to guess because HTML is horrible at WYSIWYG.
If your editing tool changes or if your switch editors, they will all botch your HTML anywhere you make edits.
RTF is basically "it just works," very much like "Microsoft Word Light."
oneeyedpigeon
HTML isn't "horrible" at WYSIWYG, it just isn't WYSIWYG. Your comment is like saying "JSON is horrible at for loops"—it's just a misunderstanding of the tool.
assimpleaspossi
Your complaint seems to be about the editors, not HTML.
hakaneskici
Makes sense. I was thinking that browsers have native support for WYSIWYG editing and most browsers/apps are Chromium based; so how the browser handles HTML formatting should be stable for a single person scenario even across apps.
account42
HTML WYSIWYG editors are not going to create worse tag soup than WYSIWYG editors for other formats. If you care about how the precise HTML cod then WYSIWYG is the wrong tool.
tengwar2
HTML would be a third alternative, yes. However historically it has been less stable in its definition, and also less stable in round-trip editing by a WYSIWYG editor - it has never been been an aim for HTML to be friendly to editing at that level. In contrast there are several editors which handle RTF without disrupting it for other editors. I use TextEdit (on the Mac), but of course it it is a common word processor format. RTFD is far less well supported, but I don't normally need images. I'm not familiar with any WYSIWYG editors for HTML which represent embedded images as though they were part of the same file.
> The main idea here is that I don't want to know any syntax like RTF
Nor do I. What I want is a file format which is long-term viable, and which I can edit in a WYSIWYG editor. The underlying file format being text-based useful as a recovery mechanism if RTF ever becomes unsupported, but it's not intended that one would edit it manually
> , nor I want to use any tools.
While I do not want to edit a file format manually.
crossroadsguy
RTF isn’t a better option than MD, plaintext is. We start with the premise that we are talking about plain text, as in plain text, texts. But pretty soon we are into colours, then maybe images and videos, and then what all not.
But MD still is closest to plaintext because in most cases MD (or a similar scheme), even when not rendered, can be read easily in its plaintext formatting.
tengwar2
And again, my requirement includes colours - also bold, underline, some font support, left indent etc. It's not sufficient that a file format be long-lived - it also has to encode the information that I need. MD is poor at that, plain text doesn't even attempt it.
labster
Honestly plaintext has a pretty bad record as a format, with all of the UTF-16, Latin-2, Shift JIS, and so on. I’d suggest paper, or for true archival storage, parchment and stone.
1propionyl
Honestly paper, parchment and stone have a pretty bad record as a format. They either degrade or even if preserved can become unreadable (e.g. Linear B) without a surviving linguistic community. Even when the text survives and is rediscovered, translations produced with century-scale gaps often lose subtext or connotation that would still have registered across a narrower gap.
I'd suggest an unbroken chain of oral transmission...
account42
That's like saying paper is a bad record as a format, with all of punch cards, barcodese, and so on.
tmountain
I’m glad you found something that works for you, but it’s barely a text format from my vantage point. Parsing it is downright user hostile.
tengwar2
Which is why you use one of the many editors that understand RTF, not edit it directly. The only time you would need to touch the underlying format is if RTF becomes unsupported, which is unlikely.
immibis
Parsing Markdown is downright everything-hostile. Computers and humans alike.
sevensor
Markdown is an attempt to codify formatting conventions that were already long in use for newsgroups and email. It’s meant to be human readable first and only incidentally convertible to actual markup. If semantics are a mess and nobody can agree on how you lay out a table, I’m kind of ok with that. Plain text is the presentation format, and if you want precise conversion, drop some raw HTML or LaTeX in there. LaTeX especially has a long history of being dropped into emails between people who needed to talk about math.
TroubledTrumpet
Can you expand on why you think reading plain markdown is hostile? For the vast majority of my Obsidian vault, I could open the markdown file in Notepad and it would be just about as readable as it is in the editor. Of course, you lose the visual effect of the styling, but it's still perfectly legible.
stared
When you want to ensure that things are rendered in a particular way, Markdown might not be the best solution—it's for content, not style. In many cases (not all!), style doesn't matter much. It's better to give each device (desktop app, ebook reader, printer) flexibility of display according to user needs and preferences (dark mode, contrast, font size, fonts for dyslexia or personal taste).
HTML gives more control - from plaintext through basic formatting to building pretty much anything. This freedom can be a slippery slope - first comes red text, then custom fonts, then some SVG showing the font, and before you know it, you're building an app.
(That's one thing I love about Hacker News - they kept it simple by not allowing any formatting in posts.)
PDFs are great when you need an exact visual presentation. And yes, I keep plenty of things in PDFs. However, it is not a format I convert to too often—usually, I prefer the flexibility to reflow text for different screen sizes. YMMV.
As for RTF - I'm not sure about its current niche. It's a Microsoft proprietary format with TeX-like syntax, so for custom applications you might need to write your own parser rather than using standard tools like XML parsers. XML feels much cleaner to work with compared to the jungle of other formats we used to live in.
That said, if it works for you, great! I'm just curious why, in this case, you prefer them to a subset of HTML.
tengwar2
> Markdown ... is for content, not style
A drawback of markup languages, including TeX, is that they intermingle content and style instructions.
> RTF ... is a Microsoft proprietary format
RTF originated with Microsoft, but it's widely supported by scores of word processors and editors. I generally use TextEdit on a Mac, which supports plain text, RTF and RTFD directly. Hence you don't write your own parser: you use the editors already available. It has been around since 1987 with a high degree of stability in the core functionality, so it's a reasonable expectation that those editors will be around long-term, but if they disappear, you can get the text out.
> It's better to give each device (desktop app, ebook reader, printer) flexibility of display
For some purposes, perhaps. Not for mine: if I set text to be red, it should be red on the screen, and red on the paper. Not "emphasised" - red.
PDF is not intended as an editable format, so not relevant here.
oneeyedpigeon
FYI: Hacker news does allow some formatting.
nicoburns
HTML is also worth considering. It's not quite as nice to write in as Markdown, but it's still pretty reasonable to hand write (or even read if it comes to it).
copperx
Is this sarcasm? or are we coming back full circle unintentionally?
nicoburns
It's not sarcasm. HTML is and always has been a decent format for hand-authoring documents. It's not as nice to use as markdown, but it does support more advanced use cases like coloured text.
And if you want an "archival" format that will stand the test of time it's pretty good (so long as your text encoding is readable, HTML will be).
ajxs
When I created the SSG I use for my blog, I tested a bunch of different markup formats for the article content, but in the end I settled on plain-old raw HTML. Over the years, I've needed to render so many different specific visual elements in the blog entries that if I wasn't actually using raw HTML, I'd probably be using raw HTML snippets all over the place anyway. For another medium I might choose a different markup format, but when it comes to writing content for the web, with HTML I know exactly what I'm getting every time.
bee_rider
I don’t quite follow the first bullet point. If you are doing public speaking, your client is rendering the slides, right? Won’t you be the one interpreting “accentuate?” (So you can make it fit whatever convention you want).
tengwar2
Speaking, not producing slides. This is stuff I read aloud, and the formatting conventions such as red text are ones which fit that environment.
And yes, a rendering pass is a drawback.
briandear
The fact that there is a “rendering the slides” step is the problem.
belval
Every once in a while you encounter an opinion on the Internet that you so deeply disagree that it's not even clear how you would even start to counter it.
"Use RTF instead of Markdown" is one of those.
Evidlo
Just a note that the most common Markdown flavor (Commonmark) doesn't actually support frontmatter. The author is using presumably Obisidian-flavored Markdown (which is a mixture of Commonmark, GH-flavored Markdown, and Latex).
For file-tagging, I would consider TMSU [0] instead of writing bespoke tools. (ideally we would just use xattrs, but the world isn't ready for that)
[0]: https://tmsu.org/
thangalin
> Markdown flavor (Commonmark) doesn't actually support frontmatter.
That leads to mixing presentation logic (meta data, ToC) and content. When typesetting the Markdown, the ToC can be derived from headings and meta data should be isolated to avoid duplication. The following videos demonstrate some of the advantages to this approach:
* https://www.youtube.com/watch?v=cjQ-dle-tAE
* https://www.youtube.com/watch?v=3QpX70O5S30
See my editor's screenshots for more details:
https://keenwrite.com/screenshots.html
My FOSS editor is a cross-platform CLI and GUI application that replaces the shell scripts developed in my blog series about typesetting Markdown.
https://dave.autonoma.ca/blog/2019/05/22/typesetting-markdow...
jorvi
I like Commonmark but I wish it would have been more opinionated. They chose to allow two ways to do everything[0].
Making * always be used for bold and _ always for italicizing is so much clearer, and some Markdown flavors (notably WhatsApp) do this. So you only have to do *haha* or _haha_, which also makes italic-bold more _*intuitive*_.
Similarly they should have gone with one style of headings, probably with #.
This frees up more visual clarity. Because you are no longer using *** for bold-italic, you can use that for lines, instead of both --- and ***.
This then further frees --- up to be used for tables.
Although I imagine there's a decent subset of people that uses the alternate style of doing headings === and the 'normal' way of doing lines ---, which would have killed adoption.
And good luck convincing people to adopt a new variant at this point. "Commonermark"? "Peasantmark"? "Rabblemark" actually sounds decent.
Edit: actually, having checked the discourse around it a bit more, Commonmark wasn't created as "one Markdown to rule them all", but rather as "Venn diagram markdown with the most overlap".
Fluorescence
> Making * always be used for bold
This is probably to support potential ambiguities and intraword emphasis e.g. underscore is a common pseudo-space so doesn't support intraword use but * does e.g.
is_not_italic
this*is*italic.
It's way harder than I expected because of the combination of the ambiguity of * and ** in multi-symbol runs which support infinite nesting even of the same type of emphasis. A given delimiter run could be many different permutations of plain text `*`, `em` and `strong` depending on context of other delimiter runs that might open and close sections along side other context like punctuation, intraword-ness, flanking and whether sums of runs can be be factored by three!
https://spec.commonmark.org/0.31.2/#emphasis-and-strong-emph...
I never expected "**" could be nested emphasis instead of bold so interpretation requires multiple passes to break down delimiter runs and match them up e.g.
***this* and that* -> *<em><em>this</em> and that </em>jorvi
> This is probably to support potential ambiguities and intraword emphasis e.g. underscore is a common pseudo-space so doesn't support intraword use but * does e.g.
is_not_italic
this*is*italic.
this_is_italic
is\_not\_italicShog9
If you want strictness, use a linter or a pretty-printer that follows your preferred style. Adopting an opinionated parser means you can't lint or pretty-print input from those with different opinions (I do not like underscores for emphasis), and thus somewhat goes against the goals of TFA here:
> Markdown files are essentially plaintext with some extra syntax for common elements like sections, bullet points, and links. The format deliberately avoids precise control over display details like font selection. Following the rule of least power, I consider this limitation a feature.
One of my biggest ongoing frustrations has been MDX - a sort of markdown-and-JSX mixture whose spec is now in its third release and which has made very little effort to maintain compatibility with either CommonMark or itself. It is fairly strict and fairly elegant, and moving to a new version requires rewriting all previously-written documents to eliminate no-longer-supported syntax and re-training writers. Both of those things are miserable tasks; it has absolutely killed any tolerance I might have had for a stricter parser.
dqv
I'm surprised they didn't make a conversion tool to do MDX(old) -> AST -> MDX(new). The library support is there, but it doesn't look like anyone has created a tool to do it.
everybodyknows
> ... new version requires rewriting all previously-written documents to eliminate no-longer-supported syntax and re-training writers
Wonder if any of the LLMs could do that for you?
jimmcslim
I would just like to see Obsidian adopt MDX. I feel like there is a whole class of interactivity that could be easily implemented that way.
stared
OP here. I'm pretty cavalier about which Markdown features I use. I employ them differently in various contexts - in plain Markdown files and on my blog, for instance.
But primarily, I treat them as plaintext files. If I needed to remove frontmatter at some point, it would be a simple script. For any feature specific to a particular Markdown flavor, preprocessing, or system - I expect it to work only as plain text elsewhere.
Also, thanks for sharing about TSMU! I was thinking about similar issues—for example, a photo can simultaneously be "from 2022," "from a conference," and "emotionally important." This doesn't work well with typical nested filesystems, where we need to decide on a single folder hierarchy rather than allowing us to filter based on need (as we can in SQL).
null
everybodyknows
Re TMSU, a scan through the bug list turns up this:
myaccountonhn
Thanks for sharing tmsu, I had never seen that before.
Though I wonder what benefits it has over just plain symlinks?
hartator
The only drawback of Markdown is images.
GitHub-flavored Markdown is so popular because you can really easy inline them. You don't have to worry about storing them, linking them correctly, and you can even paste to the Markdown field.
There is no elegant solution like this in actual Markdown.
darkteflon
I would add tables to that. Obsidian has some nice extensions to make working with tables easier, but it always feels janky.
josephg
Markdown is also missing:
- Diagrams
- Math
- Any custom blocks - like Figures, algorithms, image boxes, etc
- Numbered chapters / sections (Eg Chapter 1, Appendix A, etc).
- Semantic references
For readmes, thats fine I guess. But I miss all those features when I'm writing proper blog posts, articles and documentation.
There are various hacky workarounds. But as soon as you start using bespoke markdown extensions, you're locked out of 95% of the markdown tooling out there. And everything feels so janky.
I'm looking forward to Typst's HTML output getting more mature. Typst is the only typesetting tool I've ever used that is both enjoyable to use and powerful enough for the kind of documents I want to write. It manages that by being a full on programming language. You can define variables and write custom functions for reused blocks. And there is an ecosystem of 3rd party typst packages. For a paper I wrote recently, my benchmarking tool spat the results into a JSON file. My document loaded that JSON data directly, and used the benchmarking results to populate charts and tables in the paper. It was crazy cool.
out_of_protocol
Mermaid charts! Supported by github and very readable as plaintext
https://github.blog/developer-skills/github/include-diagrams...
ozim
Markdown should not do diagrams/math etc.
People just started doing all kinds of extensions and for me that’s silly.
Refusing23
i do believe obsidian support all those (well maybe not all)
but thats added 'on top' of basic markdown, so when you open your markdown file in some other program it looks weird
hartator
Yeah, what people like about Markdown is basically regular text.
The formatting is interesting, but it’s not revolutionary or anything.
jorams
> The only drawback of Markdown is images.
> GitHub-flavored Markdown is so popular because you can really easy inline them.
I'm not sure what you mean. GitHub-flavored Markdown has pretty much exactly the same image syntax as every other Markdown flavor.
ytjohn
I think they're mixing the GH web ui with the syntax. You can paste an image right into the editor and it does a really good job of inserting it right where you need to. It is really good UX that I miss when editing markdown locally. Obsidian also does a decent job, but not quite as smooth.
everybodyknows
Sounds like powerful lock-in for Github. How could such a project ever decamp to Gitlab or Codeberg?
null
tqwhite
Also, as an old person, I will tell you that 1) I got my first personal computer in 1979 and have been trying to keep my bon mots archived ever since. I have tried a million things and have learned one key lesson: It's not really worth it.
I literally have a footlocker filled with old disk drives (remember, since 1979!) and I have never, ever gone back more than a few years, hell, more than a year.
Now that disks are big, I keep a lot of old stuff. I have, eg, screenshots dating back to 2015. Email before then. And so so much more.
I have never gone back more than a few years.
I will continue to archive because I must but, Old Person to Young People... Don't put too much effort into long term availability. It's not a good investment.
ekanes
Similar perspective, but I'd offer a minor tweak. Just as before gmail people spent a lot of time "managing" their email. Gmail allowed us to stop bothering and just use search to find stuff among the now-messy volume of email. It works pretty well.
Similarly, I'd say save everything, but spend no time on organizing it, relying on search and ai/future technology to find what you want from among the mess.
infecto
Similar thought after many years of trying to be "organized". Search is what matters, make sure the tool or format of storage allows for easy searching.
tqwhite
I'm a big fan of general search.
euroderf
> Also, as an old person, I will tell you that 1) I got my first personal computer in 1979 and have been trying to keep my bon mots archived ever since. > I literally have a footlocker filled with old disk drives
I had a private mailing list for 15 years and had emails squirreled away across several hard drives. I archived them all to my Mac, under a directory under /, and tossed the disks. Was too broke to have another disk for backups.
Then Apple decided in a upgrade to trash everything not-Apple under /. Archives gone. No warning. Really amateur move by them. Grrr.
datadrivenangel
A triage system is essential to determining your archival strategy! We can produce information faster than we can produce information storage systems, so we need to be discerning! Random gibberish is less valuable than a screenshot you took in 2015, and that screenshot from a decade ago is probably less valuable than your tax returns or your treatise on the meaning of life! If it's worth keeping, it's worth putting some time into every few years to make sure it's copied somewhere.
martin82
You might reconsider your stance. As LLMs get increasingly more powerful at making sense of all kinds of data, these old archive can suddenly become incredibly useful.
kreelman
Hmmm. I see the use in this...
For me, everything swirls in an enjoyable vortex towards org-mode.
- Literate Programming, tangle/weave
- Export to DocX, PDF, HTML
- Org-Roam
- Time Management.
Several things mentioned above are day to day. I think spectacular things are often made up of collections of useful everyday things.
SirHumphrey
Org was designed for being a PKM-like system. Markdown was designed for README.md. It doesn't mean that you cant use either for the other task, but Obsidian for example had to modify markdown significantly, to add support for tags, math, etc.
It's just a shame that org format works really well only in emacs.
terminalgravity
Org mode is great for plain text info storage. Just difficult to use if you havent joined the church of emacs
renewedrebecca
Why? I use it in VSCode and vim all the time.
lincpa
[dead]
jon_richards
The killer app for markdown would be a collaborative editor that displays the raw markdown and formatted markdown side-by-side and makes both sides editable. Tech people can use `#` and `*` on one side for formatting, product people can use normal text-editor buttons like "header1", "italics", etc.
philips
Someone is sort of building this on Obsidian: https://screen.garden
packetlost
yoooo this is sweet. Been looking for this for awhile.
r3trohack3r
I built this in college, but the code is lost. It was a week or so of hacking. I believe in you.
IIRC the trick was to get a pipeline for Markdown to HTML, render it into a WYSIWYG editor, then convert the HTML to an AST, and walk that to generate the markdown. I had to “format” both the markdown and html on each render (bidirectional round trip render) because parsing/gen wasn’t whitespace stable.
jkingsman
It's not collaborative, but this is what I love about Typora[0]. Click into a styled area and the styling becomes visible. Click out, and you just see the final styling.
Helmut10001
Typora is really a gem in the Markdown universe.
renewiltord
You can do that in IntelliJ. If there's a way to control a tab on a browser you could do that too. When I was writing my thesis, I would have `inotifywait` running on one side and when it detected the file had changed it would run the entire `pdflatex` + `bibtex` pipeline the 6 times or whatever it needed and Evince would hot-reload so I had a live preview. I'm sure a browser can do the same with some command.
jxjnskkzxxhx
Sounds like an obsidian plugin.
philips
Someone is building that: https://screen.garden
mock-possum
Notepad++ and VSC both have plugins for this.
They’re fine.
dtkav
Here's a comparison chart of collaboration/teamwork plugins in Obsidian.
https://system3.md/observatory/categories/collaboration-team...
Peerdraft, Relay, and Screen Garden are all based on CRDTs, and Obsidian is also currently working on native collaboration.
(disclaimer: I work on Relay)
Helmut10001
Unfortunately, all of these are not self-hostable. I wish there was something like Nextcloud for Markdown Collaboration.
dtkav
Relay now supports self hosting the collaboration server. It works with tailscale out of the box.
We still have a centralized service for authentication and authorization, but if you self host it is impossible for us to access your files.
_hhnj
HackMD already does this. It has a dual-pane view for raw markdown and formatted output, supports WYSIWYG editing, and allows real-time collaboration. Surprised no one mentioned it.
- [HackMD: Your Collaborative Markdown Workspace for Knowledge Sharing](https://hackmd.io/)
pphysch
Why does it need to be side by side? Just let each client choose WSIWYG or raw.
david422
When writing in text mode so that you can see what you are generating. Wouldn't really need it the other direction though.
oneeyedpigeon
Isn't the point of Markdown that you don't need to 'see what you are generating', you can just read it? I write Markdown every day, but I do it in a plaintext editor (with syntax highlighting). I have a keyboard shortcut to view a preview in my browser, but I don't see a great need to be viewing that preview all the time.
geokon
It feels like a long term solution would be to use a markdown that is both easy to write (not RTF or XHTML), but has a defined grammar in some standard format (ex: EBNF). Most platform/languages will have a parser and so you can whip up a "renderer" or converter trivially at any point.
The only markup I'm finding with a grammar is MediaWiki (sort of..)
https://www.mediawiki.org/wiki/Markup_spec
Even Djot doesn't seem to have one. Weird..
ysleepy
MediaWiki has one of the worst syntaxes and formalisations out there. I've been trying to render wikipedia pages on and off for more than 10 years and there is no independent parser covering the whole syntax and magic behaviour.
https://www.mediawiki.org/wiki/Alternative_parsers
There is only parsoid, developed for the visual editor and that took pretty much a decade to build with much pain and suffering.
This is not the answer.
account42
It also doesn't help that in practice most wikis install at least some parser extensions.
geokon
Yeah, sorry.. i didn't mean to endorse MediaWiki. It did look kinda ugly as well.. haha
What do you recommend?
It does actually seem that djot has a grammar of sorts..
https://github.com/treeman/tree-sitter-djot/blob/master/gram...
(it's designed for a tree sitter.. I'm not super clear if it's globally usable)
dqv
Markdown is already fragmented, that would just be introducing a new fragment, not a standard [insert that comic that everyone posts any time someone proposes a new standard].
The long-term solution is having whatever markdown grammar you want and converting it to a standard AST. Then anyone can create their own transformations of that AST to render whatever document they want, including a new markdown document potentially in a different grammar.
https://pandoc.org/using-the-pandoc-api.html#pandocs-archite...
DidYaWipe
"so you can whip up a "renderer" or converter trivially at any point"
And yet almost no one has...
Y_Y
To be fair, one there's a good one there's much less incentive to write something new. In this case the good converter is Pandoc: https://pandoc.org/
DidYaWipe
Thanks; but that's a converter, not a viewer.
The problem is the lack of READER applications to simply view (not edit or convert) all these Markdown documents.
geokon
b/c I think people start from the syntax and then think about how to parse it later?
A simple grammar probably really limits how you can design your syntax.
Here is an example of the problems:
asielen
100% agree. I've been using markdown for a few years after moving away from proprietary note taking apps. Although this has led to me developing my own short hand for many things in my notes. And have been looking at a way to integrate a to-do list with my notes with some Python scripts.
So while my notes may rely on some personal scripts to get there most value out of them, I strongly value that they are still plain text and I can always move them into a new workflow if I need to.
Onawa
Maybe consider Quarto? Free and open source, integrates Python scripting directly in Markdown and/or able to call from separate scripts.
darkteflon
Love Quarto. I write all my notes, presentations, blog posts, memos, etc in .qmd files. For non-technical stuff I use Obsidian to author (there is an extension which tells Obsidian to treat .qmd as ordinary markdown - ie ignoring the additional Quarto frontmatter and so on), then for everything else I use VS Code with the Quarto extension and just render out to the display format I need. I really appreciate that it’s built on Pandoc and it means I can just use one format and one set of tooling for everything.
asielen
Thanks for the recommendation! Sounds interesting
normalaccess
I love markdown and use it for all my notes, however it really needs a native way to underline. I have been converting some older books and lectures to markdown and underline is used all the time.
If anyone has a good solution I'm all ears.
ambivalence
Markdown is plaintext so you decide what it means. I personally write *italic* and **bold**, so I can use _underline_. Most Markdown to HTML converters would make the last example into italic, but you can customize many of them.
Commonmark doesn't even mention "bold", "italic", and "underline". It just says "emphasis" and "strong emphasis". You can style it however you want.
paulryanrogers
This kind of undercuts the advantage of a semi-universal format. Though I'd agree underscore wrappers are quite reasonable and natural.
ratorx
Markdown isn’t really meant to be a universal markup format. Its primary goal is to document conventions of annotating plain text which keep the plaintext semi-consistent and readable.
So the purpose of , * etc is purely emphasis. If you need to represent something specific (bold, italic etc) then that’s a job for the Markdown parser (or embedded HTML etc). The result of the parser (HTML, etc) will be less human readable, but actually able to specify formatting.
I agree that CommonMark could be extended, but I think the focus should be on semantic* relevance rather than markup specification.
voltaireodactyl
I love the Fountain spec for exactly this reason. I primarily began using it since it’s Markdown for screenwriting, but it has bold, underline, and italics along with the usual markdown stuff like comments etc. I find it to be by far the best way to write plaintext anything other than code. It’s also a bit more opinionated than Markdown which I highly prefer.
Tagbert
it might depend on what you want to do with the underline. Does it just indicate some kind of emphasis?
Could you use the convention in your documents that "_" is the underline delimiter? I know that the default is to render it as italic/emphasis but that is just a decision at rendering time. The semantics of emphasize/underline could easily overlap.
Of course if you want 3 levels of emphasis with bold, italic, and underline, then yes you need to look elsewhere.
Markdown isn't really a formatting tool. it is a way to structure text in the minimal way that a person would interpret it and a machine could render it.
fsckboy
>converting some older books and lectures...If anyone has a good solution I'm all ears.
I don't know if this helps you, but you said "older": in the 20th century world of typewriters--which had no italics--underlining was used as a substitute for italics. Transforming underlines to italics or going the other way was considered normal. You wouldn't use both in the same document.
dredmorbius
There's notional underlining, which in typewritten documents is effectively the equivalent of italic, and there is typographical underlining, where "underline" means "there is a line under this element and/or text".
Both matter, and although Markdown flavours handle the notional case well, they fall down at this (and several other) typographical capabilities. Expressing text in a particular colour (or greyshade) is another example. It's possible to achieve this in practice through embedded HTML and/or CSS tags, or through augmented Markdown variants (Pandoc's Markdown can achieve some things CommonMark or DaringFireball Markdown cannot).
Ultimately though I find I need to switch to a more capable and consistent text-layout engine, usually LaTeX in my case.
Though for even quite large and modestly complex works, Markdown is either sufficient entirely or is useful in getting the work off the ground before switching to a more powerful option.
fsckboy
i said "typewriter", and there is only one kind of underline on a typewriter.
converting old typewritten notes, they may contain typewriter underlining, and it may represent italics. Markdown would be entirely sufficient to handle that.
there was no need to de-clarify my comment.
alpaca128
The solution are HTML tags like <u></u>
dredmorbius
Markdown is often, and was originally intended for, HTML generation. But that's not the only target which can be achieved, particularly with such tools as Pandoc, a document format interchange Swiss Army knife.
Relying on format-specific tags imposes stronger constraints on endpoints and/or increases complexity of your document build process.
alpaca128
Inline HTML is part of the standard Markdown syntax, not a complication. If your tool doesn't support HTML it doesn't support Markdown. The format can be so simple in the first place because it allows this escape hatch for anything non-trivial. And tools like Pandoc can handle that just fine.
oneeyedpigeon
Ah, the good old Unarticulated Annotation element!
grimui
Not the best solution but you could use the HTML underline tag
ambivalence
I wholeheartedly agree with this post. I also keep my notes in Markdown, I also have plenty of Python scripting around them, including automatic publishing of my website.
I use FSNotes today on macOS and iOS. Both apps are open source, both use well-structured .textbundle directories that separate Markdown content from JSON metadata and binary attachments. Synchronization happens through Git. It's a very powerful combination.
Ironically, I wrote a blog post some 8 years ago about this very subject. That blog post is now offline.
ydant
I appreciate the mention of FSNotes (and in turn textbundle). Somehow, despite trying tons of note taking apps and formats, I don't remember ever coming across mention of this format specifically.
My biggest beef with org mode and all of the markdown apps I've tried is the asset management problem. For me screenshots are almost as important as the text part of the note, and are usually strongly tied to a single note. I've taken to using apple notes at work just because it "solves" that well enough, but I'd really prefer to work in markdown/plain text (except for the images).
xenodium
I built Markdown to web, drag and drop solution: https://lmno.lol
Here's a demo https://www.youtube.com/watch?v=SykbiVweYH8
roxolotl
I’ve been self hosting linkding[0] and it has archiving capabilities. Saves in html not markdown but that’s basically the same thing. It’s been very useful and then I back the folder up to R2 for free. I enjoy knowing that if I find something I want to remember it won’t go away. Plus it works great for recipe sites because I don’t have to deal with ads.
youainti
I love linkding. I try to add sites to it whenever I'm tempted to just keep the tab open for later because it is cool.
The other major alternative to consider is RTF. I standardised on that about 10y ago, planning for a 30y horizon. It is a more complex format than Markdown, still text-based, but biased towards WYSIWYG presentation and editing, while Markdown is usually not WYSIWYG in the editor. Both formats suffer from a lack of standardisation, though Markdown seems to have more problems in practice - I've never had an issue caused by RTF incompatibility. Both are very widely supported. Both formats are very widely supported and it can reasonably be expected that this will continue.
I prefer RTF for two main reasons:
* I can't express simple formatting such as "make this text red" in Markdown. No, I don't mean "accentuate this text and leave the decision on how it looks to someone else", I really do mean "make this text red". I do a lot of public speaking, and I want to keep to certain conventions which are easy to read fast.
* Most of the time I am writing text, not reading a version after it goes through a formatter, so I prefer to see it formatted on screen. That's really a limitation on Markdown editors, but it's almost universal so for my point of view, it counts.