Hi Branden,
On 9/12/21 7:27 PM, G. Branden Robinson wrote:
Hi, Alex!
At 2021-09-12T14:56:39+0200, Alejandro Colomar (man-pages) wrote:
Hi Branden,
Usually, when a manual page highlights a term, either in bold or
italics, it usually is a special identifier (macro, function, command
name or argument), for which hyphenation can hurt readability and even
worse, turn it into a different valid identifier.
What about disabling hyphenation for .B and .I?
Are there any inconveniences in doing so that I can't see?
The problem that arises is that the font styling macros are
presentational, not semantic, so it's hard to know whether someone is
using them for emphasis or to suggest syntactical information. This is
why you made a statistical argument ("usually").
Truly, even though most cases of .B/.I are identifiers (or literals),
some are emphasized words or phrases.
I think no identifier should ever be hyphenated, if possible, mainly due
to the confusion with other possibly valid identifiers.
I'd also argue that for the cases when the writer wants to emphasize a
word, hyphenating it does the opposite. The writer wanted it to stand
out from the rest, but now it's broken into two incomplete pieces far
apart from each other.
I think I really want to disable hyphenation everywhere I want a word to
stand out from the rest, be it an identifier or just an emphasized word
or phrase.
Ingo's option of disabling hyphenation _everywhere_ in man pages seems
too drastic to me. There's still a lot of prose, and it's not so
important there (although I admit both ways have their benefits; not
saying it's wrong). But that adds a point against the only downside I
can see: disabling hyphenation may (in rare occasions where many long
identifiers are together) produce an awkward number of spaces due to
filling; but if no-one has complained against mandoc, I guess that's not
so terrible or doesn't happen that much.
Regards,
Alex
--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/
