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/