[Bug 232779] mdoc: Two spaces after a period and a closing bracket: "foo .) bar"

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232779

Yuri Pankov <yuripv at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|Latest                      |CURRENT
            Product|Documentation               |Base System
          Component|Manual Pages                |bin
             Status|Open                        |Closed
           Assignee|bugs at FreeBSD.org            |yuripv at FreeBSD.org
         Resolution|---                         |Works As Intended

--- Comment #4 from Yuri Pankov <yuripv at FreeBSD.org> ---
Closing this per Ingo Schwarze reply, copied below:

---
Yes, that is a feature.

Mandoc does some heuristics to guess where sentences end, and so
does groff, traditionally, even though the behaviour of both is not
completely identical.  When these programs detect the (likely) end
of a sentence, they insert a double space into the output,
conforming to traditional typewriter conventions, even though
this is no longer common practice in proportional-font typesetting.
But i do think the double space after the end of a sentence still
makes reading text in monospace fonts easier.

The basic idea is to assume the end of a sentence when a full stop,
an exclamation mark, or a question mark appears at the end of an
input line.  If that character is preceded by an alphanumeric
character (assumed to be the end of a word), it is even assumed
to be the end of a sentence when followed by one or more closing
delimiters.  They said, "Like in this case."

There are many subtleties, in particular when macros are involved.

That said, in your minimal example "foo.)\nbar", the double space
is unambigously correct.

The case reported by Mateusz, "port...)\ncan be used" is slightly
less clear.  Then again, an ellipsis often marks the end of a
sentence, like in this case...  So mandoc treats it just like the
full stop when it appears at the end of an input line.


Benjamin Kaduk wrote:

> The rendering changes if you put a space before the ellipsis, FWIW.

Yes, in that case, mandoc no longer feels sure whether this is a
sentence, because in English text, the punctuation marking the end
end of a sentence is supposed to follow the last word without
intervening whitespace.

> Escaping the '.'s with backslashes also works.

Do *NOT* do that, if "\." appears in a manual page, that is almost
always wrong and rarely has the effect intended by the author.

If you need to escape a delimiter (including a dot) such that it
is not treated as a delimiter, put a zero-width space "\&" next
to it - conventionally, it is put before the dot in trailing
macro arguments (e.g. .Sq \&.) and after the dot to prevent end
of sentence detection (e.g. e.g.\&), but either order works.
For details, see

  https://man.openbsd.org/mdoc.7#Delimiters
  https://man.openbsd.org/roff.7#Sentence_Spacing

So if you really want to prevent end of sentence detection here,
you would say

  Any netmap port type (physical interface,
  VALE switch, pipe, monitor port...\&)
  can be used.

While i admit there are some weird cases and some groff-mandoc
differences in this area, i don't see anything to fix in the specific
case you report.  Also, groff and mandoc behave identically for
this input file:

.Dd November 23, 2018
.Dt TEST 1
.Os
.Sh NAME
.Nm test
.Nd test
.Sh DESCRIPTION
Any netmap port type (physical interface, VALE switch, pipe, monitor port...)
can be used.

Both emit the double space.

Yours,
  Ingo

-- 
You are receiving this mail because:
You are on the CC list for the bug.