Live data from Hacker News

If it is worth keeping, save it in Markdown

p.migdal.pl

181–190 of 282 posts

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

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

b/c I think people start from the syntax and then think about how to parse it later?

A simple grammar probably really limits how you can design your syntax.

Here is an example of the problems:

https://roopc.net/posts/2014/markdown-cfg/

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

#182

Earlier quoted context omitted.

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.

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

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

Yeah, sorry.. i didn't mean to endorse MediaWiki. It did look kinda ugly as well.. haha

What do you recommend?

It does actually seem that djot has a grammar of sorts..

https://github.com/treeman/tree-sitter-djot/blob/master/gram...

(it's designed for a tree sitter.. I'm not super clear if it's globally usable)

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

#184
post #151

Earlier quoted context omitted.

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

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.

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

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

Markdown is already fragmented, that would just be introducing a new fragment, not a standard [insert that comic that everyone posts any time someone proposes a new standard].

The long-term solution is having whatever markdown grammar you want and converting it to a standard AST. Then anyone can create their own transformations of that AST to render whatever document they want, including a new markdown document potentially in a different grammar.

https://pandoc.org/using-the-pandoc-api.html#pandocs-archite...

https://github.com/syntax-tree/mdast

https://unifiedjs.com/

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

#186
post #65

Earlier quoted context omitted.

Why does it need to be side by side? Just let each client choose WSIWYG or raw.

When writing in text mode so that you can see what you are generating. Wouldn't really need it the other direction though.

Isn't the point of Markdown that you don't need to 'see what you are generating', you can just read it? I write Markdown every day, but I do it in a plaintext editor (with syntax highlighting). I have a keyboard shortcut to view a preview in my browser, but I don't see a great need to be viewing that preview all the time.

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

#187

I love markdown and use it for all my notes, however it really needs a native way to underline. I have been converting some older books and lectures to markdown and underline is used all the time. If anyone has a good solution I'm all ears.

The solution are HTML tags like

Ah, the good old Unarticulated Annotation element!

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/u

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

#189
post #156

Markdown is great, but not a panacea. Tables, in particular, just suck, especially if you want to have even slight formatting inside of the cells. Unfortunately, it’s either plain-text-readable or rich representation. Pick your poison.

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

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

#190

Earlier quoted context omitted.

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)

Post reply on HN