Live data from Hacker News

The Curse of Markdown

codehike.org

111–120 of 120 posts

Re: The Curse of Markdown

#111
post #61
post #48

Earlier quoted context omitted.

Any page that needs a table of contents with links to the sections.

Markdown supports TOC. Some flavors at least.

Unfortunately not the flavor I am using. Or at least it didn't when I got mad enough to switch to restructured text and a more complex build process. Where I've seen a TOC in markdown it was far too much manual effort to maintain the TOC and they tore it out some years back - but maybe better implementations exist today

Re: The Curse of Markdown

#112
post #98

Earlier quoted context omitted.

All the hoops you have to jump through with Markdown seem more awkward to me than a few extra characters.

but you jump through those hoops during setup, vs seven extra characters every paragraph

But then you just end up writing HTML anyways.

Re: The Curse of Markdown

#113
post #61

Earlier quoted context omitted.

Markdown supports TOC. Some flavors at least.

Unfortunately not the flavor I am using. Or at least it didn't when I got mad enough to switch to restructured text and a more complex build process. Where I've seen a TOC in markdown it was far too much manual effort to maintain the TOC and they tore it out some years back - but maybe better implementations exist today

I fill your pain. For example bitbucket has a total garbage instead of proper markdown renderer. No TOC, no stable header links, no navigation to anchors on first page visit, no image scaling.

But if you control documentation render process there is a number of feature-rich renderers like pandoc, mkdocs and others.

Re: The Curse of Markdown

#114

Earlier quoted context omitted.

It's a slideshow. I actually kinda like it.

Even in slideshow format there's no need for this distracting nonsense. Something like https://idlewords.com/talks/our_comrade_the_electron.htm is perfectly fine.

I actually find that much more distracting since you can see the images ahead of time, but to each their own.

Re: The Curse of Markdown

#115
post #109
post #103

Earlier quoted context omitted.

I think you're missing much of the context and are misrepresenting what happened. As far as I'm aware, there was no crying he didn't want to work with people, but there was a frustration that he was not open to having a Markdown "standard". To the point where he actively opposed efforts to standardize it, at least under the name Markdown[1]. This is legally and technically fine, as he owns a trademark for Markdown, b…

> As an open source project But it’s not an open-source project. It’s a download link to a Perl script which is never updated and effectively no one uses. There’s currently zero value to the code he wrote or the reference in his page. The only thing of worth that remains of his original implementation is the concept and the most basic syntax.

The point is Gruber was contacted out of courtesy, his name as the initial author carrying some weight in people's minds, and he reacted in an openly hostile and mocking way.

Re: The Curse of Markdown

#116
post #16

Markdown has always supported direct raw HTML in it. I don't see any gulf or sudden jump in cost. Don't be a Markdown purist. Even John Gruber, the creator of Markdown, is not a Markdown purist. Go look at the Markdown source of his blog and you will see that he frequently just uses raw HTML. He doesn't even do multi-paragraph ordered lists in Markdown, and chooses to write instead. And he also uses for clickable ima…

> I don't see any gulf or sudden jump in cost. Then you missed the core point of the article, so I'll try and rephrase it: While you're staying in Markdown-only land (the left part of the article's graph halfway down the article: low-medium richness (horizontal), very low complexity (vertical)), you are not learning HTML . You miss the "onboarding" process to the richness of HTML, so when you reach the limits of what…

You're not learning html when you write react horror shows either.

it's a space that broke because they're too useful and needed a broken react special version.

Re: The Curse of Markdown

#117
post #112

Earlier quoted context omitted.

but you jump through those hoops during setup, vs seven extra characters every paragraph

But then you just end up writing HTML anyways.

the output is html, but when you're writing markdown thought flows to output more seamlessly, with fewer characters vs with having to close italics with the more awkward . yeah in the end that goes through a tool and it outputs html, but it's about when I'm trying to get the ideas out of my head and onto the page.

Re: The Curse of Markdown

#118
post #115
post #109

Earlier quoted context omitted.

> As an open source project But it’s not an open-source project. It’s a download link to a Perl script which is never updated and effectively no one uses. There’s currently zero value to the code he wrote or the reference in his page. The only thing of worth that remains of his original implementation is the concept and the most basic syntax.

The point is Gruber was contacted out of courtesy, his name as the initial author carrying some weight in people's minds, and he reacted in an openly hostile and mocking way.

I understand that. To be clear, I was adding more context, not defending him (see above on the thread).

Re: The Curse of Markdown

#119
post #118
post #115

Earlier quoted context omitted.

The point is Gruber was contacted out of courtesy, his name as the initial author carrying some weight in people's minds, and he reacted in an openly hostile and mocking way.

I understand that. To be clear, I was adding more context, not defending him (see above on the thread).

True! I didn't realize you were the same user who sparked this specific thread. We're in agreement.

Re: The Curse of Markdown

#120
post #97

I think markdown is poorly designed, especially in terms of ease of parsing (human AND machine!) I've written my own markup language, I'd love ANYONE'S feedback, either good or bad https://lua.civboot.org#Package_cxt

Why did you make the decisions you did? My very first impression was “this looks different from Markdown for the sake of being different”. You say yours is easier to parse. Can you give some examples of when that might be try? Things like [*bold text] seem like they’d be harder to parse. (It’s hard to communicate tone here. My intent above was to sound curious, not dismissive.)

The bulk parser only needs to read a single character and only needs to care about two characters (brackets). The sub parser then looks for either {...} or a single character.

Markdown requires all sorts of complexity and it's nearly undecideable. Before CommonMark there wasn't even a spec and many things were largely ambiguous.

Also, tables and other structured data in markdown are almost entirely hacks

Post reply on HN