Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Jonathan Corbet <corbet@lwn.net>
To:     Matthew Wilcox <willy@infradead.org>
Cc:     Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
        Linux Doc Mailing List <linux-doc@vger.kernel.org>,
        Rob Herring <robh@kernel.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kernel-doc: better handle '::' sequences
In-Reply-To: <20210325191435.GZ1719932@casper.infradead.org>
References: <20210325184615.08526aed@coco.lan>
 <2cf44cf1fa42588632735d4fbc8e84304bdc235f.1616696051.git.mchehab+huawei@kernel.org>
 <87tuozyslu.fsf@meer.lwn.net>
 <20210325191435.GZ1719932@casper.infradead.org>
Date:   Thu, 25 Mar 2021 15:04:00 -0600
Message-ID: <87a6qrx7wf.fsf@meer.lwn.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Matthew Wilcox <willy@infradead.org> writes:

> On Thu, Mar 25, 2021 at 12:51:25PM -0600, Jonathan Corbet wrote:
>> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> writes:
>>=20
>> > Right now, if one of the following headers end with a '::', the
>> > kernel-doc script will do the wrong thing:
>> >
>> > 	description|context|returns?|notes?|examples?
>> >
>> > The real issue is with examples, as people could try to write
>> > something like:
>> >
>> > 	example::
>> >
>> > 		/* Some C code */
>> >
>> > and this won't be properly evaluated. So, improve the regex
>> > to not catch '\w+::' regex for the above identifiers.
>> >
>> > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
>> > ---
>> >  scripts/kernel-doc | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>>=20
>> Ah....wouldn't it be nice if kerneldoc comments had just been RST from
>> the beginning?  I don't think we're fixing that at this point, though,
>> so this makes sense; applied.
>
> Well ...
>
> If somebody wants to write a new tool (*) that extracts documentation
> written in a different format, I think that could be done.  Because the
> hard part of writing documentation is getting the person who knows the
> code to get everything that's in their brain into words, not really
> the formatting.
>
> If somebody did want to write such a tool, I think we'd also want a
> tool that turns the existing kernel-doc into the new format, because
> maintaining two function-doc formats would be awful.

Yeah, the thing is that, as long as we're documenting code with
something other than RST, we *do* have two formats, and they interact
with each other in surprising and unwelcome ways.

I don't really see a fix, though.  Even if we come up with the Perfect
New Format=E2=84=A2, I don't want to be the one trying to push through the
patches changing tens of thousands of kerneldoc comments over...

jon