Hi, Alex!

At 2021-07-30T14:59:52+0200, Alejandro Colomar (man-pages) wrote:
> Yes, they were because of semantic newlines.
> 
> The "rules" are:
> 
> Follow mainly "semantic newlines" style (forgetting about the line
> length), which will give you a text that (mostly) fits into 75 or 80
> columns.
> 
> If after doing that there are some lines that exceed the 75 or 80
> column right margin, consider fixing that line by breaking it at a
> different point or maybe breaking it further.  The 80 column limit is
> a hard limit (I can't read anything past the 80 col), while the 75
> limit is a bit softer (that's for allowing quotes in reviews) (if
> fitting a line into col 75 would break it in a weird way, don't do
> it).
> 
> If I didn't explain myself enough, please tell me.

I'm a little puzzled by the above.  Semantic newlines have little to do
with the output line length in *roff systems.  They arose due to a Bell
Labs Unix Room practice, popularized by Brian Kernighan.  Brandon Rhodes
has a backgrounder on this[1].

Man pages tend to be really flexible with respect to output line length.
This is one reason the groff man macros expose a user-settable LL
register.  The main limitations on line length are people using tbl(1)
tables or disabling filling (with the .nf request or in .EX/.EE
examples).  Another limitation is that as lines get shorter, it becomes
hard to set the page headers and footers without them overlapping.

For the first two points there is not much the macro package can do;
both tbl(1) and filling disablement leave the placement of line breaks
in the hands of the document author, and they can abuse that power by
"oversetting" a line; that is, making it longer than the configured line
length.

The third point is a problem the macro package can overcome with some
effort, by measuring the lengths of the components that go into a header
or footer an abbreviating them.  This is not a theoretical concern;
Erlang supplies some man pages with insanely long names[2], and you can
see the problem in footers today on the man-pages site for any page
groff ships, because Michael pulls from our Git repository (to my great
relief, because I fix documentation errors and make other improvements
all the time) and our version identifier has gotten crazily long because
we're on the order of one thousand commits since the last release
candidate, and gnulib's git-version-gen uses release tags, commit count
since the tag, _and_ an abbreviated commit ID to generate the version
string.  For my tree right now that's "1.23.0.rc1.999-7ae6d".

Here's a specimen of how that works out in a rendered page:
<https://man7.org/linux/man-pages/man1/neqn.1.html> (scroll to the
bottom).

I've fixed the problem for long page names for the next groff release,
but it involved some string-manipulation gymnastics[3].  I haven't yet
factored those out into their own (private) macro which I can also call
when preparing the page footer.

Regards,
Branden

[1] https://rhodesmill.org/brandon/2012/one-sentence-per-line/
[2] CosNotifyChannelAdmin_StructuredProxyPushSupplier(3erl)
[3] https://git.savannah.gnu.org/cgit/groff.git/commit/?id=b7f38e8a1d698e1078d7c215d08fde57d8e919b9