linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: Markus Heiser <markus.heiser@darmarit.de>,
	Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	hverkuil@xs4all.nl, daniel.vetter@ffwll.ch, airlied@gmail.com,
	grant.likely@secretlab.ca, rdunlap@infradead.org,
	keithp@keithp.com
Subject: Re: [PATCH] doc: flat-table directive
Date: Fri, 01 Jul 2016 16:09:49 +0300	[thread overview]
Message-ID: <87d1mxpkrm.fsf@intel.com> (raw)
In-Reply-To: <BD7AE7E8-5F9F-4271-B870-5F291A6F2EE8@darmarit.de>

On Fri, 01 Jul 2016, Markus Heiser <markus.heiser@darmarit.de> wrote:
> In Sphinx, the code-block directive is a literal block, no refs or markup
> will be interpreted. This is different to what you know from DocBook.
> I will look for a solution, that matches your requirement.

Parsed literal block solves the problem, but brings other problems like
requiring escaping for a lot of stuff. And you lose syntax
highlighting. It would be great to have a middle ground, like a
"semi-parsed code block" where the references are parsed but nothing
else.

http://docutils.sourceforge.net/docs/ref/rst/directives.html#parsed-literal-block

> OK, checking dead internal links might be one requirement more. Normally 
> sphinx reports internal refs which are broken with a WARNING, but I have to
> analyze what xmllint checks and how we could realize something similar
> in sphinx / or if it is enough what sphinx reports.

When we turn function() and &struct structure references to Sphinx
references, we pretty much rely on *not* being strict about all the
targets existing. At least for now. In an ideal world we'd aim for -n
and -W sphinx-build options, but we're far from that, and I don't know
if it's really possible ever.

Is it possible to set -n and/or -W on a per-rst file basis, either in
the top config file or from within the rst file itself? Then we could
gradually improve this, and subsystems that really care about this could
be in the forefront.

> But before I will send out some small patches which are needed 
> first (IMHO). E.g. customizing the RTD theme for rendering large 
> tables in HTML well and activation of useful extensions like todolist.
> I have this in my "chaotic bulk" patch :-) ... I will separate it out
> an send it to Jon one by one.

Btw I don't think we are really attached to the RTD theme. It's just
something I picked that was prettier than the default theme, and was
widely available and packaged in distros. Ideally, we should probably
keep the customization at a level where it's possible for people to
easily use different themes. That said, rendering big tables in the RTD
theme is definitely an issue.

I'd also aim to be fairly conservative at first in terms of the rst
features and Sphinx extensions we use. Keep it simple. It's really easy
to go overboard in the beginning. See how things pan out and gradually
extend from there.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

  parent reply	other threads:[~2016-07-01 13:10 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-30 12:00 [PATCH] doc: flat-table directive Markus Heiser
2016-06-30 12:00 ` [PATCH] doc-rst: flat-table directive - initial implementation Markus Heiser
2016-06-30 19:05 ` [PATCH] doc: flat-table directive Jonathan Corbet
2016-06-30 19:31   ` Mauro Carvalho Chehab
2016-06-30 19:44   ` Mauro Carvalho Chehab
2016-07-01  8:44     ` Markus Heiser
2016-07-01  9:38       ` Mauro Carvalho Chehab
2016-07-01 10:44         ` Jani Nikula
2016-07-01 11:12           ` Markus Heiser
2016-07-01 11:56             ` Jani Nikula
2016-07-01 12:03               ` [docs-next PATCH] Documentation: add cleanmediadocs to the documentation targets Jani Nikula
2016-07-01 12:24                 ` [docs-next PATCH] Documentation/sphinx: skip build if user requested specific DOCBOOKS Jani Nikula
2016-07-01 12:31                   ` Markus Heiser
2016-07-01 13:15                   ` Mauro Carvalho Chehab
2016-07-01 13:31                     ` Jani Nikula
2016-07-01 15:09                       ` Mauro Carvalho Chehab
2016-07-01 12:04               ` [PATCH] doc: flat-table directive Markus Heiser
2016-07-01 12:26                 ` Jani Nikula
2016-07-01 13:06                   ` Mauro Carvalho Chehab
2016-07-01 12:52           ` Mauro Carvalho Chehab
2016-07-01 12:58           ` Jonathan Corbet
2016-07-01 14:45             ` Markus Heiser
2016-07-01 17:24               ` Jani Nikula
2016-07-01 18:17                 ` Mauro Carvalho Chehab
2016-07-01 18:47                   ` Jani Nikula
2016-07-01 12:18         ` Markus Heiser
2016-07-01 12:59           ` Mauro Carvalho Chehab
2016-07-01 13:09           ` Jani Nikula [this message]
2016-07-01 14:07             ` Markus Heiser
2016-07-01 15:00               ` Mauro Carvalho Chehab
2016-07-01 15:01               ` Mauro Carvalho Chehab
2016-07-06 22:58               ` Mauro Carvalho Chehab
2016-07-01 12:08     ` Jani Nikula
2016-07-01  6:35   ` Markus Heiser
2016-07-01 18:25 ` Captions numbering support 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=87d1mxpkrm.fsf@intel.com \
    --to=jani.nikula@intel.com \
    --cc=airlied@gmail.com \
    --cc=corbet@lwn.net \
    --cc=daniel.vetter@ffwll.ch \
    --cc=grant.likely@secretlab.ca \
    --cc=hverkuil@xs4all.nl \
    --cc=keithp@keithp.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markus.heiser@darmarit.de \
    --cc=mchehab@osg.samsung.com \
    --cc=rdunlap@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 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 NNTP newsgroup(s).