Message-ID: <875ygxqrrf.fsf@intel.com>
Date:   Thu, 06 Oct 2022 11:29:40 +0300
From:   Jani Nikula <jani.nikula@...ux.intel.com>
To:     Mauro Carvalho Chehab <mchehab@...nel.org>
Cc:     Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/5] docs: improve the HTML formatting of kerneldoc
 comments

On Thu, 06 Oct 2022, Mauro Carvalho Chehab <mchehab@...nel.org> wrote:
> Em Wed, 05 Oct 2022 19:58:39 +0300
> Jani Nikula <jani.nikula@...ux.intel.com> escreveu:
>
>> On Tue, 04 Oct 2022, Jonathan Corbet <corbet@....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.

Two alternatives to removing it come to mind:

- Generating links to git.kernel.org at right version, file and line.

- A collapsible (and collapsed by default) code box. I think this needs
  html/css hacking, not possible in Sphinx out of the box.

>> 
>> 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.

Certainly.

>
>> 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.

ITYM simple or non-function-like macros. Sphinx supports ".. macro::"
for that nowadays, but don't know since what version. That's what I use
in Hawkmoth, and ".. function::" for macros with args.

BR,
Jani.

>
> Regards,
> Mauro

-- 
Jani Nikula, Intel Open Source Graphics Center

Powered by blists - more mailing lists