From: "Alejandro Colomar (man-pages)" <alx.manpages@gmail.com>
To: "G. Branden Robinson" <g.branden.robinson@gmail.com>
Cc: groff@gnu.org, linux-man <linux-man@vger.kernel.org>,
Ingo Schwarze <schwarze@usta.de>
Subject: Re: .B, .I disable hyphenation?
Date: Sun, 12 Sep 2021 22:09:37 +0200 [thread overview]
Message-ID: <b7ddd4e8-6faf-278f-b32f-6bf46d834d3e@gmail.com> (raw)
In-Reply-To: <20210912172749.uziql5vofxi7sjth@localhost.localdomain>
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/
next prev parent reply other threads:[~2021-09-12 20:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-12 12:56 .B, .I disable hyphenation? Alejandro Colomar (man-pages)
2021-09-12 14:47 ` Ingo Schwarze
2021-09-12 17:27 ` G. Branden Robinson
2021-09-12 20:09 ` Alejandro Colomar (man-pages) [this message]
2021-09-13 0:16 ` G. Branden Robinson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b7ddd4e8-6faf-278f-b32f-6bf46d834d3e@gmail.com \
--to=alx.manpages@gmail.com \
--cc=g.branden.robinson@gmail.com \
--cc=groff@gnu.org \
--cc=linux-man@vger.kernel.org \
--cc=schwarze@usta.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox