From: Mauro Carvalho Chehab <mchehab@kernel.org>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/5] docs: improve the HTML formatting of kerneldoc comments
Date: Thu, 6 Oct 2022 06:53:29 +0100 [thread overview]
Message-ID: <20221006065329.787c2592@sal.lan> (raw)
In-Reply-To: <87r0zmqkao.fsf@intel.com>
Em Wed, 05 Oct 2022 19:58:39 +0300
Jani Nikula <jani.nikula@linux.intel.com> escreveu:
> On Tue, 04 Oct 2022, Jonathan Corbet <corbet@lwn.net> wrote:
> > Make a few changes to cause functions documented by kerneldoc to stand out
> > better in the rendered documentation. Specifically, change kernel-doc to
> > put the description section into a ".. container::" section, then add a bit
> > of CSS to indent that section relative to the function prototype (or struct
> > or enum definition). Tweak a few other CSS parameters while in the
> > neighborhood to improve the formatting.
>
> Way back I tried to keep the formatting changes minimal to avoid opening
> that particular can of worms along with the rest of the Sphinx
> transition.
>
> But I do wonder if people find value in repeating e.g. the struct
> definitions in the documentation. I'd argue the rendered documentation
> is more for an overview, and if you need to know the exact details,
> you'll be in the editor typing code and you can look up the actual
> definition in source. Having the definition feels maybe a bit excessive.
I have split thoughts regards to it. The advantage of having the
struct definition there is to allow checking the type of each argument,
which is useful. It also provide a way to double-check if the parser
is dealing well with the argument, but, on the counter-side, the
type printed by kernel-doc may not be identical to what's inside the
Kernel, on some special cases, as the parse logic for arguments is
complex. The same applies on functions and macros.
>
> We also don't use Sphinx C Domain's ".. c:member::" for struct/union
> members,
I'm wondering how much extra build time this would impact ;-)
If the impact is not huge, I'm in favor of using it.
> or ".. c:enumerator::" for enumeration contants.
This one can be more problematic, as it could break existing
cross-references.
> They provide arguably nicer rendering out of the box than our stuff.
Agreed.
> The Sphinx way to do parameter lists would be field lists i.e. ":param
> foo: description". Ditto for return values ":return: description". (Not
> saying we should convert the comments, but kernel-doc the script could
> emit those.)
>
> Perhaps we'd be better off going towards Sphinx standard usage than
> tweaking our own thing?
>
> I'm afraid I don't have the time to work on this. Talk is cheap and all
> that. My two cents.
>
> Anyway, here are some examples how this might look like: [1].
>
>
> BR,
> Jani.
>
>
>
> [1] https://hawkmoth.readthedocs.io/en/latest/examples.html
It reminds that we're currently lacking a way to describe non-macro
#defines. In special for bit-based defines, it would be nice to have
a good way to document them, without needing to convert defines into
enums.
Regards,
Mauro
next prev parent reply other threads:[~2022-10-06 5:53 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-04 20:12 [PATCH RFC 0/5] docs: Improvements to our HTML output Jonathan Corbet
2022-10-04 20:12 ` [PATCH 1/5] docs: Switch the default HTML theme to alabaster Jonathan Corbet
2022-10-05 17:22 ` Jani Nikula
2022-10-05 17:49 ` Jonathan Corbet
2022-10-06 5:09 ` Mauro Carvalho Chehab
2022-10-06 5:17 ` Mauro Carvalho Chehab
2022-10-04 20:12 ` [PATCH 2/5] docs: tweak some Alabaster style parameters Jonathan Corbet
2022-10-05 17:28 ` Jani Nikula
2022-10-05 17:46 ` Jonathan Corbet
2022-10-04 20:12 ` [PATCH 3/5] docs: update sphinx.rst to reflect the default theme change Jonathan Corbet
2022-10-04 20:12 ` [PATCH 4/5] docs: sphinx-pre-install: don't require the RTD theme Jonathan Corbet
2022-10-04 20:12 ` [PATCH 5/5] docs: improve the HTML formatting of kerneldoc comments Jonathan Corbet
2022-10-05 5:59 ` Mauro Carvalho Chehab
2022-10-05 15:29 ` Jonathan Corbet
2022-10-06 5:41 ` Mauro Carvalho Chehab
2022-10-07 16:26 ` Jonathan Corbet
2022-10-05 16:58 ` Jani Nikula
2022-10-06 5:53 ` Mauro Carvalho Chehab [this message]
2022-10-06 8:29 ` Jani Nikula
2022-10-05 5:40 ` [PATCH RFC 0/5] docs: Improvements to our HTML output Mauro Carvalho Chehab
2022-10-05 15:33 ` Jonathan Corbet
2022-10-06 5:04 ` Mauro Carvalho Chehab
2022-10-06 11:11 ` Jani Nikula
2022-10-06 13:49 ` Jonathan Corbet
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=20221006065329.787c2592@sal.lan \
--to=mchehab@kernel.org \
--cc=corbet@lwn.net \
--cc=jani.nikula@linux.intel.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 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).