Hyphens, minus, and dashes in Debian man pages
lwn.net
lwn.net
Some distros like Void seem to patch this out.[1]
From mandoc/mdocml's mandoc_char(7) [2]
In roff(7) documents, the minus sign is normally written as ‘\-’. In manual pages, some style guides recommend to also use ‘\-’ if an ASCII 0x2d “hyphen-minus” output glyph that can be copied and pasted is desired in output modes supporting it, for example in -T utf8 and -T html. But currently, no practically relevant manual page formatter requires that subtlety, so in manual pages, it is sufficient to write plain ‘-’ to represent hyphen, minus, and hyphen-minus.
Which is the common-sense thing to do.
Meanwhile, GNU projects become increasingly less relevant due to obnoxiousness like this.
In general the amount of wankery of "the correct hyphen" is staggering.
[1]: https://man.openbsd.org/mandoc_char
[2]: https://github.com/void-linux/void-packages/blob/20c66829134...
There's a way more popular thing that breaks commandline snippets: auto-replace from `--` (double hyphen-minus) to `—` (emdash), in many chat applications and, particularly, on Mac OS.
The argument for having such problem is the same: "everyone is using the software wrong", but alas, some people just forget to backtick their snippets (when that's even supported).
So it's not just GNU projects; it's GNU projects where there's a good chance to actually fix such problems despite the opinion of some code authors.
Virtually any other method of inputting -- automatically, invariably converts it to a single em dash.
The best part about this is that it happens silently and automatically, unlike every other autocorrect on the platform. “Smart punctuation” can be disabled globally for the entire device, but I don’t think that’s particularly reasonable, either.
Preferably I should be able do type - - and then have it be replaced by —, and backspace to turn it into --.
(Alternatively, if text is selected, then of course I’d like to delete the selection.)
I had no trouble at all. iPhone 11, iOS 17.
Edit... as another commenter points out: it's the "smart punctuation" keyboard setting that handles this. I have it turned off...
Which itself seems like a bug, if the intended behaviour of adjacent dashes is to turn them into a long dash.
There is a similar annoying bug in Confluence (it's some weirdo corporate sort-of-wiki software), where backticks normally result in monospaced text, but if you type a closing backtick and then move to the start of the line and type the opening backtick, it just doesn't work. You get non-monospaced text, with literal backticks in it. To fix it you have to delete both of the backticks, then re-type the opening one, and then re-type the closing one.
Just yesterday, I had to fix a broken page because someone dared store a link tag in a word document, which helpfully and silently converted its quotes into smart quotes for the user.
I have a Ruby class that's whole purpose is to undo this kind of help in user provided text, but I missed a spot.
Thankfully, I've seen this happen a thousand times, so I knew what was happening. The user didn't though. And trying to explain why her quotes are the wrong kind of quotes would be impossible.
I cannot fathom the arrogance that drives the writer of any text processing application to silently replace what the user inputs, especially what they paste, with what they prefer instead. In the case of apple, they'll even delete other parts of the text if you disagree with their choice.
It's why I use notepad for almost everything and I avoid excel like the plague.
It's quite counterproductive to have someone paste a json blob in Slack/mails/etc. ending up with all with the wrong quotes, as in “string”
I don't like it either, but one seems modelled after the other.
The things the person I responded to mentioned:
> the global "Use smart quotes and dashes" and most of the text replacement gunk.
Are there keyboard layouts that have a "minus sign"? I can't find any (standard) keyboard layout that doesn't have - and has − instead (you will need - anyway for lots of contexts).
I always switch to English input if I need to type in lots of numbers since converting to half-space everytime gets annoying and feeding mono-/full-spaced numbers into text fields usually leads to the program on the backend crapping the water closet.
People want to use Unicode for everything, when some things are really typesetting abstractions that should be avoided in general purpose computing. Groff and troff have their peculiar exceptions for historical reasons, but surely in retrospect it would have been better for a hyphen minus to render as a hyphen minus rather than as a hyphen.
As far as Japanese goes, the keyboard mapping there is unfortunate. Perhaps they should have considered using a shift key or something to shift between hyphen minus and dash. And in my view those ought to be two characters with typesetting variations, not six or seven.
Technically, if not practically standard. (Yet ?)
> The specified behavior of groff is that an ASCII "-" (Hyphen-Minus) in the input becomes a Hyphen in the output.
This makes no sense and virtually any program that does similar things (ligatures, auto-emoji, formatting...) on output that will realistically be copy-pasted should burn in hell.
They may also add new options every now and then. I don't remember seeing the "Insert emojis using the colon character" option. Turned that damn thing off.
IAC Markdown and Mkdocs has been a solid platform for notes and with a private Gitea instance, all of my notes are local and private. Since MkDocs can serve the pages it produces, I can use it away from my home LAN (homelab) too, even w/out network access (though I suppose G. Docs has some way to cache documents locally. But I'd probably have to plan in advance.)
It is extremely common, if not expected, for a WYSIWYG editor to change the character that has been typed by the user to a different character which the editor thinks better corresponds to the intention of the user. That very principle is essentially wrong. And in a WYSIWYG editor, the user is not necessarily aware that this "helpful" change has taken place. In particular, the user will not be aware if the characters are visually identical.
Typesetting concerns only belong to typesetting tools. And even then, almost all these typesetting rules relating to quotes and dashes are obscure, actively debated, dependent on language and most important of all, completely useless.
”Externalizing costs onto relatively powerless consumers in the hope of using them to relay complaints to the people in power offends my sense of natural justice.”
It reminds me of the “Knee Defender” — plastic blocks designed to help airline passengers disable the recline feature not on their own seat, but on the seat in front of them. Part of the marketing copy from the manufacturer was that if your fellow passengers complain about you using these blocks then you should encourage them to complain to the airline with you, to appeal together for more space for everyone on board.
What a selfish and asinine suggestion that was. The upstream groff maintainer’s position is not dissimilar.
Why? Isn't it essentially just a stronger way of turning to the person and asking them not to recline their chair? Are you saying the person in front is entitled to to, since the chair has that function?
The same goes for curly quotes.
It's also a meaningful differentiation to be able to communicate a sentence such as:
“’struth,” he said, “she’s 5′2″ with eyes of blue.” or, “Usually, 35–40 m.p.h. is a workable and safe speed for travel—unless pedestrians are involved, in which case adjust by −20 m.p.h.”
which are far less intelligible when set with unidirectional/same width characters.
It's also useful to have the uni-directional versions ' and " for special usages in computer science contexts, while the curly forms can be used within say a .csv without the need to be escaped.
iOS and MacOS have native means of inputting the character and on Windows I have a small utility that replaces "--=" with an en-dash and "==-" with an en-dash.
Except that spaced vs unspaced and en vs em dashes are issues of British vs US English. Differences in usage as well as appearance.
It's sold as the emoji keyboard but there's a tab for symbols that includes all the dashes. This interface also has built in clipboard history too.
Distinct hyphens and minuses are necessary both due to their different meanings and due to their different traditional appearance in any typeface that does not have fixed width.
At most the en dashes could be unified with minuses, because they normally have identical appearance, even if they have different meanings.
they seem fine to me
maybe you're just used to it, and i'm used to the other it, and mine requires fewer distinct glyphs
"'struth," he said, "she's 5'2" with eyes of blue." or, "Usually, 35-40 m.p.h. is a workable and safe speed for travel - unless pedestrians are involved, in which case adjust by -20 m.p.h."
The only one that's kind of meh is the em dash in "travel—unless", which I had to replace with " - " here. But that's kind of a display issue: there's nothing stopping anything from a font rendering "<space>-<space>" as "—", just as there's nothing stopping a font from rendering "st" as "st". That these ligatures are in Unicode is a historical mistake, and I kind of see these dashes and quotation marks as roughly similar: they should be done mostly on the rendering end, whenever possible.
Note I prefer using en dashes – like this – in a lot of my writing, which looks better to my eyes than regular dashes - like this - but having to use separate dashes for an aesthetic issue like this is kind of silly, IMHO.
What people did in hand-writing varied wildly too. I betcha that in the handwriting for lots of people the "angled" quotes look pretty straight, and things like prime marks and quotes look pretty much identical, and distinguishing between "minus sign" and "dash" is even harder.
you don't easily know where the quote ends in the more complicated cases (e.g. quotes at the end of a paragraph) if you use the same marks, especially since in typography quotes aren't repeated (though maybe they should)
Having said that, there’s definitely environments (shells and the like) where you want different behavior. Though even there it’s tricky: emoji being Unicode and a lack of random rules means that emoji “just work” everywhere. Other normalization rules might wreak havoc in certain languages people don’t know about.
ASCII only for talking to the computer is a bit of an outdated concept at this point
It's not. The mapping between ASCII and keyboard keys is clear. Wherever unambiguous English text is required (for example programming and documentation), ASCII is still the best.
Each person may want to use renderers that will do fancy things, and that's fine because it's on the render side. The issue with Unicode is that it's a messy mix of presentation and data. ASCII isn't. So whenever you create a Unicode document, you are unintentionally embedding presentation information into it, and it's not the case with ASCII.
The different dashes have different uses and meanings, so it is appropriate that they have different glyphs. It is not nonsense.
Typography will continue to evolve over time. People seem to want more richness and complexity, not less. We've already moved beyond fixed-width fonts, even though that was all typewriters and early computers could do.
Typewriters didn't need multiple dash characters, because you can extend a hypen into an en-dash by typing hypen, backspace, half-space, hypen. You can make an em-dash with another backspace, half-space, hypen. Of course, computers lost half spaces and overstriking, for the most part.
Maaaaaaybe you need a separate minus from hypen, but that could be something you swap in, if needed (my typewriter has two keys that you can swap out, if you sent away for the keys anyway; not sure if smith-corona still stocks those)
And gained option and option+shift, which is even better (and many programs will auto-convert multiple hyphens to an en- or em-dash anyway).
How common was half spaces and overstriking anyway? I don't recall seeing it much, but it's been years since I've seen a typewritten letter.
Most people have already decided they prefer variable-width fonts (except when writing code) and multiple typefaces to setting everything in 12pt Courier. Using different dashes instead of just the keyboard hyphen-minus is the same issue.
Now we do our own typing, and increasingly, our own typesetting.
Less than 5% of what I'm doing is related to typography (namely: only when displaying text for the end user). 95% of the time when I manipulate text, the text is intended for a computer to process further. I don't want typographic issues such as the proper length of spaces when delimiting keywords on the command line, or proper collation order to slow down my `git grep`, any more than I want to be bothered by variable width fonts when I'm writing code.
UTF-8 to compose user visible strings in GUI is a godsend, though.
Text is not written only to be read visually by a human on printed paper. Arguably, text today is almost never used that way. What actually matters to humans is that text can be copied and pasted and rendered unambiguously. The distinction between minus-dash, dash, en dash, em dash and minus is pointless. It is literally impossible to confuse one for the other in actual usage. Same for all the 14 technically different quotes in the English language. Literally pointless to anyone but typography geeks.
These typographic rules are vestigial. We have inherited them from a time when it made no sense to limit the number of different characters used in script and it made no sense either to make it easy for a reader to figure out which typesetting blocks the typesetter put on the machine. Both of these things are now very important.
Hyphens and em-dashes have literally opposite functions. Hyphens join words together, as in compound adjectives. Em-dashes separate clauses in a sentence. (And en-dashes are used for ranges.)
They're not extremely niche — they are common and mostly obvious.
> What actually matters to humans is that text can be copied and pasted and rendered unambiguously
Yes. What is ambiguous is the hyphen-minus. It literally combines two meanings in its name.
> These typographic rules are vestigial.
They are still widely used, and still function as intended, so they are not vestigial.
> We have inherited them from a time when it made no sense to limit the number of different characters used in script
I would argue the opposite: they declined in use only because of a (temporary) limit to the number of characters available on some technologies. Thanks to Unicode the limit is removed and their use is increasing again.
Anyway, enough people seem to like all the extra dashes, and they don’t cause much harm, so I think it will be an uphill battle.
And who knows, maybe image recognition will free us from keyboards yet, and we can return to more sensible input paradigms, like pencils.
Also any modern typesetting can autoreplace what's on the keyboard, so it shouldn't stick to the bastardized version just because it's on the keyboard
That depends on fonts. In some it is represented more like minus (matching plus and center of numbers) and not like hyphen.
- The hyphen. Use it for minus and concatenation, and anywhere you need something that looks like a dash ;)
— The dash. Used to break up a sentence — mid flow no less! — and that's all. In some ways the opposite of the hyphen
And that's it, you can throw the rest away. Nobody uses them outside of fussy books, and even then the people reading them wouldn't notice their absence.
Hyphen and minus usually have a different vertical position, because hyphens should be positioned relative to the x height, whereas minus should be consistent with plus and positioned relative to the digit height.
In addition, minus signs are substantially wider than hyphens (again, like the plus sign). Minus width is often similar to en-dash width.
You want minus signs to be like the plus sign without its vertical bar, but you don’t want the plus sign and hyphen to have the same width, or same vertical position. That would just make at least one of them look awkward in context.
Sounds like you disagree, and the differences would really stick out for you?
En-dashes are used all the time (correctly) to indicate number ranges. The hyphen is too small, and just looks wrong for this use-case. e.g. 0–100 vs 0-100.