GNU bug report logs - #29943
[PATCH] doc: Describe Wayland status.

Previous Next

Full log

View this message in rfc822 format

From: ludo <at> gnu.org (Ludovic Courtès)
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 29943 <at> debbugs.gnu.org, Rutger Helling <rhelling <at> mykolab.com>, ng0 <ng0 <at> n0.is>
Subject: [bug#29943] [PATCH] doc: Describe Wayland status.
Date: Sat, 06 Jan 2018 22:47:42 +0100

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:

> ludo <at> gnu.org (Ludovic Courtès) writes:

[...]

>>> Under which conditions does this result in non-proper rendering?
>>> It's certainly not a Tex issue from what I can tell. So far I assumed it's just a convention
>>> because in some countries this is the default and in some not.
>>> I think we have a very short explanation in the Manual, but this never really
>>> explained why or what could go wrong. Maybe we could extend that.
>>
>> It’s a convention notably followed by Emacs’s ‘forward-sentence’
>> function, and also a Texinfo thing (info "(texinfo) Not Ending a
>> Sentence").
>>
>> Hmm actually the Texinfo manual now suggests the opposite (i.e., that it
>> needs help only for non-end-of-sentence spacing), but I wonder if it’s
>> accurate.
>>
>> Ludo’.
>
> The old texinfo section that touched that subject was the "Multiple
> Spaces" node[0]:
>
>       Ordinarily, TeX collapses multiple whitespace characters (space,
>       tab, and newline) into a single space.  (Info output, on the other
>       hand, preserves whitespace as you type it, except for changing a
>       newline into a space; this is why it is important to put two
>       spaces at the end of sentences in Texinfo documents.)
>
> The current version of the Texinfo manual indeed drops this advice and
> includes a new section "12.3.4 '@frenchspacing' VAL: Control Sentence
> Spacing" where we can learn about a setting that controls the appearance of
> the end of sentence spacing in the *output* of Info.
>
> It seems that at this point the only reason to keep this convention is
> to accommodate Emacs, where the variable `sentence-end-double-space' is
> true by default and means that[1]:
>
>     [...] a period followed by just one space does not count as the end of a
>     sentence, and the filling functions avoid breaking the line at such
>     a place.
>
> A justification for this is written in the Emacs manual[2]:
>
>     If you want to use just one space between sentences, you can set the
>     variable ‘sentence-end-double-space’ to ‘nil’ to make the sentence
>     commands stop for single spaces.  However, this has a drawback:
>     there is no way to distinguish between periods that end sentences
>     and those that indicate abbreviations.  For convenient and reliable
>     editing, we therefore recommend you follow the two-space convention.
>     The variable ‘sentence-end-double-space’ also affects filling (*note
>     Fill Commands::).
>
> [0]  https://docs.freebsd.org/info/texinfo/texinfo.info.Multiple_Spaces.html
> [1]  (elisp)Standard Regexps
> [2]  (emacs)Sentences

Excellent, thanks for explaining!

I pretty much agree with the Emacs explanation for that convention, but
I admit this is often surprising to newcomers.

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.