From: Jeff King <peff@peff.net>
To: Thomas Rast <trast@inf.ethz.ch>
Cc: "Carlos Martín Nieto" <cmn@elego.de>, git@vger.kernel.org
Subject: Re: [PATCH] Documentation: use {asterisk} in rev-list-options.txt when needed
Date: Wed, 29 Feb 2012 16:38:09 -0500 [thread overview]
Message-ID: <20120229213809.GC628@sigill.intra.peff.net> (raw)
In-Reply-To: <87hayar25i.fsf@thomas.inf.ethz.ch>
On Wed, Feb 29, 2012 at 12:03:53AM +0100, Thomas Rast wrote:
> > Anyway, that is not a problem with your patch. :) I confirmed that the
> > bug happens in my version of the toolchain, and your fix works (I also
> > tried using `*`, but backtick does not suppress markup.
>
> Actually it would, if it weren't for our use of '-a no-inline-literal'.
> Which we are using because the "backticks do not interpret {stuff}"
> feature was introduced in a backwards-incompatible way in asciidoc
> 8.4.1, see 71c020c (Disable asciidoc 8.4.1+ semantics for `{plus}` and
> friends, 2009-07-25).
>
> Some googling tells me the distros are currently at
>
> openSuSE 8.4.5 (local)
> Debian (stable) 8.5.2 packages.debian.org
> Fedora 8.4.5 admin.fedoraproject.org/pkgdb/
> (but I can't discern whether it's actually in there...)
> Arch 8.6.6 www.archlinux.org/packages/
> Ubuntu 11.10 8.6.4 packages.ubuntu.com
>
> so perhaps the time has come to remove that switch?
Looks like asciidoc 8.4.1 was introduced almost exactly 3 years ago. So
yeah, I'd be OK with breaking compatibility if it means the sources
become more readable[1]. It would be nice if there were an option (like
"-a inline-literal") that older versions could set, but I don't think it
exists. However, people on old systems always have the option of
pulling the pre-rendered documentation, which is what I assume people on
ancient proprietary systems do (or they just go without manpages).
We should also consider dropping the ASCIIDOC7 define in the
Documentation Makefile, too (it would be broken by the switch to inline
literals, and it is also ancient at this point). I wonder if we can also
drop some of the older docbook compatibility options. Even Debian
stable[2] is on docbook 1.75, which is beyond the Makefile's table of
which version needs which options. The last version to need any options
was docbook 1.72, which is from 2007.
The first step, though, would be auditing the whole Documentation
directory for escaped text inside inline literals (i.e., `{asterisk}`
would have to go back to `*`). Which does not sound like a fun job.
-Peff
[1] The documentation for asciidoc claims that inline literals will not
expand anything except "special characters". From what I understand
of special characters, that does not mean stuff like "*", which
would still be literal, but rather that "<" would be expanded into
"<" when formatting to XML or HTML. So I think it would do what
we want.
[2] I usually use Debian stable as my gold standard of "old". But
actually, RHEL5 will continue to get critical and security fixes
until 2014, and is on an older toolchain. They are not likely
to be picking up the latest git to package, of course, but there
might still be devs on it who would install git from source. But I
think we can be a little more cavalier about backwards compatibility
in the doc toolchain because pre-rendered versions are available.
prev parent reply other threads:[~2012-02-29 21:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-28 15:35 [PATCH] Documentation: use {asterisk} in rev-list-options.txt when needed Carlos Martín Nieto
2012-02-28 19:38 ` Junio C Hamano
2012-02-28 19:45 ` Jeff King
2012-02-28 20:20 ` Carlos Martín Nieto
2012-02-28 21:18 ` Junio C Hamano
2012-02-28 23:03 ` Thomas Rast
2012-02-29 21:38 ` Jeff King [this message]
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=20120229213809.GC628@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=cmn@elego.de \
--cc=git@vger.kernel.org \
--cc=trast@inf.ethz.ch \
/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).