[bug#29943] [PATCH] doc: Describe Wayland status.

[bug#29943] [PATCH] doc: Describe Wayland status.

[Rutger Helling]

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

This patch adds a small paragraph to the documentation about the
current status of Wayland in Guix.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-doc-Describe-Wayland-status.patch --]
[-- Type: text/x-patch, Size: 1624 bytes --]

From a790d403524df182cdd8aa35931b989234d874cd Mon Sep 17 00:00:00 2001
From: Rutger Helling <rhelling@mykolab.com>
Date: Tue, 2 Jan 2018 13:14:09 +0100
Subject: [PATCH] doc: Describe Wayland status.

* doc/guix.texi (Desktop Services): Add a paragraph about the current status of
Wayland in Guix.
---
 doc/guix.texi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/doc/guix.texi b/doc/guix.texi
index 1d1f30f00..336e94764 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -45,6 +45,7 @@ Copyright @copyright{} 2017 George Clemmer@*
 Copyright @copyright{} 2017 Andy Wingo@*
 Copyright @copyright{} 2017 Arun Isaac@*
 Copyright @copyright{} 2017 nee
+Copyright @copyright{} 2018 Rutger Helling@*
 
 Permission is granted to copy, distribute and/or modify this document
 under the terms of the GNU Free Documentation License, Version 1.3 or
@@ -12151,6 +12152,13 @@ limited number of special-purpose system interfaces.  Additionally,
 adding a service made by @code{mate-desktop-service} adds the MATE
 metapackage to the system profile.
 
+The desktop environments in Guix use X11 by default. If you'd like to
+use the more modern display server protocol called Wayland, you need
+to use the @code{sddm-service} instead of the @code{slim-service} for
+the graphical login manager. You should then select the ``GNOME
+(Wayland)'' session in SDDM. Currently only GNOME has support for
+Wayland.
+
 @deffn {Scheme Procedure} gnome-desktop-service
 Return a service that adds the @code{gnome} package to the system
 profile, and extends polkit with the actions from
-- 
2.15.1


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

[bug#29943] [PATCH] doc: Describe Wayland status.

[Ludovic Courtès]

Hello!

Rutger Helling <rhelling@mykolab.com> skribis:

> From a790d403524df182cdd8aa35931b989234d874cd Mon Sep 17 00:00:00 2001
> From: Rutger Helling <rhelling@mykolab.com>
> Date: Tue, 2 Jan 2018 13:14:09 +0100
> Subject: [PATCH] doc: Describe Wayland status.
>
> * doc/guix.texi (Desktop Services): Add a paragraph about the current status of
> Wayland in Guix.

Good idea!

> +++ b/doc/guix.texi
> @@ -45,6 +45,7 @@ Copyright @copyright{} 2017 George Clemmer@*
>  Copyright @copyright{} 2017 Andy Wingo@*
>  Copyright @copyright{} 2017 Arun Isaac@*
>  Copyright @copyright{} 2017 nee
> +Copyright @copyright{} 2018 Rutger Helling@*

You need @* on the line before yours, but not on yours (it introduces a
linebreak).

> +The desktop environments in Guix use X11 by default. If you'd like to

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.

> +use the more modern display server protocol called Wayland, you need

s/more modern/newer/  :-)

> +to use the @code{sddm-service} instead of the @code{slim-service} for
> +the graphical login manager. You should then select the ``GNOME
> +(Wayland)'' session in SDDM. Currently only GNOME has support for
> +Wayland.

Otherwise LGTM, thanks!

Ludo’.

[bug#29943] [PATCH] doc: Describe Wayland status.

[ng0]

[-- Attachment #1: Type: text/plain, Size: 2047 bytes --]

Ludovic Courtès transcribed 1.3K bytes:
> Hello!
> 
> Rutger Helling <rhelling@mykolab.com> skribis:
> 
> > From a790d403524df182cdd8aa35931b989234d874cd Mon Sep 17 00:00:00 2001
> > From: Rutger Helling <rhelling@mykolab.com>
> > Date: Tue, 2 Jan 2018 13:14:09 +0100
> > Subject: [PATCH] doc: Describe Wayland status.
> >
> > * doc/guix.texi (Desktop Services): Add a paragraph about the current status of
> > Wayland in Guix.
> 
> Good idea!
> 
> > +++ b/doc/guix.texi
> > @@ -45,6 +45,7 @@ Copyright @copyright{} 2017 George Clemmer@*
> >  Copyright @copyright{} 2017 Andy Wingo@*
> >  Copyright @copyright{} 2017 Arun Isaac@*
> >  Copyright @copyright{} 2017 nee
> > +Copyright @copyright{} 2018 Rutger Helling@*
> 
> You need @* on the line before yours, but not on yours (it introduces a
> linebreak).
> 
> > +The desktop environments in Guix use X11 by default. If you'd like to
> 
> 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.

> > +use the more modern display server protocol called Wayland, you need
> 
> s/more modern/newer/  :-)
> 
> > +to use the @code{sddm-service} instead of the @code{slim-service} for
> > +the graphical login manager. You should then select the ``GNOME
> > +(Wayland)'' session in SDDM. Currently only GNOME has support for
> > +Wayland.
> 
> Otherwise LGTM, thanks!
> 
> Ludo’.
> 
> 
> 
> 

-- 
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://c.n0.is/ng0_pubkeys/tree/keys
  WWW: https://n0.is/a/  ::  https://ea.n0.is

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[bug#29943] [PATCH] doc: Describe Wayland status.

[Ludovic Courtès]

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

[bug#29943] [PATCH] doc: Describe Wayland status.

[Maxim Cournoyer]

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

[bug#29943] [PATCH] doc: Describe Wayland status.

[Ludovic Courtès]

Hi Maxim,

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

> ludo@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’.

bug#29943: [PATCH] doc: Describe Wayland status.

[Rutger Helling]

[-- Attachment #1: Type: text/plain, Size: 1659 bytes --]

Thanks for the review! I updated the patch according to your feedback
and pushed it.

On Sat, 06 Jan 2018 15:16:46 +0100
ludo@gnu.org (Ludovic Courtès) wrote:

> Hello!
> 
> Rutger Helling <rhelling@mykolab.com> skribis:
> 
> > From a790d403524df182cdd8aa35931b989234d874cd Mon Sep 17 00:00:00
> > 2001 From: Rutger Helling <rhelling@mykolab.com>
> > Date: Tue, 2 Jan 2018 13:14:09 +0100
> > Subject: [PATCH] doc: Describe Wayland status.
> >
> > * doc/guix.texi (Desktop Services): Add a paragraph about the
> > current status of Wayland in Guix.  
> 
> Good idea!
> 
> > +++ b/doc/guix.texi
> > @@ -45,6 +45,7 @@ Copyright @copyright{} 2017 George Clemmer@*
> >  Copyright @copyright{} 2017 Andy Wingo@*
> >  Copyright @copyright{} 2017 Arun Isaac@*
> >  Copyright @copyright{} 2017 nee
> > +Copyright @copyright{} 2018 Rutger Helling@*  
> 
> You need @* on the line before yours, but not on yours (it introduces
> a linebreak).
> 
> > +The desktop environments in Guix use X11 by default. If you'd like
> > to  
> 
> 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.
> 
> > +use the more modern display server protocol called Wayland, you
> > need  
> 
> s/more modern/newer/  :-)
> 
> > +to use the @code{sddm-service} instead of the @code{slim-service}
> > for +the graphical login manager. You should then select the ``GNOME
> > +(Wayland)'' session in SDDM. Currently only GNOME has support for
> > +Wayland.  
> 
> Otherwise LGTM, thanks!
> 
> Ludo’.


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