All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
To: Markus Heiser <markus.heiser@darmarit.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	LKML <linux-kernel@vger.kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	linux-doc@vger.kernel.org, Christoph Hellwig <hch@infradead.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Jani Nikula <jani.nikula@linux.intel.com>,
	Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH] doc: Explain light-handed markup preference a bit better
Date: Tue, 29 Nov 2016 09:54:00 -0200	[thread overview]
Message-ID: <20161129095400.0e698ff6@vento.lan> (raw)
In-Reply-To: <8EA6D751-36E7-4CEB-8817-1B186A685B96@darmarit.de>

Em Tue, 29 Nov 2016 11:28:12 +0100
Markus Heiser <markus.heiser@darmarit.de> escreveu:

> Am 29.11.2016 um 10:23 schrieb Daniel Vetter <daniel.vetter@ffwll.ch>:
> 
> > We already had a super-short blurb, but worth extending it I think:
> > We're still pretty far away from anything like a consensus, but
> > there's clearly a lot of people who prefer an as-light as possible
> > approach to converting existing .txt files to .rst. Make sure this is
> > properly taken into account and clear.
> > 
> > Motivated by discussions with Peter and Christoph and others.
> > 
> > v2:
> > - Mention that existing headings should be kept when converting
> > existing .txt files (Mauro).
> > - Explain that we prefer :: for quoting code, it's easier on the
> > eyes (Mauro).
> > - Explain that blindly converting outdated docs is harmful. Motived
> > by comments Peter did in our discussion.
> > 
> > Cc: Jonathan Corbet <corbet@lwn.net>
> > Cc: linux-doc@vger.kernel.org
> > Cc: Christoph Hellwig <hch@infradead.org>
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> > Documentation/kernel-documentation.rst | 44 ++++++++++++++++++++++++++++++++--
> > 1 file changed, 42 insertions(+), 2 deletions(-)  
> 
> Sorry for my dump remarks ...
> 
> * shouldn't it on top of Jon's docs-next?
> * should we lose a few words about tabs/indentation?
> 
> IMO indentation for reST markup should be 2 spaces, not
> tabs (8 spaces). I know about CodeStyling but I think this doc
> (markup) and not source-code. Code-examples should be indent
> by tabs as usual. BTW here is what CodingStyle says:
> 
>  Outside of comments, documentation and except in Kconfig,
>  spaces are never used for indentation, and the above example
>  is deliberately broken.
>  Get a decent editor and don't leave whitespace at the end of
>  lines.
> 
> ... encourages me to prefer spaces.

I agree that we should define the preferred spaces style.

Yet, I very much prefer that patches converting existing documents
to not touch whitespaces/tabs except when really needed.

>From my side, the editors I use to write documents are set to automatically 
convert 8 column alignments to tabs. I also have a script that I run when
needed, when I receive a patch with whitespaces at the end of lines.
It also converts spaces to tabs where needed.

So, whatever definition we use, IMO we should define that a tab has
8 spaces, and that tabs should be used if the alignment requires
more than 8 columns.

With regards of using indentation with 2 spaces, I don't have any
strong opinion.

>From what I remember, the scripts you used to convert the media
documents made a 4 spaces alignment for the media documentation
on several places, but I may be wrong.

Thanks,
Mauro

  reply	other threads:[~2016-11-29 11:54 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-29  9:23 [PATCH] doc: Explain light-handed markup preference a bit better Daniel Vetter
2016-11-29 10:28 ` Markus Heiser
2016-11-29 11:54   ` Mauro Carvalho Chehab [this message]
2016-11-29 10:38 ` Jani Nikula
2016-11-29 11:43   ` Mauro Carvalho Chehab
2016-11-29 15:08     ` Jani Nikula
2016-12-07 15:45       ` Daniel Vetter
2016-11-29 13:17 ` Daniel Vetter
2016-12-06  7:52   ` Peter Zijlstra
2016-12-07 15:45     ` Daniel Vetter
  -- strict thread matches above, loose matches on Subject: below --
2016-12-14 13:46 Daniel Vetter
2016-12-07 15:42 Daniel Vetter
2016-12-07 19:39 ` Jonathan Corbet
2016-12-08  9:10   ` Mauro Carvalho Chehab
2016-12-08 22:06     ` Daniel Vetter
2016-12-12 17:47       ` Mauro Carvalho Chehab
2016-12-12 17:54       ` Jonathan Corbet
2016-11-28 16:16 Daniel Vetter
2016-11-28 17:51 ` Mauro Carvalho Chehab

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=20161129095400.0e698ff6@vento.lan \
    --to=mchehab@s-opensource.com \
    --cc=corbet@lwn.net \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=hch@infradead.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markus.heiser@darmarit.de \
    --cc=peterz@infradead.org \
    /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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.