Re: warning on mid-input line sentence endings

[G. Branden Robinson]

Hi Doug!

At 2022-07-17T09:06:53-0400, Douglas McIlroy wrote:
> In regard to turning the warning on or off, the warning should not be
> given when sentence spacing is set to 0 (or below some small
> threshold). In that case the opposite warning would be appropriate--a
> double space between sentences is questionable when sentence spacing
> is 0.

I'm not sure I agree.

First let me emphasize that this won't be a "warning"; the diagnostic
message won't say "warning", and shouldn't if this is message isn't to
be a warning like the others manipulable with groff's -w and -W options
and .warn request.

It is a relatively novel thing for groff, a diagnostic message not in
any other category.  The only things resembling it are the backtrace
messages produced upon other diagnostics when the -b option is given,
the .backtrace request is used, or, if I follow through with my current
plan, when the "backtrace." register is true.

Regarding the substance of your suggestion, I don't think it necessarily
follows that because someone wants less, or no, supplemental
inter-sentence space in the rendered document (as with ".ss 12 0") that
they won't have use for additional space characters after sentence
endings in the input.

Do I think it will often be true?  Yes.  No doubt many groff users will
hate their appearance and eschew them.  But I shy away from coupling
these parameters because I feel they are truly independent.  Say I'm
writing a piece for publication in a journal, and I don't use "semantic
newlines", but compose my *roff document like this email, or like Eric
Allman and Peter Schaffter write their documents, with conventional
prose paragraphs, and two spaces after sentence endings.

Let's imagine it has the following improbable content.  Note the
omission of the ineffable \& escape sequence after one of the initials.

---
The end of our debate is coming nigh.  Be in my office at 5 p.m.  P.\&
Z. Myers will be here to meet you.
---

I submit my piece and I get back a note from the editor.

"We like your article, but at our periodical we practice Reformed
Orthodox Harperism.  Please reduce by one-third the amount of space
between your sentences and re-submit camera-ready copy in PDF ASAP."

Under my proposal, this is a 30 second edit at most.  I slap ".ss 12 4"
at the top, regenerate, and email a reply with the attachment.

Under yours--assuming "4" fell below the value of the small threshold
you suggest--I'd need to refill the entire article in my text editor
lest I elicit a torrent of troff complaints.  Yes, I could call groff
with "-rbacktrace.=0" instead of "-rbacktrace.=1", or similarly edit my
Makefile or whatever--but then, what if my refilling resulted in this?

---
The end of our debate is coming nigh. Be in my office at 5 p.m. P.\& Z.
Myers will be here to meet you.
---

There are multiple problems here.

One is that I've defeated end-of-sentence detection entirely after
"nigh." and "p.m.", so I'll get High Orthodox Harperism after these
sentences instead of the Reformed rite practiced by the journal.

Another is that because I failed to use \& in a consistent, paranoid
way, the refilling of Myers's middle initial now appears to troff as a
sentence ending, and will wrongly get Reformed Orthodox Harperist space
after it even though it doesn't end a sentence at all.

But if I leave the input text in its original form...

---
The end of our debate is coming nigh.  Be in my office at 5 p.m.  P.\&
Z. Myers will be here to meet you.
---

...and apply the change you suggest, troff will screech at me for having
excessive input space after "nigh." and "p.m.", in exactly the places I
_don't_ need to be messing with it.  But if I leave it alone, it will
format as the editor desires!

I'm attaching ms source and PostScript output (produced with groff
1.22.4) to illustrate my point.

Or, possibly, I've missed yours.  If so, please try again to get through
my thick skull.

Regards,
Branden

myers.ms
Description: Troff MS-macros document

myers.ps
Description: PostScript document

signature.asc
Description: PGP signature