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

171–180 of 282 posts

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

#171

Post by Fluorescence »

jorvi wrote: post #26
Evidlo wrote: post #17

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/

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 #. T…

> 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.
I recently implemented a commonmark parser for emphasis. Holy shit it's painful. I regret doing it but it became a battle I refused to surrender.

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* -> *this and that

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

#172

Post by Y_Y »

DidYaWipe wrote: post #159
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…

"so you can whip up a "renderer" or converter trivially at any point" And yet almost no one has...

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/

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

#173

Post by [deleted] »

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…

[deleted]

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

#174

Post by ThinkBeat »

tpmoney wrote: post #68
ThinkBeat wrote: post #34

When it comes to text (though I do include Word, PDF, text files, markdown, tex) I like to burn them to dvd. I have one of those big dvd "catalogs" that takes 4 discs per side of a page. Keep one at home and one at my parents' place. I trust them more than usb-sticks. Though that may be irrational. But the time for burning files to dvd seems almost over. It is hard /impossible to buy a computer with a dvd drive. That…

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 data it needs to be migrated to whatever comes down the line.

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

#175

Post by stared »

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

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

#176

Post by alpaca128 »

dredmorbius wrote: post #125
alpaca128 wrote: post #22

Earlier quoted context omitted.

The solution are HTML tags like

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.

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.

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

#177

Post by oneeyedpigeon »

Markdown is a wonderful format (I use it all the time) but it's very narrow and I don't think it's appropriate for storing general 'things we might publish'. You lose a lot of semantics just replacing html with markdown. For a general purpose markup language, I don't think we can beat XML.

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

#178

Post by stared »

Evidlo wrote: post #17

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/

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

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

#179

Post by oneeyedpigeon »

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…

FYI: Hacker news does allow some formatting.

https://news.ycombinator.com/formatdoc

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

#180

Post by oneeyedpigeon »

dangus wrote: post #84
hakaneskici wrote: post #78

Earlier quoted context omitted.

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.

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