Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If it is worth keeping, save it in Markdown

p.migdal.pl

Post reply on HN
Print view View original

261–270 of 282 posts

Re: If it is worth keeping, save it in Markdown

#261

Post by account42 »

ysleepy wrote: post #170
geokon wrote: post #139

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…

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…

It also doesn't help that in practice most wikis install at least some parser extensions.

Re: If it is worth keeping, save it in Markdown

#262

Post by tengwar2 »

hakaneskici wrote: post #78
tengwar2 wrote: post #44

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 cause…

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

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.

Re: If it is worth keeping, save it in Markdown

#263

Post by tengwar2 »

crossroadsguy wrote: post #107
tengwar2 wrote: post #44

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 cause…

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.

Re: If it is worth keeping, save it in Markdown

#264

Post by tengwar2 »

tmountain wrote: post #194
tengwar2 wrote: post #44

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 cause…

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.

Re: If it is worth keeping, save it in Markdown

#265

Post by tengwar2 »

stared wrote: post #175
tengwar2 wrote: post #44

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 cause…

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…

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

Re: If it is worth keeping, save it in Markdown

#266

Post by tengwar2 »

bee_rider wrote: post #126
tengwar2 wrote: post #44

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 cause…

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.

Re: If it is worth keeping, save it in Markdown

#267

Post by tengwar2 »

chrismorgan wrote: post #248
tengwar2 wrote: post #44

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 cause…

> 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 prop…

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

Re: If it is worth keeping, save it in Markdown

#269

Post by tpmoney »

ThinkBeat wrote: post #174
tpmoney wrote: post #68

Earlier quoted context omitted.

The trick with burning optical media is the disks themselves can physically fail with time. I have a huge archive of various burned media from the early 00's and a number of them have developed literal holes in the material over the years. If these holes hit data tracks, the files on those tracks are lost. If you're burning to optical media, you should probably be checking them regularly for degradation.

This is true. And a real problem. In my experience hard drives, USB sticks fail and regular hard drives fail. It has been many years since I have had any involvement but backup tapes probably have issues as well, but the rapid production of new tapes and new formats is an issue already I dont have any data to evaluate the best choice is SSD drives? No matter what technology is picked, at some point to preserve the da…

Honestly, so far if you can afford the up-front investment for the space you need, and the ongoing power costs, a NAS with a RAID array (or similar redundancy scheme) that can tolerate more than one drive failure at a time is probably the best long term archival storage. Spinning rust disks in my experience rarely completely fail without warning so you can usually catch and replace failing media before data loss occurs. Additionally if you don't, I've found that recovering data from failed HDD is also usually "easier" and "cheaper" for most values of both compared to other media storage (admittedly with no experience with recovering tape media)

Re: If it is worth keeping, save it in Markdown

#270

Post by chrismorgan »

tengwar2 wrote: post #267
chrismorgan wrote: post #248

Earlier quoted context omitted.

> 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 prop…

> 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.)
Post reply on HN