discuss@mandoc.bsd.lv
 help / color / mirror / Atom feed
From: Yuri Pankov <yuripv@yuripv.net>
To: Ingo Schwarze <schwarze@usta.de>
Cc: mandoc-discuss <discuss@mandoc.bsd.lv>,
	Mateusz Piotrowski <0mp@FreeBSD.org>,
	Benjamin Kaduk <bjk@FreeBSD.org>
Subject: Re: two spaces after a period, closing bracket, and a newline
Date: Sat, 24 Nov 2018 19:00:29 +0300	[thread overview]
Message-ID: <6f1ff2e0-8ec1-ea2c-dd2d-1ef979570c46@yuripv.net> (raw)
In-Reply-To: <20181123224217.GC7177@athene.usta.de>


[-- Attachment #1.1: Type: text/plain, Size: 3731 bytes --]

Ingo Schwarze wrote:
> Hi Yuri, Mateusz, Benjamin,
> 
> Yuri Pankov wrote on Fri, Nov 23, 2018 at 11:35:41PM +0300:
> 
>> Reported by Mateusz Piotrowski in
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232779:
>>
>> A simple
> 
> This is very far from simple.  ;-)
> 
>> rendering issue -- two spaces are displayed after a period and
>> closing bracket,
> 
> Brackets would behave differently in this respect - we are talking
> about a closing parenthesis here.

Indeed, sorry.

>> *and* there's a new line, i.e. `printf "foo.)\nbar" |
>> mandoc` displays "foo.)  bar".
> 
> Yes, that is a feature.

Thanks for the detailed (as always) answer.

> 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
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

      reply	other threads:[~2018-11-24 16:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-23 20:35 Yuri Pankov
2018-11-23 22:42 ` Ingo Schwarze
2018-11-24 16:00   ` Yuri Pankov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6f1ff2e0-8ec1-ea2c-dd2d-1ef979570c46@yuripv.net \
    --to=yuripv@yuripv.net \
    --cc=0mp@FreeBSD.org \
    --cc=bjk@FreeBSD.org \
    --cc=discuss@mandoc.bsd.lv \
    --cc=schwarze@usta.de \
    --subject='Re: two spaces after a period, closing bracket, and a newline' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).