list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <>
To: "Martin Ågren" <>
Cc: "brian m. carlson" <>,
	Bagas Sanjaya <>,
	Git Users <>
Subject: Re: [RFC suggestion] Generate manpage directly with Asciidoctor
Date: Mon, 10 May 2021 18:24:16 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Sun, May 09, 2021 at 10:20:37AM +0200, Martin Ågren wrote:

> > But I wouldn't be at all sad to just standardize on asciidoctor. I think
> > we're at parity in terms of the output (thanks to lots of work from you
> > and Martin over the past couple of years), and I've generally found it
> > nicer to work with.
> I tend to think asciidoctor even renders our manpages *better* than
> asciidoc does. Not by a huge margin, but a few things here and there.

Yeah, I'd agree with that.

> Some time around the Python 2 EOL, I was about to propose flipping the
> default, but then I went to look up the asciidoc EOL schedule, and like
> you, I noticed that it was a lot more alive and kicking than I thought
> it was. So it's not so much "we should flip to avoid a bitrotting
> dependency" as it is "asciidoctor is arguably nicer" or "it's the way
> forward".

I'm OK with those arguments, too. :)

> > The only downside is that it may be available in fewer places (though
> > I'd think that python vs ruby is not so different). IMHO it's OK to be
> > aggressive about the doc toolchain requirements, because the fallback is
> > always grabbing the preformatted roff or HTML pages that were generated
> > on a different system.
> In general, I agree. I do think it's important that "most people
> contributing to Git", whatever that means, can build the documentation
> to check the part they're adding/modifying and not find it broken left
> and right. They would then (quite rightly) not even bother building it.

Agreed. But I think that is mostly the case (asciidoctor seems no harder
to acquire on most modern systems than asciidoc; there are system
packages in most cases, and decent binary-package systems for both ruby
and python if you really need it).

It does create a situation where people like Randall on NonStop might
need to do part of their dev work on another, more mainstream platform.
But I suspect that is already the case.

> When we looked at xmlto-less rendering around two years ago [1], we
> found various asciidoctor bugs up to and around version 2.0. We would
> likely need to require some >=2.0.x. The exact requirements will
> probably only become clear when someone really does the work.

That does make things a little less convenient; Debian stable, for
instance, still has 1.5.8. It's not too hard to install an updated gem,
but not quite as nice as using the system package (it also makes things
weird for building the stable Debian package itself, which would want to
rely only on other packages; but of course any proposed change to the
doc toolchain would be for new versions, and would not get backported
there anyway).

> I think what I'm arguing for is
>   1) switch the default to asciidoctor,
>   2) enable optionally using it without xmlto,
>   3) figure out what broke and fix it, and document which is the minimum
>      asciidoctor version we're going to bother with for (2),
>   4) lather, rinse, repeat (3),
>   5) switch the default to not using xmlto,
>   6) drop the xmlto way of generating the manpages(?).

I'm unclear when support for python asciidoc goes away here. Is it part
of step 6 (because it does not have another way of generating them)? Or
does it live on forever as a non-default legacy system? I'd prefer not,
but as long as we are clear about the primary target and leave it up to
people interested in the legacy to do the compat fixes, that might be


  parent reply	other threads:[~2021-05-10 22:24 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-07  6:06 Bagas Sanjaya
2021-05-07 12:02 ` Randall S. Becker
2021-05-07 22:55   ` Felipe Contreras
2021-05-07 22:57   ` brian m. carlson
2021-05-08  1:42     ` Randall S. Becker
2021-05-07 12:27 ` Đoàn Trần Công Danh
2021-05-07 12:47   ` Bagas Sanjaya
2021-05-07 23:03   ` Felipe Contreras
2021-05-08  4:27     ` Bagas Sanjaya
2021-05-07 20:25 ` brian m. carlson
2021-05-07 22:19   ` Jeff King
2021-05-08  4:22     ` Bagas Sanjaya
2021-05-09  8:20     ` Martin Ågren
2021-05-09 18:46       ` Felipe Contreras
2021-05-10 18:43         ` Martin Ågren
2021-05-10 22:24       ` Jeff King [this message]
2021-05-11  4:27         ` Felipe Contreras
2021-05-11  6:13           ` Jeff King
2021-05-11  8:03             ` Felipe Contreras
2021-05-11 12:44               ` Ævar Arnfjörð Bjarmason
2021-05-11 19:00                 ` Felipe Contreras
2021-05-11 19:09                   ` Jeff King
2021-05-11 20:22                     ` Felipe Contreras
2021-05-11 23:14           ` brian m. carlson
2021-05-12  1:44             ` Felipe Contreras
2021-05-11 18:45         ` Martin Ågren
2021-05-11 19:07           ` Jeff King
2021-05-11 19:11             ` Martin Ågren
2021-05-11 20:14             ` Felipe Contreras
2021-05-11  9:04       ` Jean-Noël Avila
2021-05-11 18:54         ` Martin Ågren
2021-05-07 23:35   ` Felipe Contreras
2021-05-07 23:57     ` brian m. carlson
2021-05-08  3:10       ` Jeff King
2021-05-08  3:23         ` Jeff King
2021-05-09  0:22         ` brian m. carlson
2021-05-09  8:29     ` Martin Ågren
2021-05-07 22:48 ` Felipe Contreras

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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \
    --subject='Re: [RFC suggestion] Generate manpage directly with Asciidoctor' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

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 read-only IMAP folder(s) and NNTP newsgroup(s).