Hacker News Reader

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

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.

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.

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

You can use this bookmarklet to create new pages:

  data:text/html,<html%20contenteditable>

then save them as HTML-files.

You can use another bookmarklet to turn existing pages or files into editable pages.

You can't easily take text and make it red that way, only edit the existing content.

You can add another bookmarklet for that.

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.

> what's your offline scenario?

Keep my data out of corporate hands without needing to run a website myself (eg, a WYSIWYG site) while not having to use some different app.

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

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.

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

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.

Your complaint seems to be about the editors, not HTML.

Unless you're willing to write your own editor, that's not really a practical distinction

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.

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.

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.

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.

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.

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.

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.

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

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

> Much more slowly and gracefully than any digital medium we have concocted so far

https://arcticworldarchive.org/ would like a word

This is a high-tech vault located in the Arctic. Compare this with manuscripts that survived centuries by virtue of simply being on a library shelf in some random monastery.

Furthermore, the vault contents are stored on piqlFilm, which in turn uses Boxing barcodes [1]. So, they literally rely on an analog support.

I restm my case.

[1]: https://en.wikipedia.org/wiki/Boxing_barcode

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.

I’d suggest stone tablets

That's like saying paper is a bad record as a format, with all of punch cards, barcodese, and so on.

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.

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.

Parsing Markdown is downright everything-hostile. Computers and humans alike.

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.

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

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

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.

You don't attempt to parse it. You don't try to understand what **foo* bar* means. You just assume things next to * are bullets or emphasized and things next to # are headings.

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.

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

FYI: Hacker news does allow some formatting.

https://news.ycombinator.com/formatdoc

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

Is this sarcasm? or are we coming back full circle unintentionally?

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

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.

I'd argue that, at that point, you might as well write HTML. I find it easier to work with one format at a time rather than two intermixed and a typical Markdown document is barely more readable than its equivalent HTML document, while the latter gives you a lot more flexibility and semantic accuracy.

versus markdown it is ungreppable with all the escape codes/entities, then you have to use special tooling for search.

Avoid character entities—store your HTML files as UTF-8 and just embed everything.

I guess that mostly works but lots of my notes have <>'s. I guess <code> covers most of that

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.

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

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.

The fact that there is a “rendering the slides” step is the problem.

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.

Markdown editors like Typora somewhat close this gap in functionality.

Works in Commonmark:

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

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

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

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

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.

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

You know what has live view all the time? RTF. What’s wrong with WYSIWYG?

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)

> 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 (disclaimer: I contributed a small PR a long time ago)

nothing wrong with it. I wasn't evangelizing, just noting that at least some developers also want dual-pane markdown editing.

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.

* Embedded images

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

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

> LaTeX was clearly inspired by it

By initial release dates, LaTeX (1984) and TeX (1978) predate RTF (1987).