lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Branching to replace XSL-FO


From: Vadim Zeitlin
Subject: Re: [lmi] Branching to replace XSL-FO
Date: Mon, 9 Oct 2017 18:17:44 +0200

On Mon, 9 Oct 2017 15:59:31 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2017-10-06 21:51, Vadim Zeitlin wrote:
GC> > On Fri, 6 Oct 2017 20:53:37 +0000 Greg Chicares <address@hidden> wrote:
GC> [...]
GC> > GC> $ git checkout vz-no-xslfo
GC> > GC> $ make srcdir=/opt/lmi/src/lmi -f /opt/lmi/src/lmi/GNUmakefile 
check_concinnity 2>&1 |less -S
GC> > GC> 
GC> > GC> If you haven't addressed the output yourself yet,
GC> > 
GC> >  I planned to do it as part of my final review but I indeed haven't done
GC> > this yet. I can/will do it soon, but probably not before Monday.
GC> 
GC> Okay, then let me just offer a few comments.
GC> 
GC> I want to maintain the 31-character limit on file names.

 Sooner or later this will really need to change, but I guess it won't
happen today.

GC> Do we really need to use nine of those characters for '.mustache',

 This is the de facto standard extension for these files but we could also
use .mst if it's really important. This short extension is not nearly as
widespread though, e.g. it's not even recognized by vim-mustache-handlebars
plugin (while .hbs is indeed recognized as a synonym for .handlebars).

GC> Mustache files should all contain a boilerplate copyright notice.

 Oops, yes, I didn't think about it, but will do it now (especially as the
parser does support comments in Mustache templates now, unlike originally).

GC> 'compliance_tracking_number.mustache': Let's replace the base name of
GC> this file with 'imprimatur'.

 Sure.

GC> 'reg_d_individual_cur_irr.mustache' vs. 
'reg_d_individual_guar_irr.mustache':
GC> Let's use 'guar_' as above and 'curr_' with two r's, to follow the
GC> convention used elsewhere in lmi.

 I guess I also need to change all column_cur_xxx to column_curr_xxx in the
code too, don't I?

GC> Will you rebase the final result on current lmi master?

 If you'd like, this is not a problem at all. The only problem is that this
will invalidate your local vz-no-xslfo and you will need to reset it to the
latest version of my branch (which will, in fact, be a new branch, as it
won't contain exactly the same commits -- but with the same name) to avoid
confusion. The simplest way to do it would be to just delete and recreate
this branch, i.e.

        $ git fetch vz-remote
        ... git will tell you something about "forced update" ...
        $ git branch -D vz-no-xslfo"
        $ git branch vz-no-xslfo vz-remote/direct-pdf-gen-master

 I should push my commits later tonight and if you don't object to this
rebasing and branch recreation by then, I'll do it.

 Thanks for the tips above,
VZ


reply via email to

[Prev in Thread] Current Thread [Next in Thread]