bugGNU roff - Bugs: bug #62593, clarify description of...

 
 

bug #62593: clarify description of end-of-sentence detection

Submitter:  Dave <barx>
Submitted:  Mon 06 Jun 2022 09:30:30 PM UTC
   
 
Category:  General Severity:  3 - Normal
Item Group:  Documentation Status:  Fixed
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Closed Planned Release:  1.23.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 11 Jul 2022 01:14:11 PM UTC, comment #20: 

comment #19:

> However, there is a population of imaginative *roff users out
> there, so we may yet see it arise.


Indeed.  And for thoroughness it's worth documenting the behavior of even improbable input.

Dave <barx>
Group Member
Mon 11 Jul 2022 12:41:42 PM UTC, comment #19: 


comment #17:

> (It's less clear why someone would specify a nonbreaking space and then force a break right after it, but that's neither here nor there.)


Oh, I addressed the wrong point.

Yes, doing


something\~
else


makes very little sense.  I'm struggling to think of a use case for it, even if macros producing unexpected text are interposed.

However, there is a population of imaginative *roff users out there, so we may yet see it arise.




G. Branden Robinson <gbranden>
Group administrator
Mon 11 Jul 2022 12:34:19 PM UTC, comment #18: 

comment #17:

> The point I was trying to make with that: Space is only ever discarded if it becomes a line break point.  Nonbreaking space by definition can never be a break point.  So saying "horizontal motion cannot be [discarded]" is only meaningful if it can in fact be a break point; thus, making such an observation might be read to imply that it can be.
>
> But that was a reply to a bug comment; the actual wording added to the manual makes this clear, saying the space represented by \~ "is discarded from the end of an output line if a break is forced."  (It's less clear why someone would specify a nonbreaking space and then force a break right after it, but that's neither here nor there.)


The only case I've been able to think of was following the horizontal motion with a vertical one, maybe to point some kind of arrow at the end of the horizontal motion.  And even for that, I've had trouble coming up with a practical application for it.

The best I can do is somewhat whimsical, but there's no law against using groff for whimsical literature.


$ cat EXPERIMENTS/trailing-motion.groff
The flowers will start growing here.\h'1i'\v'1v'\[ua]
$ nroff EXPERIMENTS/trailing-motion.groff | cat -s
The flowers will start growing here.
                                              ↑


G. Branden Robinson <gbranden>
Group administrator
Mon 11 Jul 2022 12:21:24 PM UTC, comment #17: 

comment #16:

> Whether a motion command gets sent to device-independent output
> matters for things like the output comparison operator.


That's a good point that I hadn't considered.

> I don't think I understand your point here.  Can you rephrase?


The point I was trying to make with that: Space is only ever discarded if it becomes a line break point.  Nonbreaking space by definition can never be a break point.  So saying "horizontal motion cannot be [discarded]" is only meaningful if it can in fact be a break point; thus, making such an observation might be read to imply that it can be.

But that was a reply to a bug comment; the actual wording added to the manual makes this clear, saying the space represented by \~ "is discarded from the end of an output line if a break is forced."  (It's less clear why someone would specify a nonbreaking space and then force a break right after it, but that's neither here nor there.)

> Within the domain of *roff operation, however, there is a
> tangible, measurable difference between spaces and horizontal
> motions, as I tried to illustrate above.


Yes, I think I'm following now, thank you for clarifying.

Dave <barx>
Group Member
Sun 19 Jun 2022 12:09:28 AM UTC, comment #16: 


comment #12:

> comment #7:
> > A "space" as I'm proposing to use it can always be discarded
> > at a break and a horizontal motion cannot be.
>
> True but slightly misleading: most of the things groff now deems horizontal motions are not breakpoints, so groff would only break there if there were also a space (or a \:) adjacent to it, which will rarely be the case.


That's true, but as far as my testing so far shows, motions always end up in device-independent output, and spaces--including the non-breaking space \~--don't, necessarily (they can be discarded).

See attachments.  They are four nearly identical files: one uses a trailing space on a line, one \h, one \~, and one "\ " (a.k.a. \SP, \space).  Format them with "groff -Z", and diff the outputs.


