unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 29943@debbugs.gnu.org, Rutger Helling <rhelling@mykolab.com>
Subject: [bug#29943] [PATCH] doc: Describe Wayland status.
Date: Sat, 06 Jan 2018 16:37:48 -0500	[thread overview]
Message-ID: <87r2r2ekib.fsf@gmail.com> (raw)
In-Reply-To: <87h8rysouh.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sat, 06 Jan 2018 21:40:22 +0100")

Hello,

ludo@gnu.org (Ludovic Courtès) writes:

> ng0 <ng0@n0.is> skribis:
>
>> Ludovic Courtès transcribed 1.3K bytes:
>
> [...]
>
>>> s/X11/the Xorg display server/ (in an attempt not to assume a too
>>> technical audience.)
>>> 
>>> Also, please always put two spaces after an end-of-sentence period, to
>>> ensure proper rendering.
>>
>> 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

I hope that clears up this up whys of this somewhat convention.

Maxim

  reply	other threads:[~2018-01-06 21:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-02 12:18 [bug#29943] [PATCH] doc: Describe Wayland status Rutger Helling
2018-01-06 14:16 ` Ludovic Courtès
2018-01-06 14:43   ` ng0
2018-01-06 20:40     ` Ludovic Courtès
2018-01-06 21:37       ` Maxim Cournoyer [this message]
2018-01-06 21:47         ` Ludovic Courtès
2018-01-06 17:20   ` bug#29943: " Rutger Helling

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

  List information: https://guix.gnu.org/

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

  git send-email \
    --in-reply-to=87r2r2ekib.fsf@gmail.com \
    --to=maxim.cournoyer@gmail.com \
    --cc=29943@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    --cc=rhelling@mykolab.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).