6 ms·

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, sti

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.

caseyy 2y ago
Markdown editors like Typora somewhat close this gap in functionality.
0x073 2y ago
* Embedded images
- e2021 2y ago
  markdown can do embedded images with data urls. It works really well, the data gets all appended at the end of the document
nicoburns 2y ago
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 2y ago
  Is this sarcasm? or are we coming back full circle unintentionally?
  - nicoburns 2y ago
    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).
    - cma 2y ago
      versus markdown it is ungreppable with all the escape codes/entities, then you have to use special tooling for search.
      - oneeyedpigeon 2y ago
        Avoid character entities—store your HTML files as UTF-8 and just embed everything.
        deleted 2y ago
        [deleted]
        cma 2y ago
        I guess that mostly works but lots of my notes have <>'s. I guess <code> covers most of that
    - colonial 2y ago
      I agree with you, but I will say that Markdown (or at least, all the major "standards" for it) support interleaving HTML both inline and at the block level. Unless you are writing a very bombastic document or want to avoid a rendering step, I'd argue that you'd be best served by just writing CommonMark with embedded HTML.
hakaneskici 2y ago
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/ 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.
- dangus 2y ago
  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."
  - hakaneskici 2y ago
    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.
  - assimpleaspossi 2y ago
    Your complaint seems to be about the editors, not HTML.
    - pimlottc 2y ago
      Unless you're willing to write your own editor, that's not really a practical distinction
    - dangus 2y ago
      Yes, my complaint is about the editors. But it's also a problem with HTML because with HTML you can implement a document that looks the same using multiple techniques, so editors will always have code generation differences.
genewitch 2y ago
The nextcloud Markdown editor shows a live view while you edit... Its called "Notes"
- briandear 2y ago
  You know what has live view all the time? RTF. What’s wrong with WYSIWYG?
  - genewitch 2y ago
    nothing wrong with it. I wasn't evangelizing, just noting that at least some developers also want dual-pane markdown editing.
  - orwin 2y ago
    Hard to parse when read as text. Heavier. Cannot read it through SSH. Need something else than your terminal. As someone who live in terminal emulators (yes, even home), markdown is more WYSIWYG than most other formats (I still think org-mode is better though)
    - lou1306 2y ago
      > Cannot read it through SSH. Need something else than your terminal. Well, for reading you can always use pandoc with stdout output and pipe it to a pager. There are also fancier options like https://github.com/Orange-OpenSource/pandoc-terminal-writer https://github.com/Orange-OpenSource/pandoc-terminal-writer (disclaimer: I contributed a small PR a long time ago)
crossroadsguy 2y ago
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.
- labster 2y ago
  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 2y ago
    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...
    - labster 2y ago
      If you’re going oral tradition, you might as well use repeatedly-compressed JPEG instead. Same quality but less space used by the storage devices.
    - drexlspivey 2y ago
      I’d suggest stone tablets
    - lou1306 2y ago
      > They either degrade Much more slowly and gracefully than any digital medium we have concocted so far (save for core rope memory, maybe). > even if preserved can become unreadable (e.g. Linear B) without a surviving linguistic community [...] translations produced with century-scale gaps often lose subtext This pertains to the message and not the support; also, I'll take missing subtext over missing text any day of the week, thank you very much.
bee_rider 2y ago
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).
- briandear 2y ago
  The fact that there is a “rendering the slides” step is the problem.
- tengwar2 2y ago
  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.
jajko 2y ago
The part about seeing the results immediately can be done easily ie via plugins in text editors like Notepad++. You have left pane with markdown text and right pane with rendered result, updated after each keystroke. I've tried 2 different plugins, they are a bit finnicky re formatting (I do a lot of bullet points in my various todo lists and a small thing can break whole block of them) and output looks a bit different, but I still prefer them. Heck, I often prefer reading markdown itself these days just for myself since the structure is already there and visible, I've learned to see those formatting characters as already sort of rendered formatting so not even looking into rendered pane that much.
bflesch 2y ago
Good point. I just noticed that RTF really looks a lot like LaTeX syntax - LaTeX was clearly inspired by it.
- sampo 2y ago
  > LaTeX was clearly inspired by it By initial release dates, LaTeX (1984) and TeX (1978) predate RTF (1987).
- deleted 2y ago
  [deleted]
- deleted 2y ago
  [deleted]