$ diff -u space.grout motion.grout && echo no difference
--- space.grout 2022-06-18 18:08:55.097349267 -0500
+++ motion.grout        2022-06-18 18:09:04.009294632 -0500
@@ -19,6 +19,7 @@
 Cfl
 h5560
 te.
+h10000
 n12000 0
 x trailer
 V792000
$ diff -u space.grout nbspace.grout && echo no difference
no difference
$ diff -u space.grout fixedspace.grout && echo no difference
--- space.grout 2022-06-18 18:08:55.097349267 -0500
+++ fixedspace.grout    2022-06-18 19:00:17.675332923 -0500
@@ -19,6 +19,7 @@
 Cfl
 h5560
 te.
+h2500
 n12000 0
 x trailer
 V792000


> So drawing a distinction that doesn't have much real-world application seems like it maybe doesn't serve readers best,


Whether a motion command gets sent to device-independent output matters for things like the output comparison operator.

> and also might imply a breakability that these characters don't have.


I don't think I understand your point here.  Can you rephrase?

> Further, terms like "figure space" are well known outside groff, and it serves readers knowledgeable about typography to use the terms standard in the art.


I have no problem making reference to these as descriptive material when documenting the escape sequences; I already started down that road with "thin space" and "hair space".

Within the domain of *roff operation, however, there is a tangible, measurable difference between spaces and horizontal motions, as I tried to illustrate above.
 

> Essentially moot, since I get your point, but I don't understand this example: with adjusting turned off, whether there is "space" at the end of an output line is invisible.  And this snippet's terminal output has no lines with trailing space characters.


Yes, I recognize that it didn't clearly enough communicate the point I was trying to get across.  See if you find the foregoing (and attached) more illuminating.

Regards,
Branden

(file #53316, file #53317, file #53318, file #53319)

G. Branden Robinson <gbranden>
Group administrator
Sat 18 Jun 2022 11:02:03 PM UTC, comment #15: 


comment #14:

> comment #9:
> > Yes, but I also want the pages to look nice.
>
> Sure, but the manual is currently undergoing so much revision (184 commits this year as of today, the 169th day of the year) that things like where page breaks occur today seem like they'll be obsolete by next week.  (At least that's my impression, though you look at the PDF version a whole lot more often than I do, so maybe you know of other factors that limit this.)


A while back I thought the same thing, but two factors reduce the amount of page-break churn.

1. Texinfo forces chapters to start on a recto page.
2. Most relocations of material occur within a chapter.

Together, these limit the cascade of page break changes.

That said, right now there are some pretty ugly spots in the manual where TeX spaces paragraphs much too far apart, to prevent breaking examples, which are automatically kept.   Further, we have one chapter (5, "gtroff Reference") that overwhelmingly dominates the overall content.

The takeaway is that I try to be mindful of keeping the page layouts agreeable, especially in places where my editorial pen has wreaked havoc to a level I find satisfying, but I'm not a perfectionist, let alone at each commit.

G. Branden Robinson <gbranden>
Group administrator
Sat 18 Jun 2022 10:47:49 PM UTC, comment #14: 

comment #9:

> Yes, but I also want the pages to look nice.


Sure, but the manual is currently undergoing so much revision (184 commits this year as of today, the 169th day of the year) that things like where page breaks occur today seem like they'll be obsolete by next week.  (At least that's my impression, though you look at the PDF version a whole lot more often than I do, so maybe you know of other factors that limit this.)

Dave <barx>
Group Member
Sat 18 Jun 2022 10:47:05 PM UTC, comment #13: 


comment #11:

> From commit 27ee71cd:


> +it obtains information about the device for which it is preparing
> +output from it description file


> Presumably the third "it" is meant to be "its"?


Good catch; the language diverges here between our Texinfo manual and roff(7), and I slipped in the latter.  I'm recasting to avoid an ambiguous antecedent.

Thanks!

G. Branden Robinson <gbranden>
Group administrator
Sat 18 Jun 2022 10:17:26 PM UTC, comment #12: 

comment #7:

> A "space" as I'm proposing to use it can always be discarded
> at a break and a horizontal motion cannot be.


