Re: [lmi] Empty paragraphs in HTML-MST

[Greg Chicares]

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

Not urgent, but extremely helpful. Capitalization: likewise.

> GC> And, if literals are allowed as the 'Object', they could be much longer
> GC> than the 'Verb':
> GC>   {{Paragraphize "This is a literal footnote that goes on and on and on...
> GC>   ...and on and on and on."}
> GC> in which case a 'Verb' written at the end would be hard to see.
> 
>  I didn't think about allowing string arguments, would this really be
> useful? Right now my syntax would be
> 
>       {{function-name arg-1 arg-2 ... arg-N}}
> 
> where function-name is just a sequence of any non-space characters and
> arguments are either numbers, i.e. sequences of digits, or field names, to
> be expanded before being passed to the function.
> 
>  If we do want to have string arguments, then we'd need to further impose
> the condition that field names can't contain double quotes (currently they
> can contain anything at all, including spaces and quotes) and amend the
> syntax above to accept quoted strings (with potentially escaped quotes
> inside) too.

By "field names", do you mean only the names within {{}} in the
following snippet?

  {{^SinglePremium}}
    Premiums are assumed to be paid on {{ErModeLCWithArticle}}
    basis and received at the beginning of the {{ContractName}} year.
  {{/SinglePremium}}

Or perhaps you mean only {{ErModeLCWithArticle}} and {{ContractName}}
therein. Either way, the answer is the same: all variable names that
can occur between {{ and }} match [A-Za-z0-9_] only, and I wouldn't
want to allow even '-' because it can be very handy to use those names
for C++ variables (hence, no "reserved" leading underscore either).
We'll never have a name like "this is never any variable's name", in
the sense of
  this is never any variable's name = 42
  printf(this is never any variable's name) // prints "42"

Or are you referring to the contents of those named strings? In that
case, they might very well contain any kind of quote characters
except guillemets:
  "This \"Policy\" is 'life insurance'"
However, we can simply declare that literals in MST constructs, like
  {{NameOfFunction "This is the literal part."}}
are forbidden to include any quotes, and a defined variable must be
used instead:
  char const* p = "This is a 'literal' part containing a quote symbol.";
  {{NameOfFunction p}} <!-- Here 'p' must be used. -->
so that this is a diagnosable error:
  {{NameOfFunction "This is the 'literal' part."}}

> GC> ...but I have no doubt that the option that uses helpers is much better,
> GC> and you seem to prefer it, too, so let's proceed with that option.
> 
>  I'm not sure if I can finish this in the next few days and if I don't, it
> would be delayed for a couple of weeks. OTOH if we can clearly define the
> desired syntax, I could ask Ilya to work on this sooner.

Let's approach it in this decreasing priority order:
  {{substitutions}}
  pilcrow for internal breaks
  suppression of empty paragraphs
  <strong>

Explanation of "{{substitutions}}":

Right now, we have lots of code like this:
  std::string const s0 = "This contract is life insurance.";
  std::string const s1 = "This policy is life insurance.";
  std::string const s2 = "This certificate is life insurance.";
and for each of 140 products we must select one:
  product0::product0()     {... item("SomeFootnote") = s2; ...}
  product1::product1()     {... item("SomeFootnote") = s0; ...}
  product139::product139() {... item("SomeFootnote") = s1; ...}
But every product already sets a 'ContractName', so we want only
  std::string const s0 = "This {{ContractName}} is life insurance.";
on a single line in a function that sets all defaults (instead
of 140 different product-specific lines). This is an enormously
important simplification. If we can do it right now, then we can
spend a week or two cleaning up decades of accumulated cruft.
The branch I shared a week or two ago does this, though in some
ugly and inefficient way. I can commit the non-HTML part of that
tonight, or you can propose a non-awful workalike in the next
couple of days, and then we can enter the augean stables, from
which we won't emerge very soon. That's all we need immediately.

I think the other three items in that prioritized list document
themselves, more or less; we can make good use of them as soon
as they become available, but if we have only {{substitutions}}
in '.policy' files, that's enough to keep us busy for a while.

>  In any case, please let me know if the syntax above (with and/or without
> string literals) looks reasonable to you.

Yes, it does.