linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Corbet <corbet@lwn.net>
To: Danilo Cesar Lemes de Paula <danilo.cesar@collabora.co.uk>
Cc: Randy Dunlap <rdunlap@infradead.org>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Stephan Mueller <smueller@chronox.de>,
	Michal Marek <mmarek@suse.cz>,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 1/6] scripts/kernel-doc: Replacing highlights hash by an array
Date: Sun, 13 Sep 2015 14:36:47 -0600	[thread overview]
Message-ID: <20150913143647.1c7a9b05@lwn.net> (raw)
In-Reply-To: <1441656124-8997-2-git-send-email-danilo.cesar@collabora.co.uk>

On Mon,  7 Sep 2015 17:01:59 -0300
Danilo Cesar Lemes de Paula <danilo.cesar@collabora.co.uk> wrote:

> The "highlight" code is very sensible to the order of the hash keys,
> but the order of the keys cannot be predicted. It generates
> faulty DocBook entries like:
> 	- @<function>device_for_each_child</function>
> 
> Sorting the result is not enough some times (as it's deterministic but
> we can't control it).
> We should use an array for that job, so we can guarantee that the order
> of the regex execution on dohighlight is correct.

OK, I've spent a bunch of time with this, comparing the results before
and after.  The output you mention is clearly wrong, but there might be
room to differ over what the root cause is.

That output is caused by @device_for_each_child() in the comments.  This
happens for a few other functions as well, and I think it's wrong.  @ is
used to indicate parameters (or structure fields); I'm not sure why
people are using it for functions that are *not* one of the above.
Formatting the function names as a parameter doesn't seem right either.

There is the occasional case where the parameter *is* a function and the
text uses the () notation (threadfn(), for example).  Having the
"parameter" style win out over the "function" style in such cases is OK,
I guess, but it would be good to format the parentheses along with the
name.  The function patterns there now drop the parentheses entirely,
which seems a bit strange to me.

I guess I'll apply the patch; determinism is good, and it doesn't make
anything screwy that wasn't already that way.  But I think we should fix
the misapplied @s and sort out function formatting in general.  One of
these days...

Thanks,

jon

  reply	other threads:[~2015-09-13 20:36 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-07 20:01 [PATCH 0/6] scripts/kernel-doc: Kernel-doc improvements Danilo Cesar Lemes de Paula
2015-09-07 20:01 ` [PATCH 1/6] scripts/kernel-doc: Replacing highlights hash by an array Danilo Cesar Lemes de Paula
2015-09-13 20:36   ` Jonathan Corbet [this message]
2015-09-13 21:17     ` Lukas Wunner
2015-09-07 20:02 ` [PATCH 2/6] scripts/kernel-doc: Adding infrastructure for markdown support Danilo Cesar Lemes de Paula
2015-10-01  8:41   ` Jani Nikula
2015-09-07 20:02 ` [PATCH 3/6] drm/doc: Convert to markdown Danilo Cesar Lemes de Paula
2015-09-07 20:02 ` [PATCH 4/6] drm/doc: Fixing xml documentation warning Danilo Cesar Lemes de Paula
2015-09-07 20:02 ` [PATCH 5/6] scripts/kernel-doc: Improve Markdown results Danilo Cesar Lemes de Paula
2015-09-07 20:02 ` [PATCH 6/6] scripts/kernel-doc: Processing -nofunc for functions only Danilo Cesar Lemes de Paula
2015-09-12 21:24 ` [PATCH 0/6] scripts/kernel-doc: Kernel-doc improvements Jonathan Corbet
2015-09-13 10:36   ` Daniel Vetter
2015-09-13 19:13     ` Jonathan Corbet
2015-09-13 20:58       ` Daniel Vetter
2015-09-14 12:11         ` Danilo Cesar Lemes de Paula

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=20150913143647.1c7a9b05@lwn.net \
    --to=corbet@lwn.net \
    --cc=daniel.vetter@ffwll.ch \
    --cc=danilo.cesar@collabora.co.uk \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mmarek@suse.cz \
    --cc=rdunlap@infradead.org \
    --cc=smueller@chronox.de \
    /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).