Live data from Hacker News

If it is worth keeping, save it in Markdown

p.migdal.pl

211–220 of 282 posts

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

#212
post #190

Earlier quoted context omitted.

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)

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

#213

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.

Org mode is great for plain text info storage. Just difficult to use if you havent joined the church of emacs

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

#214

Earlier quoted context omitted.

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.

This kind of undercuts the advantage of a semi-universal format. Though I'd agree underscore wrappers are quite reasonable and natural.

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.

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

#215

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…

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.

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

#216

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

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.

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

#217

Earlier quoted context omitted.

The biggest problem with Markdown is the baffling lack of plain VIEWERS. Not editors with a preview pane, but straight-up viewers that render Markdown for reading. There are very, very few. I use Marked 2, for Mac. I don't even remember if I ever found another one. It's irritating as hell, because pretty much every open-source project's read-me files are in Markdown. Why, when there is no viewer anywhere near as ubiq…

Agreed. I use QLMarkdown [0] for preview in Finder and this markdown-viewer extension [1] for in-browser preview. But a standalone, native app would be pretty nice too. [0] https://github.com/sbarex/QLMarkdown [1] https://github.com/simov/markdown-viewer

Thanks. Try Marked; it is exactly what I wanted. It's $14, but I decided to reward whoever did what apparently no one else (including me) can be bothered to do.

I have tried MarkText, which is yet another editor with a viewer but it's free.

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

#218
post #172

Earlier quoted context omitted.

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

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.

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

#219
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/

Re TMSU, a scan through the bug list turns up this:

https://github.com/oniony/TMSU/issues/264

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

#220
post #203
post #167

Earlier quoted context omitted.

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

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.

Sounds like powerful lock-in for Github. How could such a project ever decamp to Gitlab or Codeberg?
Post reply on HN