Em Wed, 05 Oct 2022 19:58:39 +0300 Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx> escreveu: > On Tue, 04 Oct 2022, Jonathan Corbet <corbet@xxxxxxx> 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