zimpenfish 2y ago
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 2y ago
  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.
WA 2y ago
Works in Commonmark: Some text and <span style="color:red">this is important</span>
deleted 2y ago
[deleted]
stared 2y ago
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.
- oneeyedpigeon 2y ago
  FYI: Hacker news does allow some formatting. https://news.ycombinator.com/formatdoc https://news.ycombinator.com/formatdoc
- tengwar2 2y ago
  > 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.
tmountain 2y ago
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.
- immibis 2y ago
  Parsing Markdown is downright everything-hostile. Computers and humans alike.
  - sevensor 2y ago
    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.
    - chrismorgan 2y ago
      > Markdown is an attempt to codify formatting conventions that were already long in use for newsgroups and email. Markdown was never really about codifying anything existing. Sure, it took a lot of guidance from existing conventions, but it also invented quite a bit, ignored quite a bit, and compromised quite a bit because of wanting to mostly sit atop HTML. The most notable deviation from custom is its link syntax, which is simply bad. Where any delimiter was necessary, the longstanding custom was to delimit with angle brackets; and Markdown did allow <https://example.com/ https://example.com/>, but its text-with-hyperlink syntax of [text](href) is highly confusing, leads to frequent errors, and makes the huge mistake of using as its delimiters characters that are valid in URLs. (In current spec terms, parentheses are in the set of URL code points <https://url.spec.whatwg.org/#url-code-points https://url.spec.whatwg.org/#url-code-points>.) This has led to all sorts of trouble. My guess is that angle brackets weren’t used because of the potential for confusion with HTML tags, though there would have been no real parser ambiguity, and autolink syntax kinda messed that argument up anyway. Then its image syntax of ![alt text](href), that’s just plain nonsense. I’d say that reStructuredText (from a little earlier) matched existing conventions slightly better than Markdown, in general. And it was much more sane, as a language, especially when you wanted to extend it. > It’s meant to be human readable first and only incidentally convertible to actual markup. If it were incidental, you wouldn’t use it—just go informal and write what suits you, it will be nicer. No, the only reason for Markdown is so that you can write HTML with a nicer syntax. It’s not incidental at all. Sure, that syntax is intended for human-readability and -authoring, but it’s essential to Markdown that it is actual markup, poorly-defined though it be as a family of lightweight markup languages <https://en.wikipedia.org/wiki/Lightweight_markup_language https://en.wikipedia.org/wiki/Lightweight_markup_language>. > Plain text is the presentation format Do you know how many README.md files there are on GitHub that are essentially HTML soup? It’s a bit sad, really. It doesn’t invalidate the intention of what you’re saying, but I would say that Markdown is noticeably less about plain text being the presentation format than it was twenty years ago.
tqwhite 2y ago
I also prefer RTF. I have tried to live with markdown's limitations several times. I simply cannot. It is standard enough but I really, really wish static websites would support it. The fact that it won't creates a huge split in my universe.
belval 2y ago
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.
chrismorgan 2y ago
> It is a more complex format than Markdown Depending on what one means by “Markdown” and how completely you want to support RTF, I might argue RTF is way simpler than Markdown. Certainly it’ll be more consistent. Markdown is far better suited for human authoring; RTF is a data format, not a markup language. And you can cut a lot of corners with Markdown and it mostly won’t bite you. But if you want to do things properly, Markdown gets rather complicated, whereas RTF stays comparatively simple after the initial parsing/serialising cost, especially if you exclude newer features like XML markup.
- tengwar2 2y ago
  > Markdown is far better suited for human authoring A lot of people are assuming that you would edit RTF manually. There's no earthly reason to do that.
  - chrismorgan 2y ago
    Oh, I’ve definitely edited RTF manually, when I wanted fine control, or to strip out certain formatting but not all. But it’s definitely not intended for manual editing; and it’s hopeless if you want to go beyond ASCII, as you can’t (from memory) just use UTF-8 or UTF-16 encoding, you need to escape non-codepage characters as \uNUMBER?, where NUMBER is the signed decimal representation of a UTF-16 code unit, which is probably the most absurd escape representation I’ve ever encountered. (The character after the number, here and normally ? these many years, represents the fallback character to use if Unicode is not supported. \uc0 can disable that so it’d be just \uNUMBER. It’s cases like that that really show how RTF was designed as an internal file format for things like Word, back before they fully supported Unicode. RTF has not aged very well as a file format.)

