Re: [PATCH v2 0/2] asciidoctor-extensions: provide `<refmiscinfo/>`

From: Jeff King <peff@peff.net>
Date: Sep 7, 2019, 06:45 UTC
Message-ID: <20190907064508.GC28860@sigill.intra.peff.net>
In-Reply-To: <CAN0heSpbRvNG9okz5pqkHqDMB2BM5T+FzAbaK3sVwzGC6fjpPA@mail.gmail.com>

On Thu, Sep 05, 2019 at 09:35:10PM +0200, Martin Ågren wrote:

Show 14 quoted lines

> > > do also think it makes sense to first make the "softer" switch to
> > > Asciidoctor-by-default and get that particular hurdle behind us. Then,
> > > once we're ok with dropping AsciiDoc entirely, we can do the switch to
> > > an Asciidoctor-only toolchain.
> >
> > Yeah, I do still like that as an endgame, but I like what you have here
> > as an intermediate step in the right direction.
> 
> Hmm, so this sounds like once I am happy with replacing AsciiDoc with
> Asciidoctor 1(.5.5), I should rather not propose a series "let's default
> to Asciidoctor!!!" but instead a slightly more careful "go with
> Asciidoctor, but document that we work badly with v2 and that the 2nd
> choice after Asciidoctor 1 should be AsciiDoc". Or do you see it
> differently? (I wonder which Asciidoctor-version Junio would be on..)

Yeah, that seems reasonable.

TBH, if making things in the middle step work turns out to be too hard, I'm not entirely opposed to a hard switch.

The "does not work with 2.0" thing has to be a temporary step, though, I think, since using the older versions will get harder and harder as time goes on. I think it's OK to take such a temporary step as long as we understand where it leads (and presumably its to directly generating the roff with asciidoctor). The middle step of having asciidoctor+xmlto helps us understand and isolate which changes are responsible for which parts of the output.

-Peff