I am not sure (and too lazy to check) if the issue is with groff vs mandoc (the typesetters) or instead with tmac.an aka -man vs tmac.doc aka -mdoc (the macro packages, one presentational, the other semantic) — note the confusingly similar names. I understand the BSDs have been switching their pages to -mdoc for the most part, but on a typical Linux system you’ll find both used quite a lot (and even for GNU software, most though not all will not have come from the GNU project, what with that project being actively hostile to man pages).
There is a footnote from Robinson along the lines of "well, actually, see, mdoc isn't that great" but I'm not sure it makes a compelling case for troff, either.
I mean, -mdoc is so much nicer to write than -man, and the mandoc utilities from OpenBSD are so much nicer for rendering man pages than full fat groff…
> Mapping all hyphens and minus signs to a single character, as people whose blood pressure spikes over this issue tend to promote as a first resort, is an ineluctably information-discarding operation. In my opinion, man page source documents are not the correct place to discard that information.
Treating all dashes as minus signs within the context of man pages sounds perfectly fine to me (even though it can be unacceptable in other situations). I see man pages as a sort of an extension of code, be it shell code or C code. If hyphens started to creep into my code I'd be furious.
At a technical level, yes, okay. At a human level? No.
To a human reading the man page, these characters look basically identical on screen. Sure, one is sometimes, in some fonts, a bit bolder and/or a bit of a different length - but even when that’s true it’s hard to discern without context. So an actual _reader_ of these characters depends on context to know what one they’re seeing anyway. Literally no information is lost between the source text and the reader by using either.
Just use minus signs in the man pages. Trying to force everyone to care about the difference between dash/hyphen/minus sign is an unwinnable battle. There’s only one key on their keyboard, and that’s what they’re going to press. And there’s not enough context to do anything automatic to correct it.
You could maybe make an argument about accessibility for screen readers - but I’m pretty sure they’re always going to have to cope with minus-sign-as-dash for ever too (see argument about humans using keyboards, and the inability to do anything automatic to correct it).
The only actual, real-world, outcome _worth caring about_ of treating these differently is that, if they are treated differently, people can’t search for or copy/paste command line arguments.
Using minus signs is the better choice for most people.
In the fonts I use, I've never noticed a difference between hyphen/dash/endash/minus. But (as alluded to in the intro of the submitted message) some fonts will render it differently. I would not be surprised if various screen-reading software handles them differently.
So for some people, rewriting all of them into '-' would be information-discarding.
(However, I'd not be surprised if there are more "incorrect" hyphen/dash/minus issues in many code bases than "correct" ones...)
See also blogs where double hyphens in shell script examples have been automatically converted to em-dashes, and source code rendered in a monospaced font with monospaced ligatures like “fl”. The latter not only fails copy/paste, it’s a typographical tragedy. Even Communications of the ACM does it, in a printed magazine with supposedly professional designers!
I've configured uBlock Origin to block remote fonts and aside from some icon fonts failing to load, it made my browser experience a lot better. Especially after picking a better monospace font for code blocks (IntelOne Mono in my case).
Windows itself won't, but have you ever tried copying code into a microsoft application and found that it didn't paste like it should and then fixed the escaping?
It will fuck the code up so bad that Ctrl+Z and starting over is your only option.
It’s a function of the application, not the OS (though I see your point, the basic Mac text box does do it by default, unlike the Windows one (even in W11?)). MS Word will do the curly quote conversion on any OS. I’d guess it’s InDesign doing the ligatures in printed/PDF magazine articles, which would happen on any OS. Same is true with WordPress or a Markdown converter. There’s always an app preference somewhere to make this not happen, but people don’t bother finding it.
I expected this to be about hyphenation, which (as i just realized and checked) breaks search because it won't find hyphenated words. I'm "happy" to see it's an entirely different and another problem.
At a terminal, when I type on my keyboard the key that physically has the symbol "-" written on it:
... $ echo -n "-" | hexdump -C
I get 2d. That's ASCII. It's minus sign.
Case closed. Anyone arguing for Unicode hyphen should be shot dead on the spot, no trial.
P.S: I hope it's not lost on people that both echo and hexdump took a parameter here, and that that parameter was passed preceded by the ASCII minus sign. Which is the whole point.
- Common blocks (like option descriptions) which apply consistent combination of rules above
Everything else should be plain text, just like the the computer code or shell commands.
(There is an interesting question of why is bold text accessible in manpage but not in code.. I think the answer for that is code's equivalent is syntax highlighter. Computer languages are regular enough that we can have computer highlight various syntaxical elements; while human languages are not, so we need to ask manpage authors to highlight them for us)
In the overwhelming majority of fonts, it’s not a minus sign, as you can see from it being vertically positioned in the middle of a lowercase n instead of in the middle of a lining digit, like the plus sign is. (Neither is it a dash, being both too short and too thick.) It’s a weird hybrid of a hyphen and a minus that was introduced on typewriters to save a key and the accompanying mechanics. (For the same reason and with about as much respect for typography, many of them neglected to have numerals 0 and 1 separate from the Latin capital letters O and I.)
Unicode, unlike typewriters and ASCII, but following half a millenium of book printing tradition, encodes a hyphen and a minus separately. (Also a number of dashes, though perhaps fewer than medieval printers used.) The weird thing it resorts to calling HYPHEN-MINUS also has to be encoded and will probably persist in computer code (including Unix program arguments) forever, but in texts targeted at humans it has no place. The inadequacy of your (and my) keyboard is regrettable, but doesn’t really make for a great argument here.
Because readability is really important. We can't do much to improve monspaced environments such as the terminal, but most documentation, even man pages, is read in the browser. Using an ASCII ‘-’ to indicate a minus sign in a mathematical expression is quite bad for readability. It is usually less of a problem to use it as a hyphen, but a real hyphen will generally look better.
For command-line parameters, yes. For everything else, I can understand that the writer would want to express more semantics in the character than just 'minus'.
In fact, I would guess that anything else than 2d as a command-line parameter prefix is a bug (bar using a /).
That said, normalization when searching is useful.
There is a way, of course, of getting the correct hyphen-minus, and that’s by using ‘\-’. Almost all manual pages do this, including manual page generators, because the “problem” (which is just troff syntax) is well known and well documented.
It was just a couple of weeks ago that I got annoyed by "man ascii" on some Linux system showing me a dash instead of an apostrophe for character 39. Of course it wasn't actually a dash, but it was an apostrophe converted somehow into a character 180 (which in ISO 8859 is an acute accent), at least that's what "man ascii | hexdump -C" told me. My terminal settings were set in such a way that it came out as a dash.
How exactly it got to be a dash is not really the problem. What it should show is a character 39 apostrophe, because that's exactly what it should be showing there! Ironically, the character 45 dash is shown for me as a character 45 dash, just as it should.
For those interested, I had to learn this stuff and following are the usual suspects in these typographical crimes, in English:
* U+002D: Hyphen-minus "-": The old ASCII character that appears when you press the key on your keyboard, at least on a US keyboard. Per Unicode, "used generically for hyphen, minus sign or en dash". Recall that ASCII had only ~96 'codepoints', as we now call them, available for characters, so many characters were designed for multiple uses, such as quotes, used for open and close quotes; carot '^', tilde '~', etc. used also as diacritics; and the uber-flexible hyphen-minus-en dash (and unofficially em dash, half-em dash ('--'), and univeral horizontal line). Also, recall that typewriters only had one hyphen-dash-minus character.
* U+2010: Hyphen: "‐": Specifically a hyphen and nothing else. Typographically, hyphens are just a bit shorter than en dashes. Grammatically, a hyphen demarcates a boundary within a term, such as compound words ('editor‐in‐chief'), phone numbers (555‐555‐5555), etc.
* U+2013: En dash: "–": Typographically, half an em dash, slightly longer than a hyphen. Grammatically, en dashes show a continuous range, e.g.: 'October–December', 'pages 15–93', and, if I don't misunderstand, 'London–Paris train', etc. It's also used in some grammatical and typographical edge case circumstances. Also, of interest only on HN: "typographers sometimes use U+2013 en dash to represent the minus sign, particularly a unary minus"
* U+2014: Em Dash "—": Typographically, twice the length of an en dash, reputedly the width of a capital 'M'. Grammatically, em dashes show a break: '"No, no, not the—" ("Yes—the Spanish Inquisition!")'. Also commonly used for parenthetical-style breaks in sentences: 'The Spanish Inquisition—ubiquitous, omniscient, or so they say—was always unexpected.' Finally, used for attribution: '"The only thing we have to fear is fear itself." — Eisenhower'. Also some odd, edge case uses. And because you asked, "In older mathematical typography, U+2014 em dash may also used to indicate a binary minus sign."
* U+2212: Minus sign: "−"
There are many more—Double Oblique Hyphen anyone? Search around Unicode, for example, for 'dash'.
Sources: Unicode documentation, Chicago Manual of Style, maybe other similar sources. The summaries of their functions, based on those sources, are mine.
* In my experience, the hyphen is usually very short in most fonts, the en dash is significantly longer, and the em dash can be much less than double the en dash (some of this may be a result of poor font design though. Monospace fonts have it rough!).
* It's widely recommended to avoid writing U+2010 and just use U+002D for hyphens. Hyphens are by far the most common of these punctuation symbols, so it's ludicrous that `man` pages to map them by default; most man pages will never want any kind of dash.
* Soft hyphen support sucks.
* For different reasons, it's rare to manually write U+2212, since you should generally tell your typesetting engine to switch to math mode (which also takes care of inserting the right obscure kinds of spaces).
* En dash is also used as a higher-level hyphen, when the inputs are already compound (not necessarily with hyphens!).
* En dash with spaces around it is an alternate style equivalent to em dash without spaces, for uses like a comma/colon/reverse-colon/parenthesis. A given work should only use one for consistency. In casually written text, space-asciidash-space is almost always intended as an en dash.
* Em dash is also the thing to use for interruption; there are several subcases here. This is the only time an em dash can potentially touch a space, though except for self-interruption they're generally inside quotes so won't actually.
* When there's a parenthetical interruption by the narrator, the em dash goes outside the quotes (“Foo”—bar—“baz”).
* Em dashes are also used for attribution after a quote, or for signatures. This is supposed to always be the start of a line, but if you're sloppy I guess it might be preceded by a space here too.
* U+2012 figure dash is probably the only other dash worth knowing; use it with digits. There's also a "figure space" you should use for monospace-like padding in a non-monospace font.
> Em dashes are also used for attribution after a quote
I believe the correct code point for quotation attribution is U+2015 HORIZONTAL BAR:
> The Unicode standard introduced a separate character U+2015 ― HORIZONTAL BAR to be used as a quotation dash. It may be the same length as an em-dash, which is often used instead. Some software will insert a line break after an em-dash, but not after a quotation dash.
I was talking about attribution, not obscure (apparently standard in some languages, but not in English) quote styles. Attribution (including signatures) is always an actual em dash.
I don’t know what you mean by “obscure quote styles”. Did you read the link? You’ll see that it includes
> Em-dash, an alternative to the quotation dash
You confidently asserted the em-dash as the correct choice for quotation attribution which, if not outright incorrect, is certainly not the most or the only canonical choice. Nothing obscure in style about it!
The point is that a "quotation dash" (i.e., a dash that precedes a quotation, used in place of or accompanying quotation marks in many languages, as your link explains) is not the same thing as the dash used for quotation attributions.
An em-dash is an alternative to a proper quotation dash when used to precede a quotation, but is generally itself considered the proper dash for attribution [0].
Imagine how many people must have been unjustly accused of not RTFMing because of this bug. Maddening.
It's preposterous that we have to resort to such primitive text search methods just to find the information for command line arguments. We've had hypertext for 3 decades now; why aren't they just listed in a table of contents and then you can follow the links to the detailed descriptions? I always seek out HTML documentation whenever I can; man pages are a last resort.
The problem is search functions. Unicode has been standard for awhile; I seem to recall some open source normalization-of-punctuation code.
If your search function/engine doesn't find all the horizontal lines characters when the user types ASCII hyphen-minus, you're generating false-negatives.
Isn't there some open source code that takes care of this universal problem? It's not just hyphen/minus/dashes. There are quotation marks, diacritics, and more.
There's the counter-issue of trying to search for some specific character, and instead matching the generic one. For example, searching "ā" on chrome or firefox finds all "a"s, which is extremely annoying if there's one "ā" on a page you want to find, and thousands of "a"s everywhere.
For dashes, if done right, it could be useful to be able to search the separate ones too - i.e. search for flag dashes but not ones in prose.
> For example, searching "ā" on chrome or firefox finds all "a"s, which is extremely annoying if there's one "ā" on a page you want to find, and thousands of "a"s everywhere.
For reference, the ‘match diacritics’ option on Firefox toggles this behaviour.
(It’s slightly misnamed, actually, since it’s more expansive than just diacritics: it also matches things like Unicode dashes for ASCII dashes, and so on.)
Ah right, Firefox does have a nice option for this. I happened to check Chromium on desktop, but Firefox on Android (which were the browsers I had open already), which doesn't have this option.
No, that's not it; there are some further issues mentioned in the thread and the linked bug reports, like man pages containing command line options that can't be copy/pasted into a terminal (because they consist of Unicode hyphens).
55 comments
[ 3.1 ms ] story [ 121 ms ] threadFunny at that, too: https://lists.debian.org/debian-devel/2023/10/msg00085.html
> Mapping all hyphens and minus signs to a single character, as people whose blood pressure spikes over this issue tend to promote as a first resort, is an ineluctably information-discarding operation. In my opinion, man page source documents are not the correct place to discard that information.
Treating all dashes as minus signs within the context of man pages sounds perfectly fine to me (even though it can be unacceptable in other situations). I see man pages as a sort of an extension of code, be it shell code or C code. If hyphens started to creep into my code I'd be furious.
At a technical level, yes, okay. At a human level? No.
To a human reading the man page, these characters look basically identical on screen. Sure, one is sometimes, in some fonts, a bit bolder and/or a bit of a different length - but even when that’s true it’s hard to discern without context. So an actual _reader_ of these characters depends on context to know what one they’re seeing anyway. Literally no information is lost between the source text and the reader by using either.
Just use minus signs in the man pages. Trying to force everyone to care about the difference between dash/hyphen/minus sign is an unwinnable battle. There’s only one key on their keyboard, and that’s what they’re going to press. And there’s not enough context to do anything automatic to correct it.
You could maybe make an argument about accessibility for screen readers - but I’m pretty sure they’re always going to have to cope with minus-sign-as-dash for ever too (see argument about humans using keyboards, and the inability to do anything automatic to correct it).
The only actual, real-world, outcome _worth caring about_ of treating these differently is that, if they are treated differently, people can’t search for or copy/paste command line arguments.
Using minus signs is the better choice for most people.
So for some people, rewriting all of them into '-' would be information-discarding.
(However, I'd not be surprised if there are more "incorrect" hyphen/dash/minus issues in many code bases than "correct" ones...)
I would be a little bit less repulsed by them if they took up the right amount of space, but they’d still be an abomination.
Windows doesn't do that.
Mac also changes quotes, like
toIt will fuck the code up so bad that Ctrl+Z and starting over is your only option.
Case closed. Anyone arguing for Unicode hyphen should be shot dead on the spot, no trial.
P.S: I hope it's not lost on people that both echo and hexdump took a parameter here, and that that parameter was passed preceded by the ASCII minus sign. Which is the whole point.
- Wrapping the lines to terminal window width
- Indenting blocks
- _Basic_ formatting (bold, underline - OK, colors - NO)
- Common blocks (like option descriptions) which apply consistent combination of rules above
Everything else should be plain text, just like the the computer code or shell commands.
(There is an interesting question of why is bold text accessible in manpage but not in code.. I think the answer for that is code's equivalent is syntax highlighter. Computer languages are regular enough that we can have computer highlight various syntaxical elements; while human languages are not, so we need to ask manpage authors to highlight them for us)
Unicode, unlike typewriters and ASCII, but following half a millenium of book printing tradition, encodes a hyphen and a minus separately. (Also a number of dashes, though perhaps fewer than medieval printers used.) The weird thing it resorts to calling HYPHEN-MINUS also has to be encoded and will probably persist in computer code (including Unix program arguments) forever, but in texts targeted at humans it has no place. The inadequacy of your (and my) keyboard is regrettable, but doesn’t really make for a great argument here.
let us not judge
In fact, I would guess that anything else than 2d as a command-line parameter prefix is a bug (bar using a /).
That said, normalization when searching is useful.
How exactly it got to be a dash is not really the problem. What it should show is a character 39 apostrophe, because that's exactly what it should be showing there! Ironically, the character 45 dash is shown for me as a character 45 dash, just as it should.
* U+002D: Hyphen-minus "-": The old ASCII character that appears when you press the key on your keyboard, at least on a US keyboard. Per Unicode, "used generically for hyphen, minus sign or en dash". Recall that ASCII had only ~96 'codepoints', as we now call them, available for characters, so many characters were designed for multiple uses, such as quotes, used for open and close quotes; carot '^', tilde '~', etc. used also as diacritics; and the uber-flexible hyphen-minus-en dash (and unofficially em dash, half-em dash ('--'), and univeral horizontal line). Also, recall that typewriters only had one hyphen-dash-minus character.
* U+2010: Hyphen: "‐": Specifically a hyphen and nothing else. Typographically, hyphens are just a bit shorter than en dashes. Grammatically, a hyphen demarcates a boundary within a term, such as compound words ('editor‐in‐chief'), phone numbers (555‐555‐5555), etc.
* U+2013: En dash: "–": Typographically, half an em dash, slightly longer than a hyphen. Grammatically, en dashes show a continuous range, e.g.: 'October–December', 'pages 15–93', and, if I don't misunderstand, 'London–Paris train', etc. It's also used in some grammatical and typographical edge case circumstances. Also, of interest only on HN: "typographers sometimes use U+2013 en dash to represent the minus sign, particularly a unary minus"
* U+2014: Em Dash "—": Typographically, twice the length of an en dash, reputedly the width of a capital 'M'. Grammatically, em dashes show a break: '"No, no, not the—" ("Yes—the Spanish Inquisition!")'. Also commonly used for parenthetical-style breaks in sentences: 'The Spanish Inquisition—ubiquitous, omniscient, or so they say—was always unexpected.' Finally, used for attribution: '"The only thing we have to fear is fear itself." — Eisenhower'. Also some odd, edge case uses. And because you asked, "In older mathematical typography, U+2014 em dash may also used to indicate a binary minus sign."
* U+2212: Minus sign: "−"
There are many more—Double Oblique Hyphen anyone? Search around Unicode, for example, for 'dash'.
Sources: Unicode documentation, Chicago Manual of Style, maybe other similar sources. The summaries of their functions, based on those sources, are mine.
* In my experience, the hyphen is usually very short in most fonts, the en dash is significantly longer, and the em dash can be much less than double the en dash (some of this may be a result of poor font design though. Monospace fonts have it rough!).
* It's widely recommended to avoid writing U+2010 and just use U+002D for hyphens. Hyphens are by far the most common of these punctuation symbols, so it's ludicrous that `man` pages to map them by default; most man pages will never want any kind of dash.
* Soft hyphen support sucks.
* For different reasons, it's rare to manually write U+2212, since you should generally tell your typesetting engine to switch to math mode (which also takes care of inserting the right obscure kinds of spaces).
* En dash is also used as a higher-level hyphen, when the inputs are already compound (not necessarily with hyphens!).
* En dash with spaces around it is an alternate style equivalent to em dash without spaces, for uses like a comma/colon/reverse-colon/parenthesis. A given work should only use one for consistency. In casually written text, space-asciidash-space is almost always intended as an en dash.
* Em dash is also the thing to use for interruption; there are several subcases here. This is the only time an em dash can potentially touch a space, though except for self-interruption they're generally inside quotes so won't actually.
* When there's a parenthetical interruption by the narrator, the em dash goes outside the quotes (“Foo”—bar—“baz”).
* Em dashes are also used for attribution after a quote, or for signatures. This is supposed to always be the start of a line, but if you're sloppy I guess it might be preceded by a space here too.
* U+2012 figure dash is probably the only other dash worth knowing; use it with digits. There's also a "figure space" you should use for monospace-like padding in a non-monospace font.
I believe the correct code point for quotation attribution is U+2015 HORIZONTAL BAR:
> The Unicode standard introduced a separate character U+2015 ― HORIZONTAL BAR to be used as a quotation dash. It may be the same length as an em-dash, which is often used instead. Some software will insert a line break after an em-dash, but not after a quotation dash.
― https://en.m.wikipedia.org/wiki/Quotation_mark#Quotation_das...
—o11c
> Em-dash, an alternative to the quotation dash
You confidently asserted the em-dash as the correct choice for quotation attribution which, if not outright incorrect, is certainly not the most or the only canonical choice. Nothing obscure in style about it!
An em-dash is an alternative to a proper quotation dash when used to precede a quotation, but is generally itself considered the proper dash for attribution [0].
[0] https://en.wikipedia.org/wiki/Dash#Attribution_of_quote_sour...
It's preposterous that we have to resort to such primitive text search methods just to find the information for command line arguments. We've had hypertext for 3 decades now; why aren't they just listed in a table of contents and then you can follow the links to the detailed descriptions? I always seek out HTML documentation whenever I can; man pages are a last resort.
If your search function/engine doesn't find all the horizontal lines characters when the user types ASCII hyphen-minus, you're generating false-negatives.
Isn't there some open source code that takes care of this universal problem? It's not just hyphen/minus/dashes. There are quotation marks, diacritics, and more.
For dashes, if done right, it could be useful to be able to search the separate ones too - i.e. search for flag dashes but not ones in prose.
For reference, the ‘match diacritics’ option on Firefox toggles this behaviour.
(It’s slightly misnamed, actually, since it’s more expansive than just diacritics: it also matches things like Unicode dashes for ASCII dashes, and so on.)
No, that's not it; there are some further issues mentioned in the thread and the linked bug reports, like man pages containing command line options that can't be copy/pasted into a terminal (because they consist of Unicode hyphens).
If I'm reading a man page via `less`, I want find the next option with a simple search function i.e. /-
https://lists.debian.org/debian-devel/2023/10/msg00106.html
https://salsa.debian.org/debian/groff/-/commit/d5394c68d7