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