Re: [lmi] Empty paragraphs in HTML-MST

[Vadim Zeitlin]

On Sat, 27 Jul 2019 00:41:53 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2019-07-26 22:47, Vadim Zeitlin wrote:
GC> > On Fri, 26 Jul 2019 22:18:55 +0000 Greg Chicares <address@hidden> wrote:
GC> > 
GC> > GC> On 2019-07-25 22:22, Vadim Zeitlin wrote:
GC> > GC> > On Thu, 25 Jul 2019 14:52:33 +0000 Greg Chicares <address@hidden> 
wrote:
GC> > GC> > 
GC> > GC> > GC> Motivation: MST files often contain blocks like this example:
GC> > GC> > GC>   <p>{{SampleText}}</p>
GC> > GC> > GC> which does the right thing if 'SampleText' is nonempty. However,
GC> > GC> > GC> for certain products, 'SampleText' is deliberately empty, in
GC> > GC> > GC> which case the example above expands to '<p></p>', printing an
GC> > GC> > GC> empty paragraph that consumes vertical space [0]. We'd like to
GC> > GC> > GC> suppress that effect.
GC> > GC> [...]
GC> > GC> >  I see 2 ways to do it, globally:
GC> > GC> > 
GC> > GC> > 1. Avoid generating <p></p> in the HTML in the first place.
GC> > GC> > 2. Keep generating <p></p> but render it as nothing.
GC> > [...]
GC> > GC> Okay, (1) is costlier, but it seems to be well worth the cost. Once we
GC> > GC> add MST helpers, we'll probably wish we had supported them sooner.
GC> > 
GC> >  Perhaps, especially if we support multiple arguments in them, which would
GC> > make it possible to have {{Abbrev Whatever 50}} rather than having to do
GC> > {{Abbrev50 Whatever}} (where changing "Abbrev50" to "Abbrev60" would
GC> > require changing C++ code).
GC> 
GC> Not urgent, but extremely helpful. Capitalization: likewise.

 Capitalization is trivial because it doesn't require any extra arguments.
Abbreviation is more interesting because it does require 2 arguments, and
not just one.

GC> By "field names", do you mean only the names within {{}} in the
GC> following snippet?
[...]
GC> Or perhaps you mean only {{ErModeLCWithArticle}} and {{ContractName}}
GC> therein.

 Yes.

GC> Either way, the answer is the same: all variable names that
GC> can occur between {{ and }} match [A-Za-z0-9_] only, and I wouldn't
GC> want to allow even '-' because it can be very handy to use those names
GC> for C++ variables (hence, no "reserved" leading underscore either).

 OK, we'll do this. I haven't done it so far because there didn't seem any
reason to impose some arbitrary constraints on their names, so it could be
any string non-containing "}}" (including even an empty string, which, I
guess, will be disallowed as well now).

GC> Let's approach it in this decreasing priority order:
GC>   {{substitutions}}
[...]
GC> This is an enormously
GC> important simplification. If we can do it right now, then we can
GC> spend a week or two cleaning up decades of accumulated cruft.
GC> The branch I shared a week or two ago does this, though in some
GC> ugly and inefficient way. I can commit the non-HTML part of that
GC> tonight, or you can propose a non-awful workalike in the next
GC> couple of days, and then we can enter the augean stables, from
GC> which we won't emerge very soon. That's all we need immediately.

 My best proposal remains to use partials to avoid writing nested
interpolate_string() calls. Without them, these calls seem unavoidable,
i.e. I basically can't see any way to improve your version. I am still not
sure why are you opposed to my proposal so much, is it really just because
of the overhead of the extra "<policy:"? If so, would it help if we used
something like "<<" instead, e.g. "{{<<SomeFootnote}}"? Or we could
shorten it even further, to "{{=SomeFootnote}}", maybe.


 Well, there is one other possibility, so let me mention it even it doesn't
seem right to me neither: we could make all expansions recursive by
default, i.e. {{Foo}} would take the value of "Foo" and then expand it,
replacing any {{Bar}}s in it recursively.

 Brining this up does make me wonder if you don't actually want this:
without a special syntax (i.e. using partials), it will be impossible to
perform recursive expansion manually. I.e. you can expand "ContractName" in

        "This {{ContractName}} is life insurance"

but if ContractName itself is defined as

        "{{ContractClass}} {{ContractSubClass}}"

then the results may be not what you'd want.

 If such recursion expansion is indeed (at least potentially) desirable,
and it seems to me it is, my partials proposal becomes even more appealing.
And if you still don't accept it, then making expansion recursive by
default would seem to be the only solution.


 I've stumbled upon this point totally accidentally, but I think it's a
pretty important one and would appreciate if you could let me know about
how do you think it should be handled (and, just one last nag, if you
really don't want to use partials instead of recursive function calls in
the PDF generation source).

 Thanks in advance,
VZ

pgpP5vfKhTWI4.pgp
Description: PGP signature