True but slightly misleading: most of the things groff now deems horizontal motions are not breakpoints, so groff would only break there if there were also a space (or a \:) adjacent to it, which will rarely be the case.  So drawing a distinction that doesn't have much real-world application seems like it maybe doesn't serve readers best, and also might imply a breakability that these characters don't have.

Further, terms like "figure space" are well known outside groff, and it serves readers knowledgeable about typography to use the terms standard in the art.

I'd be interested in others' views about this, but terminology discussions on the list have shown a tendency to move in the direction of holy wars.  (Regardless, although the discussion arose here, it's not really on topic for this bug.)

> The following exercise helped push me in this direction.


Essentially moot, since I get your point, but I don't understand this example: with adjusting turned off, whether there is "space" at the end of an output line is invisible.  And this snippet's terminal output has no lines with trailing space characters.

Dave <barx>
Group Member
Sat 18 Jun 2022 07:58:38 PM UTC, comment #11: 

From commit 27ee71cd:

+it obtains information about the device for which it is preparing
+output from it description file

Presumably the third "it" is meant to be "its"?

Dave <barx>
Group Member
Wed 15 Jun 2022 02:01:46 PM UTC, comment #10: 


commit 27ee71cd0ad0ba6dad515efa0b7550bd18a5733a
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Wed Jun 15 03:19:04 2022 -0500

    [docs]: Revise end-of-sentence detection material.

    * doc/groff.texi (Filling):
    * man/roff.7.man (Concepts): Do it.  "Spaces" is a now a term with a
      much more restricted usage.  Emphasize the input context, now
      explicitly identified as plain text files with Unix line endings.

    Fixes (one hopes) <https://savannah.gnu.org/bugs/?62593>.  Thanks to
    Ingo Schwarze for the report and Dave Kemper for the discussion.

commit bf6ff8f2a57f6064ac1f0c9cb6144f247e3e7630
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Wed Jun 15 02:51:55 2022 -0500

    [docs]: Revise discussion of spaces and motions.

    Draw a sharper distinction between "spaces", which are adjustable and
    discardable, and horizontal motions, which are not.

    * doc/groff.texi: Relocate presentation of `\~` escape sequence...
      (Page Motions): ...from here...
      (Manipulating Filling and Adjustment): ...to here, much earlier.

      (Page Motions): Recast descriptions of `\v`, `\h`, `\space`, `\|`,
      `\^`, `\0`.

    * man/groff.7.man:
    * man/groff_diff.7.man:
    * man/groff_font.5.man: Sync with updated descriptions above.


G. Branden Robinson <gbranden>
Group administrator
Wed 15 Jun 2022 06:09:56 AM UTC, comment #9: 

comment #6:

> comment #5:
> Perhaps for completeness, but I think those two terms are intuitive enough to be used before a formal definition.  (And cross references can always point forward, in case anyone is confused about the terms.)  The text can say "ordinary space characters" without needing to bring in the concept of escapes yet; the reader who goes through the manual linearly (and such readers are probably rare anyway) may wonder "what's a NONordinary space?," but this won't trip up their understanding of the point being made here.  And the reader who's looking up this section for reference will understand immediately that there are other types of spaces.


I think I've found a way to address both Ingo's and my concerns.
 

> > page space (in DVI and PDF) is at a premium in this part of
> > the manual.
>
> Happily, the supply-chain issues limiting the supply of so many other things have not hit PDF pages yet.  And I bet the set of people who will print out the PDF manual is quite small.


Yes, but I also want the pages to look nice.  I did get sucked into development work on a typesetting system...
 

> > A CSTR#54-ish definition of sentence-ending detection that has
> > free recourse to the panoply of *roff jargon is better
> > situated in groff(7).
>
> Yes, but as long as the Texinfo manual advertises itself as the most complete reference, the detail does need to be there as well.


Agreed.
 

> In any case, I'm not sure how important the first change is; I think most readers will assume the unmodified word "spaces" means the spaces you get when you hit the keyboard's spacebar.


Yes.

> The second change ("end of an input line") does seem a useful clarification.


Yes.

Here's what I've got pending.  It's in word diff format.


diff --git a/doc/groff.texi b/doc/groff.texi
index 742f4cedc..56f39d833 100644
--- a/doc/groff.texi
+++ b/doc/groff.texi
@@ -4862,21 +4862,22 @@ inter-sentence space.

When GNU @code{troff} starts up, it obtains information about the device
for which it is preparing output.@footnote{@xref{Device and Font
Description Files}.}  [-A crucial example-]{+An essential property+} is the length of the output
line, such as ``6.5 inches''.

@cindex word, definition of
@cindex filling
GNU @code{troff} {+interprets plain text files employing the Unix+}
{+line-ending convention.  It+} reads[-its-] input {+a+} character [-by character,-]{+at a time,+}
collecting words as it goes, and fits as many words together on an
output line as it can---this is known as @dfn{filling}.  To GNU
@code{troff}, a @dfn{word} is any sequence of one or more characters
that aren't spaces, tabs, or newlines.  The exceptions separate
words.@footnote{There are also @emph{escape sequences} which can
function as word characters, word separators, or neither---the last
simply have no effect on GNU @code{troff}'s idea of whether an input
character is within a word or not.}  To disable filling, see
@ref{Manipulating Filling and Adjustment}.

@Example
It is a truth universally acknowledged
@@ -5110,8 +5111,8 @@ This is discussed in @ref{Manipulating Filling and Adjustment}.
@subsection Adjustment

@cindex extra spaces between words
After GNU @code{troff} performs an automatic[-line-] break, it then tries to
@dfn{adjust} the line: inter-word spaces are widened until the text
reaches the right margin.  Extra spaces between words are preserved.
Leading and trailing spaces are handled as noted above.  Text can be
aligned to the left or right margins or centered; see @ref{Manipulating
@@ -5467,24 +5468,23 @@ traditions have accrued in service of these goals.
@itemize @bullet
@item
Follow sentence endings in input with newlines to ease their
recognition (@pxref{Sentences}).  It is frequently convenient to [-break-]{+end+}
{+input lines+} after colons and semicolons as well, as these typically
precede independent clauses.  Consider [-breaking-]{+doing so+} after commas; they often
occur in lists that become easy to scan when itemized by line, or
constitute supplements to the sentence that are added, deleted, or
updated to clarify it.  Parenthetical and quoted phrases are also good
candidates for placement on input lines by themselves.[-In filled text, spaces and-]
[-newlines are interchangeable; place breaks where it aids your purpose.-]

@item
Set your text editor's line length to 72 characters or
fewer.@footnote{Emacs: @code{fill-column: 72}; Vim: @code{textwidth=72}}
This limit, combined with the previous [-advice regarding breaking around-]
[-punctuation,-]{+item of advice,+} makes it less
common that an input line will wrap in your text editor, and thus will
elp you perceive excessively long constructions in your text.  Recall
that natural languages originate in speech, not writing, and that
punctuation is correlated with pauses for breathing and changes in
prosody.

@item
Use @code{\&} after @samp{!}, @samp{?}, and @samp{.} if they are


G. Branden Robinson <gbranden>
Group administrator
Wed 15 Jun 2022 05:55:39 AM UTC, comment #8: 

comment #3:

> > \| Unbreakable 1/6 em (“thin”) space glyph; zero‐width in nroff.
> >
> > might become the following
> >
> > \| 1/6 em motion (“thin space”); zero-width in nroff.
>
> \| and \^ seem the poorest fit for this renaming since they can be defined as glyphs in the font.


But they're excellent fits for the renaming because they're equivalent to '\h@1m/6u@' and '\h@1m/12u@' respectively.

Yes, but I'm seriously mulling withdrawing support for that.  It's a GNU extension that no one seems to use.

Unicode supports more space glyphs than we have escape sequences for; see U+2000 to u+200B.

If someone wants to define customized horizontal motion (non-breaking space), it is easy to do so.  And that seems to me more properly the province of the document author than the provider of the output device (driver) anyway.


$ cat EXPERIMENTS/nineteen-twelfths.groff
.char \[fnord] \h'19m/12u'
Check out my\[fnord]custom space width.


G. Branden Robinson <gbranden>
Group administrator
Wed 15 Jun 2022 05:35:31 AM UTC, comment #7: 


comment #3:

> comment #1:
> > I've been chewing over the idea of discarding as many "space"
> > terms as possible in favor of "motions".
>
> Hmm, I wonder if that's another case of veering into being technically correct at the expense of some clarity to the average reader (a la replacing "single quote" with "neutral apostrophe" in a coding context*).  Sure, theoretically all spaces (horizontal or vertical) are motions, but especially for horizontal spacing, it seems like users will more naturally think of something like \0 as a space the width of a digit, rather than a horizontal cursor motion of that magnitude.


After doing some experimenting I'm more confident that my musing in comment #1, quoted above, is a step in the right direction.

A "space" as I'm proposing to use it can always be discarded at a break and a horizontal motion cannot be.  This is leading me to introduce the \~ escape sequence much earlier, in section "Manipulating Filling and Adjustment" rather than in "Page Motions".  And that's good because *roff writers should learn \~ fairly early.  TeX's ~, to similarly suppress breaks as in "G.~W.~Pabst", is introduced fairly early in the tutorial material I recall.

The following exercise helped push me in this direction.


$ cat EXPERIMENTS/spaces-and-motions.groff
.na
.nm 1
.if n .ll 23n
.if t .ll 1.25i
This is my rifle.
This is my rifle.
.br
This is my rifle.\ \
This is my rifle.
.br
This is my rifle.\~\~
This is my rifle.
.br
This is my rifle.\0\0
This is my rifle.
.br
This is my rifle.\h'1i'
This is my rifle.
.if t \{\
.br
This is my rifle.\|\|\|\|\|\|
This is my rifle.
.br
This is my rifle.\^\^\^\^\^\^\^\^\^\^\^\^
This is my rifle.
.\}
.pl \n[nl]u


G. Branden Robinson <gbranden>
Group administrator
Mon 13 Jun 2022 07:35:38 AM UTC, comment #6: 

comment #5:

> It's difficult to make either of the suggested changes at this
> location in the manual.  This is §5.1.2.  I introduce an escape
> sequence later in the same section for the sake of `\&`, but not
> formally until §5.6.2.  I notice that I do not formally define
> "ordinary character" or "input line".  Those should probably be
> done.


Perhaps for completeness, but I think those two terms are intuitive enough to be used before a formal definition.  (And cross references can always point forward, in case anyone is confused about the terms.)  The text can say "ordinary space characters" without needing to bring in the concept of escapes yet; the reader who goes through the manual linearly (and such readers are probably rare anyway) may wonder "what's a NONordinary space?," but this won't trip up their understanding of the point being made here.  And the reader who's looking up this section for reference will understand immediately that there are other types of spaces.

> page space (in DVI and PDF) is at a premium in this part of
> the manual.


Happily, the supply-chain issues limiting the supply of so many other things have not hit PDF pages yet.  And I bet the set of people who will print out the PDF manual is quite small.

> A CSTR#54-ish definition of sentence-ending detection that has
> free recourse to the panoply of *roff jargon is better
> situated in groff(7).


Yes, but as long as the Texinfo manual advertises itself as the most complete reference, the detail does need to be there as well.

In any case, I'm not sure how important the first change is; I think most readers will assume the unmodified word "spaces" means the spaces you get when you hit the keyboard's spacebar.

The second change ("end of an input line") does seem a useful clarification.

Dave <barx>
Group Member
Fri 10 Jun 2022 01:11:30 AM UTC, comment #5: 


original submission:

> Another "bookmark" bug report; Ingo already suggested this in email (http://lists.gnu.org/r/groff/2022-06/msg00030.html), but that message might easily get lost in the deluge of that highly active thread.
>
> In Ingo's words:
>
> the documentation is indeed slightly fuzzy regarding this point; "info groff" tells me:
>
>   5.1.2 Sentences
>   ---------------
>   [...]
>   GNU 'troff' does this by flagging certain characters (normally '!',
>   '?', and '.') as potentially ending a sentence.  When GNU 'troff'
>   encounters one of these "end-of-sentence characters" at the end of a
>   line, or one of them is followed by two spaces on the same input line,
>   it appends an inter-word space followed by an inter-sentence space in
>   the formatted output.
>   [...]
>
> Branden, please consider improving the words "followed by two spaces".
>
> Anything like
>
>   followed by two ordinary space characters ("  ")
>   followed by two unescaped space characters ("  ")
>
> might do.
>
> You might also consider saying "at the end of an input line" rather than just "at the end of a line".


It's difficult to make either of the suggested changes at this location in the manual.  This is §5.1.2.  I introduce an escape sequence later in the same section for the sake of `\&`, but not formally until §5.6.2.  I notice that I do not formally define "ordinary character" or "input line".  Those should probably be done.

I might see if I can squeeze the latter into §5.1.1, "Filling", but page space (in DVI and PDF) is at a premium in this part of the manual.

A CSTR#54-ish definition of sentence-ending detection that has free recourse to the panoply of *roff jargon is better situated in groff(7).  (It's portable enough to be in roff(7), but that page similarly concerns itself with introducing concepts.)

G. Branden Robinson <gbranden>
Group administrator
Wed 08 Jun 2022 08:39:06 AM UTC, comment #4: 

comment #3:

> (a la replacing "single quote" with "neutral apostrophe" in a
> coding context*)


Sure enough, give up looking for one thing and start searching for another, and the thing you were previously trying to find pops right up.

Replacement footnote for the above-quoted line:

* Bug #60836 comment #11

Dave <barx>
Group Member
Tue 07 Jun 2022 08:07:52 PM UTC, comment #3: 

comment #1:

> I've been chewing over the idea of discarding as many "space"
> terms as possible in favor of "motions".


Hmm, I wonder if that's another case of veering into being technically correct at the expense of some clarity to the average reader (a la replacing "single quote" with "neutral apostrophe" in a coding context*).  Sure, theoretically all spaces (horizontal or vertical) are motions, but especially for horizontal spacing, it seems like users will more naturally think of something like \0 as a space the width of a digit, rather than a horizontal cursor motion of that magnitude.

> \| Unbreakable 1/6 em (“thin”) space glyph; zero‐width in nroff.
>
> might become the following
>
> \| 1/6 em motion (“thin space”); zero-width in nroff.


\| and \^ seem the poorest fit for this renaming since they can be defined as glyphs in the font.

> Setting "category" to "general" because I'm not certain we
> don't discuss sentence endings in non-"core" documents (like
> manuals for macro packages).


Good point.  I didn't intend to limit the scope, but was thinking only of the scope of Ingo's original comment.


* I commented on this in response to a recent commit, but after a fruitless hour scouring savannah, the groff list, and private email to you, failed to unearth my comment.  So maybe I only imagined it.

Dave <barx>
Group Member
Mon 06 Jun 2022 10:05:36 PM UTC, comment #2: 


comment #1:

> while elsewhere discussing the fact that motions are never discarded except at the end of an output line (horizontal) or page (vertical).


I also want to record the fact that I think some more conceptual groundwork needs to be laid early in our Texinfo manual (and the roff(7) "Concepts" section).

Our documentation has been somewhat ad hoc about what constitutes "output" versus "formatted output", and it's a tricky thing to talk about without grappling directly with groff_out(5) commands.  (Also I badly need to revise that page someday--it's got some of our most painful lingering Bernd-isms, like senseless editorializing[1].)

Some rocks to steer among:

  • the "formatted output comparison operator" (my unwieldy term) considers not just written glyphs and drawn geometric primitives, but motions
  • motions don't result in "output" for the purpose of the \c escape sequence, but written glyphs and drawn geometric primitives do
  • everything produced by troff -Z is "output" in a sense, of course...but often not in a useful one for a workaday document author


I could sorely use a term for things that "put ink on paper", except of course most of the time we aren't dealing with ink, or paper.  :-|

Just for the nonce, I want to get across the series of nested proper subsets we have.  I groped around for some words of Greek etymology to get a couple of fresh ones.

Device-independent output consists of COMMANDS (some of which are ACTUATORS (some of which are SKETCHES)).

I don't like these terms (except the first, although I'm not wedded even to it).  But I think we badly need unambiguous terms for their referents to bring order to the wretched chaos that is reflected in some of the threads on groff@gnu we've seen this month (and over the years).

