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
