public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Corbet <corbet@lwn.net>
To: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kernel-doc: Let backtick and backslash escape percent sign
Date: Mon, 8 Apr 2019 16:03:14 -0600	[thread overview]
Message-ID: <20190408160314.05bc5ecb@lwn.net> (raw)
In-Reply-To: <20190405211820.17617-1-sean.j.christopherson@intel.com>

On Fri,  5 Apr 2019 14:18:20 -0700
Sean Christopherson <sean.j.christopherson@intel.com> wrote:

> There are a handful of instances where kernel doc comments want an
> actual '%' in the final output, e.g. vsnprintf() wants to display "%n"
> and "%p" to document format specifiers, and assembly functions that use
> a custom call ABI may want to document their register usage, e.g. %eax.
> 
> Because kernel-doc unconditionally interprets '%' followed by a word
> character as a constant definition, i.e. %CONST, it's impossible to get
> an actual '%\w' when kernel-doc is used to translate comments into rst
> format.  Treat backtick and backlash as escaping '%', the former to
> handle '%' in a ``LITERAL``, and the latter to allow '%' when using
> standard formatting.

So I'm sympathetic toward the goal; we want this stuff to format properly.
But I'm less convinced about this specific solution.  Starting with the
details: 

> -my $type_constant2 = '\%([-_\w]+)';
> +my $type_constant2 = '(^|[^\`\\\])\%([-_\w]+)';

This only escapes the % if it occurs *immediately* after the backtick, so
something like ``foo %p`` will still get processed incorrectly.  Somebody
will surely run into that at some point and waste a bunch of time trying to
figure out what's going on.

Also, believe it or not, I don't think you have enough backslashes; that
inner expression, I believe, should be:

	[^\`\\\\]

Gosh Perl regexes are fun...  This highlights the danger of adding
functionality that isn't exercised anywhere; I don't think it works here.

Now to more general considerations.  Willy's suggestion of using %% instead
makes some sense, though it may lead to pushback from the "no extra markup
ever" contingent.  It should be more straightforward to implement
correctly.

I have to wonder if the % thing is actually buying us much, honestly.  It's
another form of markup that kind of duplicates the Sphinx notation, and
we've kind of agreed that most of the time, we don't want to clutter our
text with ``explicit markup`` like that.  I'm curious what people think:
might the best solution be to just make %const do nothing special, with the
idea of phasing it out?

Thanks,

jon

  parent reply	other threads:[~2019-04-08 22:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-05 21:18 [PATCH] kernel-doc: Let backtick and backslash escape percent sign Sean Christopherson
2019-04-05 23:10 ` Matthew Wilcox
2019-04-08  9:58   ` Jani Nikula
2019-04-08 22:03 ` Jonathan Corbet [this message]
2019-04-09 14:39   ` Sean Christopherson

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=20190408160314.05bc5ecb@lwn.net \
    --to=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sean.j.christopherson@intel.com \
    /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