Come back next week, and that should all be archived (preserving all content and links) and a new site in a completely different direction begun. A pure-CSS 3D space. Lots of handwriting. A synthesised pipe organ. And lots more, over time.

TCHA of CAPTCHA is literally "tell computer human apart"

(Also, the T was nominally Turing rather than telling.)

I’m concerned, from this description, about people putting features only in a command palette, and rendering features completely undiscoverable.

This is one of the big problems of Windows’ Start Menu ever since Vista. In XP, you could find all your programs easily. Vista kinda hid them, and Windows 8 hid them a little more, and 11 hid them a lot more. They’re still there, but honestly difficult to find.

So please make sure your features are still discoverable.

Also remember that a lot of users are shockingly bad at typing. Command bars are a power user feature.

It’s always present and cannot be hidden by app developers, and so there’s no reason to not populate it, and thus the menubar serves as a consistently available master index of the program’s functions. That alone makes it invaluable.

There’s incentive for the menu bar to be properly populated with all the functions that a program offers. Mac users expect it.

Compare with non-standard Mac apps (mainly Electron apps or ports from other OS), modern Windows apps, and many Linux apps where the menu bar is often a second class citizen or completely absent, leaving you to the whims of the developer rather than enjoying conformance to a system-wide standard.

Mind you, app-defined command palettes can be better than a global one because they can provide more information and context and augment it with other widgets as appropriate. The best command palettes are not just a searchable version of the menu, they add more.

The app-defined palette enables more rich functionality as you’ve mentioned, while the system-owned global menu provides a consistent way to see everything an app is capable of without hunting and pecking through the palette. The menu also serves as a unified API for assistive and automation technology to interact with software and allows users to choose how the menus are displayed (don’t like a top-aligned menubar? Cool, your desktop can present it as window attached menus, a pie menu, or NeXT style floating menus or anything else you can imagine).

For what I wanted at the time, all that was acceptable. But as a first-generation product of a new category, I wouldn’t have tried it without that three year warranty. There were bound to be issues.

For reading, I don’t know who prefers straight quotes.

For writing—

There are more than a few people on HN who deliberately type curly quotes and other non-ASCII punctuation, due to a strong preference for them. I’m one of them.

I use Compose sequences: ; ; for left single quote, : : for left double, ' ' for right single, " " for right double.

(Accordingly, I hate being subjected to automatic curlification, partly because it’s not always correct, but more because if I typed ' or " you better believe I meant ' or ".)

Not so. You just need to be principled with your indentation, adding four spaces or one tab for every level of nesting.

  1. Here is a thing.

      - See, it works.

          Nothing is amiss.

  2.  If you want to align everything…

      -   Then it looks like this.

          Then it doesn’t seem so weird.

But what you type isn’t even mrkdwn, but rather an input mode that supports most of the same syntax.

Related reading: https://www.rfc-editor.org/rfc/rfc7763.html text/markdown registration.

No way. You were never left in doubt about whether a normal HTML tag would work, or whether tables were available or would become a jumbled illegible mess, or whether a line break in the source would become a space or a hard break. And that’s just the first three things that occur to me.

I understand it doesn't have all the extensions one might hope, but to not parse the basics like the examples in the spec say is just doing everyone a disservice.

Markdown did not come up with the idea of lightweight markup languages (LMLs). It just happened to become the most popular one, for reasons that the article doesn’t really address. There were other LMLs before and after Markdown. (It does mention Textile later on, but doesn’t mention that there were a number of others, and that it was a field that had been steadily developing.)

> What if you could just write out the text and then the link, sort of like you might within an email? Like: [Anil Dash’s blog](https://anildash.com)!

No one would ever have spelled it like that. It would rather have been either “Anil Dash’s blog (https://anildash.com)” or “Anil Dash’s blog <https://anildash.com>”.

> If mark_up_ is complicated, then the opposite of that complexity must be… markd_own_.

I’m guessing this was intended to have actual italics. (Clearly it wasn’t checked after writing, or else the third underscore would have been shifted before the d.) This shows one of the problems of Markdown. (“_anti_commercial” later has the same problem.) Also why you should prefer * for italics rather than _ when writing Markdown, because in CommonMark it allows you to mark up partial words. Throw away Prettier’s Markdown formatting, by the way, it’s terrible and if you’re not careful may destroy your content, and it insists on underscore for italics.

> Hitting the Mark

> [Stuff about Markdown becoming supported by Google Docs, Microsoft Notepad, Slack, WhatsApp, Discord, Apple Notes.]

A lot of this is wrong:

• What most of them have added is an input mode for their WYSIWYG editor which is best expressed as inspired by Markdown. If you want to actually deal in Markdown, they are always infuriatingly incomplete and incompatible. At best (and it’s never even that good) you’re only typing Markdown, not editing Markdown.

• What most of the rest of them have is a lightweight markup language only superficially similar to Markdown. Slack’s mrkdwn and WhatsApp’s formatting are this.

> The Ten Technical Reasons Markdown Won

I’ll grant 1 as valid but non-technical. 2 as valid for Markdown and less valid for other LMLs for reasons that I’ll get into shortly. 3 as valid for Markdown but also some other LMLs that already existed. 4 as valid and somewhat technical. 5 I won’t grant as distinct from 4. 6… well, the key there is actually that correctness isn’t as important as some of us would like. The flavours part of it was more a building up of technical debt. 7, 8, 9 and 10 I will not grant as reasons that Markdown won—several other LMLs already existed with the same benefits.

But it really misses out on the big reason, though 2 and 6 nudge on it:

Markdown won because it was simple, and extended HTML. It was horribly underspecified and all early implementations were all awfully buggy, inconsistent and incompatible, but it was simple and we didn’t care so much about those problems in those days (for better or for worse). People could implement Markdown themselves in an hour or two.

Nowadays, people familiar with Markdown will look baffled at some of reStructuredText’s syntaxes, but at the time I’d say Markdown and reStructuredText were similarly weird, just in different areas. When getting away from things like BBCode which was almost just HTML with square brackets, and Textile which had more idiosyncratic spellings (I mean things like “bq. ” where email had “> ” on every line), reStructuredText and Markdown were about equal.

reStructuredText is way more technically sound. It’s more capable than Markdown, and there’s none of the wild and incompatible fragmentation. But reStructuredText is heavy to implement, and if you only care about outputting HTML and only for yourself, it’s actually harder to extend—you’ll have to define a node type and extend the writer to know what to do with it, or else use the “raw” directive or role. Whereas with Markdown, you just wrote HTML and hoped for the best. Because Markdown was such a mess. But you’d get it right faster than in reStructuredText.

It’s no coincidence that there’s only one major implementation of each of reStructuredText and AsciiDoc, and only three or four total for each. They were designed for bigger, heavier things. Markdown was designed for simplicity at the cost of correctness… just like HTML was.