Let's focus on the real issue here, which is that HN has apparently normalized the double hyphen in the title to an en dash--yes, an en dash, not even an em dash.
I agree that it should be left as a double hyphen, but an en dash is far more appropriate considering the decades-long precedent set by LaTeX (and continued by Typst).
It's a command line argument. The undeniably correct way to render it is with two minus signs[1] and absolutely not something non-ascii.
[1] Not strictly a hyphen, which has its own unicode point (0x2010) outside of ascii. Unicode embraced the ambiguity by calling this point (0x2d) "HYPHEN-MINUS" formally, but really its only unique typographic usage is to represent subtraction.
But... it's not more appropriate than an em dash for representing command line arguments? I don't see how either is any more incorrect than the other. There's a uniquely correct answer here and the em-dash is not it. Period.
It’s about the top-level comment’s horror that ”--” was substituted with “an en dash, not even an em dash”. If you’re picking a substitution for “--”, en dash makes more sense. The comment you originally replied to had already agreed “that it should be left as a double hyphen”.
> If you’re picking a substitution for “--”, en dash makes more sense.
No, it doesn't? This seems like crazy talk to me, like "If you're picking a substitute for saffron, blood plasma makes more sense than monocrystalline silicon". Like, what?
It makes zero sense to substitute this at all. It's exactly what it says it is, the "--hard" command line option to "git reset", and you write it in exactly one way.
Nobody is confused or disagrees about the `--hard` part. It was a minor tangent about contexts where these ASCII substitutions are established, like LaTeX (`` -> “, '' -> ”, -- -> –, --- -> —, etc.)
> The undeniably correct way to render it is with two minus signs[1] and absolutely not something non-ascii.
> [1] Not strictly a hyphen, which has its own unicode point (0x2010) outside of ascii. Unicode embraced the ambiguity by calling this point (0x2d) "HYPHEN-MINUS" formally, but really its only unique typographic usage is to represent subtraction.
Strictly, its as you note, the hyphen-minus, and Unicode has separate, disambiguated code points for both hyphen (0x2010) and minus (0x2212); hyphen-minus has no "unique typographic usage".
I said that badly. What I meant was that ASCII 0x2d is, in fact, used as the only minus sign in basically all markup and presentation layers. (Mostly because math layout tends to go through its own interpreter -- what lives in "the unicode text" is always "markup" of some kind). The unicode value is ignored AFAIK, nothing emits it or interprets it specially. That is not true of the hyphen, which does get special treatment at the presentation layer in fonts and whatnot.
The "sed" expressions that power the title "cleanup" here do overshoot quite often. It ruins --long-command-arguments and it definitely also reuins cpp::namespaces. Quite curious why these obvious shortcomings are not being fixed.
I really don’t! I switched it all of months ago - autocomplete, autocaps, all of
it. I reached a point where the constant frustration had to be worse than any productivity gain it was hoping to offer.
A few months on… I like
it! Frustration is all gone, any errors are just on me now, and it forces me to slow down a bit and use the brain a bit more!
No, the comment was pointing out that the HN platform automatically replaces `--` in titles with `–`. (I don’t know if that’s true, but that was the intent. Nothing to do with AI.)
