From: "Nícolas F. R. A. Prado" <n@nfraprado.net>
To: linux-doc@vger.kernel.org
Cc: "Jonathan Corbet" <corbet@lwn.net>,
"Mauro Carvalho Chehab" <mchehab+huawei@kernel.org>,
"Matthew Wilcox" <willy@infradead.org>,
linux-kernel@vger.kernel.org,
"André Almeida" <andrealmeid@collabora.com>,
~lkcamp/patches@lists.sr.ht
Subject: [RFC PATCH 0/2] docs: automarkup.py: Add literal markup of known constants
Date: Tue, 8 Jun 2021 22:43:06 -0300 [thread overview]
Message-ID: <20210609014308.234027-1-n@nfraprado.net> (raw)
Hi,
a while back Matthew suggested adding automatic markup of known constants, like
NULL and error codes, as literals [1]. This is a great idea since those literals
are very frequently used throughout the documentation and are fixed names, so we
can easily match them without false positives and make the source files less
cluttered.
Patch 1 adds that feature to automarkup.py, while patch 2 removes the no longer
needed markup from the xarray.rst file which was given as an example.
Some things I'd like to discuss:
* As a first draft I added the constants I found on xarray.rst plus all error
codes from errno-base.h and errno.h. We don't need to start with everything,
but we can certainly do better than this. What are common constants that
should be added here? (Matthew mentioned ANSI C or POSIX, some reference to
the constants in those would be great, even more if they are easily parsable)
* The Literals list added is already a bit big with just the error codes, so
perhaps we should move them to a separate plain text file that is read on
startup?
* There was also mention of automatically converting uppercase words to
literals. I'm not so sure about that one so I left it out for now.
The example given was XA_MARK_0, which is a #define in xarray.h. The way
to go here is certainly to first use kernel-doc to get it included in the
documentation, and then cross-reference to it. FWICT at the moment kernel-doc
for defines should be done like for functions (but the parenthesis can be
omitted, although they show up in the output):
/**
* XA_MARK_0 - Brief description.
*
* Description of the type.
*/
At the current state, the cross-reference would then need to be done either
through plain :c:macro:`XA_MARK_0`, or, by relying on automarkup, typedef
XA_MARK_0 (which is not ideal since this isn't a typedef). Options for
improvements would be to add 'macro' as a possible prefix (so eg. macro
XA_MARK_0), or go all out and try to cross-reference on every uppercase word
like suggested. We should strive for what is the most natural to write, as
long as the regex isn't too broad.
Since automarkup.py is opt-out rather than opt-in, I think we should be extra
careful not to make the regexes too broad, even if in this case it relies on a
C symbol being present.
One other idea I had was that we could limit to all uppercase words as
long as it has an _ on it, since I don't expect we would get false positives
with that. The downside is that it might be very confusing to people why their
MACRONAME isn't being automatically cross-referenced to...
Thanks,
Nícolas
[1] https://lore.kernel.org/linux-doc/20201007234024.GY20115@casper.infradead.org/
Nícolas F. R. A. Prado (2):
docs: automarkup.py: Add literal markup of known constants
XArray: Remove literal markup from known constants
Documentation/core-api/xarray.rst | 48 +++++++++++++++---------------
Documentation/sphinx/automarkup.py | 45 ++++++++++++++++++++++++++--
2 files changed, 67 insertions(+), 26 deletions(-)
--
2.32.0
next reply other threads:[~2021-06-09 1:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-09 1:43 Nícolas F. R. A. Prado [this message]
2021-06-09 1:43 ` [RFC PATCH 1/2] " Nícolas F. R. A. Prado
2021-06-09 8:11 ` Mauro Carvalho Chehab
2021-06-13 23:13 ` Jonathan Corbet
2021-06-14 7:27 ` Mauro Carvalho Chehab
2021-06-09 1:43 ` [RFC PATCH 2/2] XArray: Remove literal markup from " Nícolas F. R. A. Prado
2021-06-09 7:50 ` Mauro Carvalho Chehab
2021-06-09 7:45 ` [RFC PATCH 0/2] docs: automarkup.py: Add literal markup of " 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=20210609014308.234027-1-n@nfraprado.net \
--to=n@nfraprado.net \
--cc=andrealmeid@collabora.com \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab+huawei@kernel.org \
--cc=willy@infradead.org \
--cc=~lkcamp/patches@lists.sr.ht \
/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
all inboxes | Powered by JetHome®