From: Jonathan Nieder <jrnieder@gmail.com>
To: Jeff King <peff@peff.net>
Cc: Andi Kleen <andi@firstfloor.org>,
Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org, Chris Johnsen <chris_johnsen@pobox.com>
Subject: Re: groff .ft command use in asciidoc
Date: Fri, 19 Nov 2010 12:22:30 -0600 [thread overview]
Message-ID: <20101119182230.GA26187@burratino> (raw)
In-Reply-To: <20101119175424.GA13276@sigill.intra.peff.net>
Jeff King wrote:
> --- a/Documentation/Makefile
> +++ b/Documentation/Makefile
> @@ -63,35 +63,28 @@ endif
[...]
> -# -1.68.1, set ASCIIDOC_NO_ROFF? (based on changelog from 1.73.0)
> -# 1.69.0, no extra settings are needed?
> +# -1.68.1, no extra settings are needed?
> +# 1.69.0, set ASCIIDOC_ROFF?
> # 1.69.1-1.71.0, set DOCBOOK_SUPPRESS_SP?
> -# 1.71.1, no extra settings are needed?
> +# 1.71.1, set ASCIIDOC_ROFF?
I would like to see these question marks go away. I believe the
initial introduction of ASCIIDOC_NO_ROFF happened conservatively:
i.e., do not change anything unless this particular toolset
requires the change. Which is a shame, because it means it is not
obvious what ASCIIDOC_ROFF is working around.
*does some digging*
The story begins with v1.3.0-rc1~45^2 (Tweak asciidoc to work with
broken docbook-xsl, 2006-03-05). The [listingblock] style, used
for listings like:
--------------------
$ ls
foo
bar
baz
--------------------
is meant to be rendered with the <screen> tag, but apparently DocBook
XSL 1.68.1 does not and 1.70.1 does treat <screen> as a
verbatim environment as it should. See <http://bugs.debian.org/375503>.
The patch swapped in another verbatim environment, <literallayout>.
The result is a regression in another aspect from <screen>: namely,
<screen> uses monospace text. v1.5.2.5~6 (Force listingblocks to be
monospaced in manpages, 2007-07-18) worked around that by introducing
some raw nroff, since this codepath is only used for manpages anyway.
The rest is history. docbook-xsl 1.72 broke the traditional method
for passing raw roff through. It had a hole that let you do it some
other way. Later versions of docbook-xsl forbid passing through raw
roff escapes altogether.
Given all that, I suspect (but haven't checked) that the only knob we
would need to cover all historically supported versions of DocBook is
DOCBOOK_MESSES_UP_SCREEN_TAG = YesUnfortunately
to be set with docbook versions in the 1.68 series. Everyone else
can use <screen>, with the <literallayout> fixup to add some space
after it.
> However, I think it is worth it to avoid the hassle for the vast
> majority of people on modern systems.
Yes! Your patch takes care of that, so ack.
Thanks,
Jonathan
next prev parent reply other threads:[~2010-11-19 18:23 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-17 9:52 groff .ft command use in asciidoc Andi Kleen
2010-11-17 10:15 ` Jonathan Nieder
2010-11-17 11:52 ` Andi Kleen
2010-11-17 14:38 ` Jeff King
2010-11-17 15:48 ` Andi Kleen
2010-11-19 17:54 ` Jeff King
2010-11-19 18:22 ` Jonathan Nieder [this message]
2010-11-19 18:37 ` Jeff King
2010-11-19 20:34 ` Drew Northup
2010-11-19 20:40 ` Jeff King
2010-11-19 20:53 ` Drew Northup
2010-11-19 22:58 ` Junio C Hamano
2010-11-20 1:48 ` Todd Zullinger
2010-11-18 17:47 ` Alejandro Riveira Fernández
2010-11-18 21:11 ` Drew Northup
2010-11-18 23:15 ` Alejandro Riveira Fernández
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=20101119182230.GA26187@burratino \
--to=jrnieder@gmail.com \
--cc=andi@firstfloor.org \
--cc=chris_johnsen@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
/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).