If it is worth keeping, save it in Markdown
211–220 of 282 posts
Re: If it is worth keeping, save it in Markdown
#212Earlier 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)
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
#213Hmmm. 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.
Re: If it is worth keeping, save it in Markdown
#214Earlier 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.
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
#215The 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…
"Use RTF instead of Markdown" is one of those.
Re: If it is worth keeping, save it in Markdown
#216The 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…
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
#217Earlier 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
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
#218Earlier 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/
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
#219Just 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: If it is worth keeping, save it in Markdown
#220Earlier 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.