The current ReStructuredText formatting results in "--", used to
indicate the end of the kernel command-line parameters, appearing as
an en-dash instead of two hyphens; this patch formats them as code,
"``--``", as done elsewhere in the documentation.
Signed-off-by: Stephen Kitt <[email protected]>
---
Documentation/admin-guide/kernel-parameters.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.rst b/Documentation/admin-guide/kernel-parameters.rst
index 0124980dca2d..b8d479b76648 100644
--- a/Documentation/admin-guide/kernel-parameters.rst
+++ b/Documentation/admin-guide/kernel-parameters.rst
@@ -9,11 +9,11 @@ and sorted into English Dictionary order (defined as ignoring all
punctuation and sorting digits before letters in a case insensitive
manner), and with descriptions where known.
-The kernel parses parameters from the kernel command line up to "--";
+The kernel parses parameters from the kernel command line up to "``--``";
if it doesn't recognize a parameter and it doesn't contain a '.', the
parameter gets passed to init: parameters with '=' go into init's
environment, others are passed as command line arguments to init.
-Everything after "--" is passed as an argument to init.
+Everything after "``--``" is passed as an argument to init.
Module parameters can be specified in two ways: via the kernel command
line with a module name prefix, or via modprobe, e.g.::
--
2.11.0
On Thu, 27 Jun 2019 15:59:38 +0200
Stephen Kitt <[email protected]> wrote:
> The current ReStructuredText formatting results in "--", used to
> indicate the end of the kernel command-line parameters, appearing as
> an en-dash instead of two hyphens; this patch formats them as code,
> "``--``", as done elsewhere in the documentation.
>
> Signed-off-by: Stephen Kitt <[email protected]>
A worthy fix, I've applied it. This seems like the sort of annoyance that
will bite us over and over, though. We might want to find a more
comprehensive way to turn this behavior off.
Thanks,
jon
On Fri, 28 Jun 2019 09:10:21 -0600, Jonathan Corbet <[email protected]> wrote:
> On Thu, 27 Jun 2019 15:59:38 +0200
> > The current ReStructuredText formatting results in "--", used to
> > indicate the end of the kernel command-line parameters, appearing as
> > an en-dash instead of two hyphens; this patch formats them as code,
> > "``--``", as done elsewhere in the documentation.
> >
> > Signed-off-by: Stephen Kitt <[email protected]>
>
> A worthy fix, I've applied it. This seems like the sort of annoyance that
> will bite us over and over, though. We might want to find a more
> comprehensive way to turn this behavior off.
Right, looking further shows a large number of places where -- is handled
incorrectly. The following patch disables this “smart” handling wholesale;
I’ll follow up (in the next few days) with patches to use real em- and
en-dashes where appropriate.
Regards,
Stephen
From 3b10d01decfec38a124be75739b398a3dcd9d5ce Mon Sep 17 00:00:00 2001
From: Stephen Kitt <[email protected]>
Date: Fri, 28 Jun 2019 20:34:31 +0200
Subject: [PATCH] Disable Sphinx SmartyPants in HTML output
The handling of dashes in particular results in confusing
documentation in a number of instances, since "--" becomes an
en-dash. This disables SmartyPants wholesale, losing smart quotes
along with smart dashes.
With Sphinx 1.6 we could fine-tune the conversion, using the new
smartquotes and smartquotes_action settings.
Signed-off-by: Stephen Kitt <[email protected]>
---
Documentation/conf.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/conf.py b/Documentation/conf.py
index 7ace3f8852bd..966dbdfafcd1 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -200,7 +200,7 @@ html_context = {
# If true, SmartyPants will be used to convert quotes and dashes to
# typographically correct entities.
-#html_use_smartypants = True
+html_use_smartypants = False
# Custom sidebar templates, maps document names to template names.
#html_sidebars = {}
--
2.11.0
On Fri, 28 Jun 2019 20:38:41 +0200
Stephen Kitt <[email protected]> wrote:
> Right, looking further shows a large number of places where -- is handled
> incorrectly. The following patch disables this “smart” handling wholesale;
> I’ll follow up (in the next few days) with patches to use real em- and
> en-dashes where appropriate.
Thanks for figuring that out, it seems like the right thing to do.
Let's not worry about "real" dashes for now. Not everybody welcomes
non-ascii characters in the docs and, for dashes, it's something I deemed
not worth fighting about.
Thanks,
jon
On 6/28/19 11:48 AM, Jonathan Corbet wrote:
> On Fri, 28 Jun 2019 20:38:41 +0200
> Stephen Kitt <[email protected]> wrote:
>
>> Right, looking further shows a large number of places where -- is handled
>> incorrectly. The following patch disables this “smart” handling wholesale;
>> I’ll follow up (in the next few days) with patches to use real em- and
>> en-dashes where appropriate.
>
> Thanks for figuring that out, it seems like the right thing to do.
>
> Let's not worry about "real" dashes for now. Not everybody welcomes
> non-ascii characters in the docs and, for dashes, it's something I deemed
> not worth fighting about.
Ack that. Thanks.
--
~Randy
On Fri, 28 Jun 2019 12:48:04 -0600, Jonathan Corbet <[email protected]> wrote:
> On Fri, 28 Jun 2019 20:38:41 +0200
> Stephen Kitt <[email protected]> wrote:
>
> > Right, looking further shows a large number of places where -- is handled
> > incorrectly. The following patch disables this “smart” handling wholesale;
> > I’ll follow up (in the next few days) with patches to use real em- and
> > en-dashes where appropriate.
>
> Thanks for figuring that out, it seems like the right thing to do.
>
> Let's not worry about "real" dashes for now. Not everybody welcomes
> non-ascii characters in the docs and, for dashes, it's something I deemed
> not worth fighting about.
Indeed, there are more important things to worry about than dashes.
Regards,
Stephen