[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: documentation error introduced in commit a8f804ff?
From: |
G. Branden Robinson |
Subject: |
Re: documentation error introduced in commit a8f804ff? |
Date: |
Sat, 20 Mar 2021 01:11:05 +1100 |
User-agent: |
NeoMutt/20180716 |
Hi, Dave!
At 2021-03-19T01:42:38-0500, Dave Kemper wrote:
> Among many other changes to doc/groff.texi, commit a8f804ff
> (http://git.savannah.gnu.org/cgit/groff.git/commit/?id=a8f804ff) does
> this:
>
> * (Sentences) Make clear that inter-sentence space is applied (if
> not zero) when filling is enabled, not merely adjustment.
>
> However, this doesn't appear to be true: a simple example shows groff
> applying inter-sentence spacing to unfilled text:
>
> .ss 12 144 \" make sentence space huge for easy visibility
> Sentence one. Sentence two.
> .br
> .nf
> Sentence one. Sentence two.
Yup. In fact the .br isn't even necessary since .nf implies a break.
> Branden, is this a misstatement, or do you think .ss *should* behave
> differently in fill mode vs no-fill mode? There's no historical
> (pre-groff) behavior in play here, since the second .ss parameter is a
> groff invention; however, as far as I'm aware, groff has always
> applied the additional inter-sentence space regardless of the fill
> mode setting.
It's a misstatement. I didn't test correctly when revising that
material. I'll fix our Texinfo manual accordingly--thank you!
As a side issue...
You may have just, to your possible dismay, come up with another reason
_not_ to change the default additional inter-sentence space to zero. :P
As soon as I verified what you said, I thought, "oh, shit, now I have to
change the man(7) .EX/.EE macros to save and restore the sentence
spacing because otherwise incorrect spacing might show up in 'literal'
code examples".
But then I relaxed, because I remembered 3 things:
1. I updated our man(7) macros to reassert the .ss default as part of
handling the .TH macro (so even if multiple pages are being rendered
and one page messes it up, the next one will return to normal).[1]
2. As you note, when an input line break causes one on the output (as it
does after an .nf request), there's no way of observing the special
additional inter-sentence spacing behavior _without_ using the .ss
request.
3. The fact that *roff does end-of-sentence detection, and acts on it
always, even when filling is off, is additional useful ammunition
against the argument that .EX/.EE regions, or, "better yet", entire
man(7) documents, should break from 45+ years of *roff practice and
render terminal output "exactly" as it appears on the input.[2]
*roff is not Markdown and we should not change it to chase Markdown.
Exasperatedly (but not with you) yours,
Branden
[1] d7cfedcf4b44a1fdb756d86cebbdbbc3012ab4d1
[2] https://lists.gnu.org/archive/html/groff/2020-10/msg00158.html
signature.asc
Description: PGP signature