caseyy 2y ago

Markdown editors like Typora somewhat close this gap in functionality.

0x073 2y ago

* Embedded images

e2021 2y ago
markdown can do embedded images with data urls. It works really well, the data gets all appended at the end of the document

nicoburns 2y ago

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 2y ago
Is this sarcasm? or are we coming back full circle unintentionally?
- nicoburns 2y ago
  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).
  - cma 2y ago
    versus markdown it is ungreppable with all the escape codes/entities, then you have to use special tooling for search.
    - oneeyedpigeon 2y ago
      Avoid character entities—store your HTML files as UTF-8 and just embed everything.
      - deleted 2y ago
        [deleted]
      - cma 2y ago
        I guess that mostly works but lots of my notes have <>'s. I guess <code> covers most of that
  - colonial 2y ago
    I agree with you, but I will say that Markdown (or at least, all the major "standards" for it) support interleaving HTML both inline and at the block level. Unless you are writing a very bombastic document or want to avoid a rendering step, I'd argue that you'd be best served by just writing CommonMark with embedded HTML.

hakaneskici 2y ago

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

dangus 2y ago
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."
- hakaneskici 2y ago
  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.
- assimpleaspossi 2y ago
  Your complaint seems to be about the editors, not HTML.
  - pimlottc 2y ago
    Unless you're willing to write your own editor, that's not really a practical distinction
  - dangus 2y ago
    Yes, my complaint is about the editors. But it's also a problem with HTML because with HTML you can implement a document that looks the same using multiple techniques, so editors will always have code generation differences.

genewitch 2y ago

The nextcloud Markdown editor shows a live view while you edit... Its called "Notes"

briandear 2y ago
You know what has live view all the time? RTF. What’s wrong with WYSIWYG?
- genewitch 2y ago
  nothing wrong with it. I wasn't evangelizing, just noting that at least some developers also want dual-pane markdown editing.
- orwin 2y ago
  Hard to parse when read as text. Heavier. Cannot read it through SSH. Need something else than your terminal. As someone who live in terminal emulators (yes, even home), markdown is more WYSIWYG than most other formats (I still think org-mode is better though)
  - lou1306 2y ago
    > Cannot read it through SSH. Need something else than your terminal. Well, for reading you can always use pandoc with stdout output and pipe it to a pager. There are also fancier options like https://github.com/Orange-OpenSource/pandoc-terminal-writer https://github.com/Orange-OpenSource/pandoc-terminal-writer (disclaimer: I contributed a small PR a long time ago)

crossroadsguy 2y ago

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.

labster 2y ago
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 2y ago
  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...
  - labster 2y ago
    If you’re going oral tradition, you might as well use repeatedly-compressed JPEG instead. Same quality but less space used by the storage devices.
  - drexlspivey 2y ago
    I’d suggest stone tablets
  - lou1306 2y ago
    > They either degrade Much more slowly and gracefully than any digital medium we have concocted so far (save for core rope memory, maybe). > even if preserved can become unreadable (e.g. Linear B) without a surviving linguistic community [...] translations produced with century-scale gaps often lose subtext This pertains to the message and not the support; also, I'll take missing subtext over missing text any day of the week, thank you very much.

bee_rider 2y ago

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

briandear 2y ago
The fact that there is a “rendering the slides” step is the problem.
tengwar2 2y ago
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.

jajko 2y ago

The part about seeing the results immediately can be done easily ie via plugins in text editors like Notepad++. You have left pane with markdown text and right pane with rendered result, updated after each keystroke. I've tried 2 different plugins, they are a bit finnicky re formatting (I do a lot of bullet points in my various todo lists and a small thing can break whole block of them) and output looks a bit different, but I still prefer them. Heck, I often prefer reading markdown itself these days just for myself since the structure is already there and visible, I've learned to see those formatting characters as already sort of rendered formatting so not even looking into rendered pane that much.

bflesch 2y ago

Good point. I just noticed that RTF really looks a lot like LaTeX syntax - LaTeX was clearly inspired by it.

sampo 2y ago
> LaTeX was clearly inspired by it By initial release dates, LaTeX (1984) and TeX (1978) predate RTF (1987).
deleted 2y ago
[deleted]
deleted 2y ago
[deleted]

zimpenfish 2y ago

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 2y ago
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.

