lmi
[Top][All Lists]
Advanced

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

Re: [lmi] Empty paragraphs in HTML-MST


From: Vadim Zeitlin
Subject: Re: [lmi] Empty paragraphs in HTML-MST
Date: Sat, 27 Jul 2019 00:47:51 +0200

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).

 The problem is, supporting multiple arguments requires some thought, as we
can't blithely assume that whichever follows the function name should be
expanded and passed to it.

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.

 What do you think?

GC> I think (1) and (2) are reversed in the next paragraph:

 Oops, yes, indeed, sorry for the (luckily failed) attempt to confuse you.

GC> >  I believe that (2) would make more sense, especially if we want to use
GC> > functions in other cases, e.g. for abbreviating the value to some number 
of
GC> > characters. But if you need something immediately right now, (1) might be
GC> > faster to put in place.
GC> 
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.

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

 Thanks in advance,
VZ

Attachment: pgpVAhVIvYCd2.pgp
Description: PGP signature


reply via email to

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