All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>, Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Keith Packard <keithp@keithp.com>
Subject: Re: [RFC] A first shot at asciidoc-based formatted docs
Date: Wed, 10 Feb 2016 18:12:49 +0200	[thread overview]
Message-ID: <87y4asr1by.fsf@intel.com> (raw)
In-Reply-To: <87ziv8zmpx.fsf@intel.com>

On Wed, 10 Feb 2016, Jani Nikula <jani.nikula@intel.com> wrote:
>> On Wed, Feb 10, 2016 at 1:09 AM, Jonathan Corbet <corbet@lwn.net> wrote:
>>>  - I'm not sold on the new inclusion mechanism.  Creating thousands of
>>>    little files and tracking them for dependencies and such doesn't seem
>>>    like a simplification or a path toward better performance.  I would
>>>    like to at least consider keeping the direct-from-source inclusion.

...

> Yes, my main motivation here was to get rid of the preprocessing step
> (currently tmpl->xml). I wanted to have the source documents in pure
> markup which could be directly processed by asciidoc. I wanted to have
> the editor markup helpers and syntax highlighting just work, with no
> extra non-markup cruft to confuse it. (For example, emacs tells me the
> current tmpl files are invalid XML because of the docproc directives.)
> This ties back to the dream above; just have .txt files with no
> preprocessing step, IMO it's less confusing for actually writing the
> docs.

I suppose a compromise could be to put the docproc directives in
asciidoc comments to keep the files pure asciidoc and to hide the
preprocessing step from the document writers, i.e. call them asciidoc
and name them .txt instead of .tmpl or something. While I'm not thrilled
about the idea of keeping docproc around, this would be progress, would
avoid the EXPORT_SYMBOL problem for now, and, most importantly, wouldn't
block us from doing what I suggested as a future iteration.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

  reply	other threads:[~2016-02-10 16:13 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-25 23:28 [RFC] A first shot at asciidoc-based formatted docs Jonathan Corbet
2016-01-25 23:28 ` [PATCH 1/4] kernel-doc: add support for asciidoc output Jonathan Corbet
2016-01-25 23:28 ` [PATCH 2/4] docproc: handle asciidoc templates Jonathan Corbet
2016-01-25 23:28 ` [PATCH 3/4] Docs: Makefile tweaks for " Jonathan Corbet
2016-01-25 23:28 ` [PATCH 4/4] Docs: add a sample asciidoc template Jonathan Corbet
2016-01-26 12:08 ` [RFC] A first shot at asciidoc-based formatted docs Jani Nikula
2016-01-26 12:08   ` [RFC 01/10] kernel-doc: rewrite usage description, remove duplicated comments Jani Nikula
2016-01-26 12:08   ` [RFC 02/10] kernel-doc: add support for asciidoc output Jani Nikula
2016-01-26 12:08   ` [RFC 03/10] kernel-doc: support printing exported and non-exported symbols Jani Nikula
2016-01-26 12:08   ` [RFC 04/10] kernel-doc: add support for printing DOC: comments with escaped names Jani Nikula
2016-01-26 12:08   ` [RFC 05/10] scripts: add asciidoc-includes to extract includes from asciidoc Jani Nikula
2016-01-26 12:08   ` [RFC 06/10] scripts: add a kernel-doc helper for special invocation Jani Nikula
2016-01-26 12:08   ` [RFC 07/10] scripts: add tool for generating asciidoc dependencies and rules Jani Nikula
2016-01-26 12:08   ` [RFC 08/10] scripts: add a crude converter from DocBook tmpl to asciidoc Jani Nikula
2016-01-26 12:08   ` [RFC 09/10] Documentation: convert gpu.tmpl to gpu.txt Jani Nikula
2016-01-26 12:08   ` [RFC 10/10] Documentation: build asciidoc documentation Jani Nikula
2016-01-26 12:17   ` [RFC] A first shot at asciidoc-based formatted docs Daniel Vetter
2016-01-26 12:38     ` Jani Nikula
2016-01-26 14:48   ` Jonathan Corbet
2016-01-26 14:52     ` Jonathan Corbet
2016-02-10  0:09   ` Jonathan Corbet
2016-02-10  8:07     ` Daniel Vetter
2016-02-10 14:03       ` Jani Nikula
2016-02-10 16:12         ` Jani Nikula [this message]
2016-02-10 20:56         ` Jonathan Corbet
2016-02-11 15:18           ` Keith Packard
2016-02-10 20:45       ` Jonathan Corbet
2016-02-10 23:01     ` Keith Packard
2016-02-11 13:44       ` Jani Nikula
2016-02-11 15:21         ` Keith Packard
2016-02-13  3:20       ` Keith Packard

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=87y4asr1by.fsf@intel.com \
    --to=jani.nikula@intel.com \
    --cc=corbet@lwn.net \
    --cc=daniel.vetter@ffwll.ch \
    --cc=keithp@keithp.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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.