Hacker News Reader

Comment by neonstatic | Hacker News Reader

This may be the first time my reaction to an objectively terrible programming language is a shrug and a "whatever". I like using markdown. I use it for journaling in Obsidian. It does everything I want it to. I like that it's just flat files. I don't want my journaling to be stuck in some online database.

Yet, I am the same person who refuses to code in anything but Rust due to how not-awful it feels to me. Strange how a person can hold a completely opposite view for two instances of the same problem. Being human in a nutshell.

View on HN

> Markdown in an of itself isn’t powerful enough to satisfy the simple monkey brained developer like me who is only satisfied when the site looks good enough™.

Well, indeed, Markdown is an inadequate tool for that. Let the author use more powerful tools, be it HTML, LaTeX, SVG, etc.

Markdown is fine for its intended purpose: very light formatting, very simple header structure. If I were not that lazy, i would come up with something opposite to CommonMark, some MarkDownDown, that does away with alternative ways to format things, most escaping, and most advanced syntax. The goal would be to have an easy-to-implement, unambiguous, safe and simple subset good for use anywhere. Intentionally limited.

(For daily use I prefer Org Mode, due to its vastly superior support in my preferred editor.)

> If I were not that lazy, i would come up with something opposite to CommonMark, some MarkDownDown, that does away with alternative ways to format things, most escaping, and most advanced syntax.

https://djot.net/

It makes quite a few right calls, but still tries to not be a strict subset of Markdown, requiring e.g. a different editing mode.

Being a strict subset of Markdown would make it itpossible to achieve simplicity. From the rationale:

> Rules for emphasis should be simpler. The fact that doubled characters are used for strong emphasis in commonmark leads to many potential ambiguities, which are resolved by a daunting list of 17 rules. It is hard to form a good mental model of these rules. Most of the time they interpret things the way a human would most naturally interpret them---but not always.

Indeed. I'd go with dead simple rules. The below assumes whitespace or punctuation on either side:

  *bold*
  _italic_
  *_bold italic_*
  _*also bold italic*_

Any other combination does not parse as formatting, and is considered literal text. Yes, this prevents marginally useful cases like putting an italic fragment in the middle of the word. I'd be fine with that.

If I’m understanding correctly, your rules are based on word boundaries? How do you define a word boundary?

Word boundaries are a complex thing, especially in languages like Chinese or Japanese. Whitespace and punctuation are much less complicated, even if we take the full Unicode case. So the boundary where formatting is considered is between (whitespace | punctuation) and anything else.

So now you have to distribute a character class table in every implementation of your language, which is precisely what the author of Djot wanted to avoid.

So y = x * 7 + b * c will be bolded in the middle?

If only you could just put html tags in the markdown whenever you need a bit of extra expressivity!

html comes with baggage.

---

If you're writing a parser, you might have text nodes, and bold/italics nodes which can contain each-other and text nodes. Example:

- bold node

-- italics node

--- text node

But if you add html support, you're going to run into strings like this:

text content

How easy is it for you to represent that?

What about:

not bold or italic bold but not italic bold and italic italic but not bold not bold or italic

What about:

not bold bold bold again? is this still bold? what about now?

I use a horrific mix of:

• Markdown (most of my notes these days, supplanting my previous use of plaintext.)

• Single-file HTML (when my use case for fancy documents exceeds markdown's limits. While you can embed HTML into markdown, renderers vary in what they allow or sanitize, and vary in how you can (ab)use style tags. I've even taken to looking up CSS rules for printed documents, since my intended target is often pdfs or actual print at that point. Occasionally, JavaScript!)

• Google docs (Android phone nonsense!)

I'd mutter something about "using the right tool for the right job", but that's probably giving myself too much credit.

Exactly. I write my own notes in markdown, it works with or without a viewer app. I am not even sure if there is a better alternative. This format is good enough for most of the casual and semi serious use cases

Reply on news.ycombinator.com