mbox series

[0/4] doc-diff: support diffing from/to AsciiDoc(tor)

Message ID cover.1552838239.git.martin.agren@gmail.com (mailing list archive)
Headers show
Series doc-diff: support diffing from/to AsciiDoc(tor) | expand

Message

Martin Ågren March 17, 2019, 6:35 p.m. UTC
I've taught `doc-diff` a few new knobs to support usage like

  $ ./doc-diff --from-asciidoc --to-asciidoctor HEAD HEAD

and I don't think I've messed it up too badly in the process. I'm open
to the idea that this might not be interesting to a whole lot of people.
But I have made some progress on fixing up Asciidoctor *and* AsciiDoc
issues using this, and once the output of the above command is empty --
which might not be too far off -- it could be interesting to try and
keep it that way using a bit of automation around these switches.

While using/testing these patches, I've made some progress on the
rendering of the headers and footers in Asciidoctor [1], so the
`--cut-header-footer` switch that I'm adding in the final patch might
hopefully not be necessary for too long. But we'd still need a
`--cut-footer` switch -- at least I would, on my system [2]. If this
series is considered generally sane, I'd be happy to rework the final
patch to `--cut-header` if that's preferred.

Patch 1 has a minor purely-textual merge conflict with
ma/asciidoctor-fixes.

[1] https://public-inbox.org/git/20190317144747.2418514-1-martin.agren@gmail.com/

[2] After [1], the date in the footer is still formatted differently
    here. It might be a locale thing, and I tend to shy away from even
    trying to understand those. :-/

Martin Ågren (4):
  Doc: auto-detect changed build flags
  doc-diff: let `render_tree()` take an explicit directory name
  doc-diff: support diffing from/to AsciiDoc(tor)
  doc-diff: add `--cut-header-footer`

 Documentation/.gitignore |  1 +
 Documentation/Makefile   | 23 ++++++++---
 Documentation/doc-diff   | 86 +++++++++++++++++++++++++++++++++-------
 3 files changed, 90 insertions(+), 20 deletions(-)

Comments

Junio C Hamano March 18, 2019, 6:53 a.m. UTC | #1
Martin Ågren <martin.agren@gmail.com> writes:

> I've taught `doc-diff` a few new knobs to support usage like
>
>   $ ./doc-diff --from-asciidoc --to-asciidoctor HEAD HEAD

Nice.

> But I have made some progress on fixing up Asciidoctor *and* AsciiDoc
> issues using this, and once the output of the above command is empty --
> which might not be too far off -- it could be interesting to try and
> keep it that way using a bit of automation around these switches.

That would be exciting.
Jeff King March 19, 2019, 3:14 a.m. UTC | #2
On Sun, Mar 17, 2019 at 07:35:59PM +0100, Martin Ågren wrote:

> I've taught `doc-diff` a few new knobs to support usage like
> 
>   $ ./doc-diff --from-asciidoc --to-asciidoctor HEAD HEAD
> 
> and I don't think I've messed it up too badly in the process. I'm open
> to the idea that this might not be interesting to a whole lot of people.
> But I have made some progress on fixing up Asciidoctor *and* AsciiDoc
> issues using this, and once the output of the above command is empty --
> which might not be too far off -- it could be interesting to try and
> keep it that way using a bit of automation around these switches.

Very nice. All the patches look good to me.

The "from" and "to" variants of the options are a little awkward; these
are really properties of the actual endpoints. It would be nice if we
had some fixed syntax that defined the whole state, like:

  ./doc-diff asciidoc:HEAD asciidoctor:HEAD^

or something. But I think as you introduce new options (like the
header/footer cutting) that syntax would get pretty unwieldy. So
probably the separate options is the best way forward.

> While using/testing these patches, I've made some progress on the
> rendering of the headers and footers in Asciidoctor [1], so the
> `--cut-header-footer` switch that I'm adding in the final patch might
> hopefully not be necessary for too long. But we'd still need a
> `--cut-footer` switch -- at least I would, on my system [2]. If this
> series is considered generally sane, I'd be happy to rework the final
> patch to `--cut-header` if that's preferred.

I think what's here is fine for now. This is our own internal script, so
if options become useless later on, we can always cull them.

> [2] After [1], the date in the footer is still formatted differently
>     here. It might be a locale thing, and I tend to shy away from even
>     trying to understand those. :-/

Yeah, mine too.

-Peff
Martin Ågren March 20, 2019, 8:11 p.m. UTC | #3
On Tue, 19 Mar 2019 at 04:14, Jeff King <peff@peff.net> wrote:
>
> On Sun, Mar 17, 2019 at 07:35:59PM +0100, Martin Ågren wrote:
>
> > I've taught `doc-diff` a few new knobs to support usage like
> >
> >   $ ./doc-diff --from-asciidoc --to-asciidoctor HEAD HEAD
>
> Very nice. All the patches look good to me.

Thank you.

> The "from" and "to" variants of the options are a little awkward; these
> are really properties of the actual endpoints. It would be nice if we
> had some fixed syntax that defined the whole state, like:
>
>   ./doc-diff asciidoc:HEAD asciidoctor:HEAD^

Right. I wasn't terribly impressed by the look of the "--from-foo
--to-bar" syntax, but at least I felt like I couldn't possibly mess up
the handling of it. As opposed to parsing substrings and whatnot.

> or something. But I think as you introduce new options (like the
> header/footer cutting) that syntax would get pretty unwieldy. So
> probably the separate options is the best way forward.

And this too. A few more orthogonal parameters on top and it would get
hairy pretty quickly. (At least I got the feeling it would.)

I think that at least --cut-header-footer is pretty useless to apply to
only one of the sides (you'd be asking for 4-6 lines to definitely
differ, for each and every rendered file), so this particular parameter
would perhaps not be useful to bake into your alternative syntax.

> > I'd be happy to rework the final
> > patch to `--cut-header` if that's preferred.
>
> I think what's here is fine for now. This is our own internal script, so
> if options become useless later on, we can always cull them.

That's true.

> > [2] After [1], the date in the footer is still formatted differently
> >     here. It might be a locale thing, and I tend to shy away from even
> >     trying to understand those. :-/
>
> Yeah, mine too.

Thanks for a data point. So at least it's not just me.


Martin