WA 2y ago

Works in Commonmark: Some text and <span style="color:red">this is important</span>

deleted 2y ago

[deleted]

stared 2y ago

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.

oneeyedpigeon 2y ago
FYI: Hacker news does allow some formatting. https://news.ycombinator.com/formatdoc https://news.ycombinator.com/formatdoc
tengwar2 2y ago
> 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.

tmountain 2y ago

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.

immibis 2y ago
Parsing Markdown is downright everything-hostile. Computers and humans alike.
- sevensor 2y ago
  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.
  - chrismorgan 2y ago
    > Markdown is an attempt to codify formatting conventions that were already long in use for newsgroups and email. Markdown was never really about codifying anything existing. Sure, it took a lot of guidance from existing conventions, but it also invented quite a bit, ignored quite a bit, and compromised quite a bit because of wanting to mostly sit atop HTML. The most notable deviation from custom is its link syntax, which is simply bad. Where any delimiter was necessary, the longstanding custom was to delimit with angle brackets; and Markdown did allow <https://example.com/ https://example.com/>, but its text-with-hyperlink syntax of [text](href) is highly confusing, leads to frequent errors, and makes the huge mistake of using as its delimiters characters that are valid in URLs. (In current spec terms, parentheses are in the set of URL code points <https://url.spec.whatwg.org/#url-code-points https://url.spec.whatwg.org/#url-code-points>.) This has led to all sorts of trouble. My guess is that angle brackets weren’t used because of the potential for confusion with HTML tags, though there would have been no real parser ambiguity, and autolink syntax kinda messed that argument up anyway. Then its image syntax of ![alt text](href), that’s just plain nonsense. I’d say that reStructuredText (from a little earlier) matched existing conventions slightly better than Markdown, in general. And it was much more sane, as a language, especially when you wanted to extend it. > It’s meant to be human readable first and only incidentally convertible to actual markup. If it were incidental, you wouldn’t use it—just go informal and write what suits you, it will be nicer. No, the only reason for Markdown is so that you can write HTML with a nicer syntax. It’s not incidental at all. Sure, that syntax is intended for human-readability and -authoring, but it’s essential to Markdown that it is actual markup, poorly-defined though it be as a family of lightweight markup languages <https://en.wikipedia.org/wiki/Lightweight_markup_language https://en.wikipedia.org/wiki/Lightweight_markup_language>. > Plain text is the presentation format Do you know how many README.md files there are on GitHub that are essentially HTML soup? It’s a bit sad, really. It doesn’t invalidate the intention of what you’re saying, but I would say that Markdown is noticeably less about plain text being the presentation format than it was twenty years ago.

tqwhite 2y ago

I also prefer RTF. I have tried to live with markdown's limitations several times. I simply cannot. It is standard enough but I really, really wish static websites would support it. The fact that it won't creates a huge split in my universe.

belval 2y ago

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.

chrismorgan 2y ago

> It is a more complex format than Markdown Depending on what one means by “Markdown” and how completely you want to support RTF, I might argue RTF is way simpler than Markdown. Certainly it’ll be more consistent. Markdown is far better suited for human authoring; RTF is a data format, not a markup language. And you can cut a lot of corners with Markdown and it mostly won’t bite you. But if you want to do things properly, Markdown gets rather complicated, whereas RTF stays comparatively simple after the initial parsing/serialising cost, especially if you exclude newer features like XML markup.

tengwar2 2y ago
> Markdown is far better suited for human authoring A lot of people are assuming that you would edit RTF manually. There's no earthly reason to do that.
- chrismorgan 2y ago
  Oh, I’ve definitely edited RTF manually, when I wanted fine control, or to strip out certain formatting but not all. But it’s definitely not intended for manual editing; and it’s hopeless if you want to go beyond ASCII, as you can’t (from memory) just use UTF-8 or UTF-16 encoding, you need to escape non-codepage characters as \uNUMBER?, where NUMBER is the signed decimal representation of a UTF-16 code unit, which is probably the most absurd escape representation I’ve ever encountered. (The character after the number, here and normally ? these many years, represents the fallback character to use if Unicode is not supported. \uc0 can disable that so it’d be just \uNUMBER. It’s cases like that that really show how RTF was designed as an internal file format for things like Word, back before they fully supported Unicode. RTF has not aged very well as a file format.)