Promoting to "Normal" severity accordingly.

[1] My editorializing, by contrast, invariably stimulates deep insight in all readers.  Sure it does...

G. Branden Robinson <gbranden>
Group administrator
Mon 06 Jun 2022 09:46:44 PM UTC, comment #1: 


original submission:

> Another "bookmark" bug report; Ingo already suggested this in email (http://lists.gnu.org/r/groff/2022-06/msg00030.html), but that message might easily get lost in the deluge of that highly active thread.
>
> In Ingo's words:
>
> the documentation is indeed slightly fuzzy regarding this point; "info groff" tells me:
>
>   5.1.2 Sentences
>   ---------------
>   [...]
>   GNU 'troff' does this by flagging certain characters (normally '!',
>   '?', and '.') as potentially ending a sentence.  When GNU 'troff'
>   encounters one of these "end-of-sentence characters" at the end of a
>   line, or one of them is followed by two spaces on the same input line,
>   it appends an inter-word space followed by an inter-sentence space in
>   the formatted output.
>   [...]
>
> Branden, please consider improving the words "followed by two spaces".
>
> Anything like
>
>   followed by two ordinary space characters ("  ")
>   followed by two unescaped space characters ("  ")
>
> might do.
>
> You might also consider saying "at the end of an input line" rather than just "at the end of a line".


I've been thinking about this while the discussions rage, and I'll consider them, but I've been chewing over the idea of discarding as many "space" terms as possible in favor of "motions".

So, e.g.,


\| Unbreakable 1/6 em (“thin”) space glyph; zero‐width in nroff.


might become the following


\| 1/6 em motion (“thin space”); zero-width in nroff.


while elsewhere discussing the fact that motions are never discarded except at the end of an output line (horizontal) or page (vertical).

Setting "category" to "general" because I'm not certain we don't discuss sentence endings in non-"core" documents (like manuals for macro packages).  (I do recall that we try to keep the gory details out of those.)

Thanks for your help tracking the flaming paddles I've chosen to juggle!

G. Branden Robinson <gbranden>
Group administrator
Mon 06 Jun 2022 09:30:30 PM UTC, original submission:  

Another "bookmark" bug report; Ingo already suggested this in email (http://lists.gnu.org/r/groff/2022-06/msg00030.html), but that message might easily get lost in the deluge of that highly active thread.

In Ingo's words:

the documentation is indeed slightly fuzzy regarding this point; "info groff" tells me:

  5.1.2 Sentences
  ---------------
  [...]
  GNU 'troff' does this by flagging certain characters (normally '!',
  '?', and '.') as potentially ending a sentence.  When GNU 'troff'
  encounters one of these "end-of-sentence characters" at the end of a
  line, or one of them is followed by two spaces on the same input line,
  it appends an inter-word space followed by an inter-sentence space in
  the formatted output.
  [...]

Branden, please consider improving the words "followed by two spaces".

Anything like

  followed by two ordinary space characters ("  ")
  followed by two unescaped space characters ("  ")

might do.

You might also consider saying "at the end of an input line" rather than just "at the end of a line".

Dave <barx>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #53316:  62593-space.roff added by gbranden (42B - text/troff)
file #53317:  62593-nbspace.roff added by gbranden (24B - text/troff)
file #53318:  62593-motion.roff added by gbranden (28B - text/troff)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gbranden (Posted a comment)
  • -email is unavailable- added by barx (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 12 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-06-19 gbranden Attached File- Added 62593-space.roff, #53316
        Attached File- Added 62593-nbspace.roff, #53317
        Attached File- Added 62593-motion.roff, #53318
        Attached File- Added 62593-fixedspace.roff, #53319
    2022-06-15 gbranden StatusIn Progress Fixed
        Open/ClosedOpen Closed
        Planned ReleaseNone 1.23.0
    2022-06-15 gbranden StatusPostponed In Progress
    2022-06-10 gbranden StatusNone Postponed
    2022-06-06 gbranden Severity2 - Minor 3 - Normal
        Assigned toNone gbranden
    2022-06-06 gbranden CategoryCore General

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code