Re: [PATCH v2 0/2] asciidoctor-extensions: provide `<refmiscinfo/>`
- From
brian m. carlson <sandals@crustytoothpaste.net>
- Date
- Sep 3, 2019, 23:16 UTC
- Message-ID
- <20190903231610.GI11334@genre.crustytoothpaste.net>
- In-Reply-To
- <cover.1567534373.git.martin.agren@gmail.com>
On 2019-09-03 at 18:51:19, Martin Ågren wrote:
Show 27 quoted lines
> Almost half a year ago, I wrote: > > To be clear. *This* patch has a sufficiently incorrect commit message > > that it really needs a makeover. You can expect a v2. > > Finally, here's that v2. I should probably refresh memories: The goal of > the main patch here is to make the headers and footers of our manpages > built by Asciidoctor look a lot more like those generated by AsciiDoc. > In particular, this gets rid of the ugly "[FIXME: source]". > > I spent a little bit of time trying to work on the XML as XML, and > quite a lot of time procrastinating on that. In the end, I decided that > the outcome of my attempts wouldn't get better and that there is some > value to the stupid approach from v1 of doing a simple search-and-replace > in the text. I've preserved my attempts in the commit message. > > When I posted v1, it turned into quite a thread [1] on AsciiDoc vs > Asciidoctor vs Asciidoctor 2.0 and differences in rendering. (I am on > Asciidoctor 1.5.5.) > > Among other things, the v1-thread discussed switching the rendering > toolchain entirely to avoid the detour over xmlto. Doing that would > render this patch obsolete. While I agree that such a switch is the > correct long-term goal and that we can be fairly aggressive about it, I > 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, this seems like a good approach. xmlto is a neat tool, but it's essentially unmaintained and is designed for DocBook 4. Avoiding it where possible seems like the right choice.
I looked at this series and it seems sane. I agree that adding a dependency on nokogiri isn't really desirable. It is an extremely common Ruby package, but it has native extensions, which causes problems for some people if their distro doesn't support it.
-- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204