bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #64502] [mdoc] macros should inhibit word breaking where sensible


From: Ingo Schwarze
Subject: [bug #64502] [mdoc] macros should inhibit word breaking where sensible
Date: Tue, 8 Aug 2023 18:13:43 -0400 (EDT)

Follow-up Comment #3, bug #64502 (project groff):

FYI: how mandoc(1) does this.

1) mandoc(1) never hyphenates anything - obviously, groff(1) does not want to
emulate *this* aspect.
2) Even at existing hyphens, mandoc(1) only breaks output lines if the word
containing the hyphen is on a text input line, never if it is on a macro or
request input line.
3) In mandoc, rule 2) applies to both mdoc(7) and man(7).

That may sound unbelievably simple to people who previously pondered ploughing
through macro lexica and making tons of individual decisions.
But isn't it beneficial to keep things simple when you have the chance?

Besides, i also think rule 2) actually makes sense.  In manual pages, the vast
majory of words that appear on macro lines are some kinds of syntax elements,
and splitting these across line breaks, even at existing hyphens, is certainly
not needed, but may often look weird, no matter whether that happens in the
SYNOPSIS or anywhere else in a manual page.  For example, when listing links
to other manual pages below SEE ALSO, and some of those manual page names
contain hyphens, wouldn't it be better to keep each page name on one line
anyway?  Or even when the same thing happens in the middle of running text?

Admittedly, manual page writers may occasionally use .Em or .I for stress
emphasis in running text, and arguably, in that case hyphenation would be OK. 
But i think that's rare in manual pages compared to using macros for more
technical purposes, and having such an emphasized word hyphenated is certainly
not important.  Sometimes, it may not even look so good to have a few italic
characters at the end of one output line and then a few more at the beginning
of the next.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64502>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]