public inbox for linux-man@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Schwarze <schwarze@usta.de>
To: "Alejandro Colomar (man-pages)" <alx.manpages@gmail.com>
Cc: "G. Branden Robinson" <g.branden.robinson@gmail.com>,
	linux-man@vger.kernel.org, groff@gnu.org
Subject: Re: .B, .I disable hyphenation?
Date: Sun, 12 Sep 2021 16:47:18 +0200	[thread overview]
Message-ID: <20210912144718.GC41870@athene.usta.de> (raw)
In-Reply-To: <ebbf8dab-6fd0-2fb8-d29b-b7146f79398d@gmail.com>

Hi Alejandro,

Alejandro Colomar (man-pages) wrote on Sun, Sep 12, 2021 at 02:56:39PM +0200:

> 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?

I would welcome such a change.

Needless to say, that is insufficient for getting it implemented.
A change of that kind requires consensus, or at least an overwhelming
majority, among groff developers.

> Are there any inconveniences in doing so that I can't see?

I don't expect any downside at all.

For comparison, the mandoc implementation of man(1) globally disables
any kind of automatic hyphenation, even in running text not containing
any markup, even if documents explicitely request hyphenation, and
provides no way to override that global choice, neither via
compile-time nor via run-time configuration, options, or any other
means.  I don't recall user complaints about the lack of hyphenation.

In technical documentation, i think the occasional confusion that
automatic hyphenation may cause, and the occasional ugliness of
output caused by automatic hyphenation, both outweigh the potential
benefits that automatic hyphenation has in texts that are not
technical documentation (yes, i did write an implementation of
automatic hyphenation around 1984 or 1985 because i do see benefits
of automatic hyphenation for some texts outside the domain of
technical documentation).

The mandoc implementation of man(1) even goes some steps further.
It globally disables line-breaking even at *existing* hyphens
whenever the hyphen appears on (almost) *any* macro or request line,
and also if the character on either side of the hyphen is not an
ASCII letter.  Again, i do not recall complaints by users that they
desire more line-breaking at existing hyphens.

Yours,
  Ingo

  reply	other threads:[~2021-09-12 14:47 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 [this message]
2021-09-12 17:27 ` G. Branden Robinson
2021-09-12 20:09   ` Alejandro Colomar (man-pages)
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=20210912144718.GC41870@athene.usta.de \
    --to=schwarze@usta.de \
    --cc=alx.manpages@gmail.com \
    --cc=g.branden.robinson@gmail.com \
    --cc=groff@gnu.org \
    --cc=linux-man@vger.kernel.org \
    /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