groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

warning on mid-input line sentence endings (was: Warn on semantic newlin


From: G. Branden Robinson
Subject: warning on mid-input line sentence endings (was: Warn on semantic newlines)
Date: Sat, 16 Jul 2022 15:44:39 -0500

[I've retitled the subject line to avoid misleading terminology.]

At 2022-06-10T07:16:54-0500, G. Branden Robinson wrote:
> At 2022-06-10T11:52:30+0200, Alejandro Colomar wrote:
> > As far as I know, there's currently no tool that warns on "foo. bar"
> > in filled test.  Not `mandoc -Tlint`, and not `groff -ww`, and not
> > `groff -rCHECKSTYLE=999`.  I know that CHECKSTYLE is not designed in
> > a way that could catch this easily,

First a comment on terminology.  "Semantic newlines" is a term of art in
the Linux man-pages project; we don't use it in groff's documentation.
It refers to the practice of ending input lines where sentences end.
groff documentation _does_ encourage this.

Further, what's being requested here is _not_ a warning when semantic
newlines are encountered, but the opposite: a warning when the end of a
sentence is encountered anywhere _but_ the end of an input line.

> For groff, at least, the fundamental change is straightforward.  I can
> made the troff(1) command do it with a 1-line patch.
> 
> diff --git a/src/roff/troff/env.cpp b/src/roff/troff/env.cpp
> index d6a9e982d..d3f80a205 100644
> --- a/src/roff/troff/env.cpp
> +++ b/src/roff/troff/env.cpp
> @@ -472,6 +472,7 @@ void environment::space(hunits space_width, hunits 
> sentence_space_width)
>        && node_list_ends_sentence(p->next) == 1) {
>      hunits xx = translate_space_to_dummy ? H0 : sentence_space_width;
>      if (p->merge_space(xx, space_width, sentence_space_width)) {
> +      debug("end of sentence detected in input line");
>        *tp += xx;
>        return;
>      }
> 

As mentioned previously,[1] I think a new, writable troff register would
be a better way to manipulate this feature--which is basically a style
diagnostic--than a warning category.  When the register is "true" (has a
positive value), a message much the one above will be emitted, and not
otherwise.  Nothing in the groff distribution will turn it on by
default (some of our Automake files may use it during document
generation, but nothing will impose it on user documents).

I have at least resolved the name space problem to my satisfaction; we
can name the register with a trailing period, like the `c.` register
that Kernighan introduced to device-independent troff ca.  1980.  This
also solves my backtrace register naming dilemma; see
<https://savannah.gnu.org/bugs/index.php?59290>.

The devilish problem is that I don't know what to put _before_ the
period in the register name for _this_ issue.

"sentence." seems too broad and too vague.  "midlinenewsentence." is
hard to read and much too long, but at least it gets the idea across
once you've morphologically analyzed it.

I'd like to hear suggestions.

Regards,
Branden

[1] https://lists.gnu.org/archive/html/groff/2022-06/msg00059.html

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]