[stringtemplate-interest] summarizing white space and indentation

[Jonathan Buhacoff]

There's a template toolkit for Perl which has been around for a while  
and it uses the following convention to allow authors to control  
whitespace around ANY template directive, not just conditionals:

a single character (in the perl toolkit it's a hyphen) immediately  
after the start tag indicates that all leading whitespace should be  
ignored,  and the same character immediately before the end tag  
indicates that all trailing whitespace should be ignored.

When that whitespace control character is not used, all whitespace is  
retained.

I think that for conditionals and any other directive that wraps some  
other text, if the directive appears on a line by itself (ignoring  
whitespace), it makes sense for the entire line to be ignored.

Hypothetical ST examples using a hyphen as whitespace control  
character & the ignore-entire-line rule:

"begin\n   <if>\n   foo\n   <endif>\nend"
yields "begin\n   foo\nend" if true or "begin\nend" if false

"begin\n   <if>\n\n   foo\n\n   <endif>\nend"
yiedds "begin\n\n   foo\n\nend" if true (showing if you want foo to be  
surrounded by blank lines, it's trivial) or "begin\nend" if false

"begin\n   <-if>   foo<\n>    <-endif->\nend"
yields "begin\n   foo\nend" if true or "begin\nend" if false

"   <\n>\n"
yields "   \n\n"   since <\n> doesn't wrap anything so whitespace  
around it is retained

"   <-\n>\n"
yields "\n\n"    leading whitespace ignored with the whitespace  
control character

"   <-\n->\n"
yields "\n"    leading and trailing whitespace ignored with the  
whitespace control character


Notice that ignoring leading whitespace only affects that line -- the  
previous line & the newline at the its end are not affected.  Also  
notice that ignoring trailing whitespace does affect up to one  
newline.  But that's up for discussion, I think.

If there are syntax or aesthetic issues with using hyphen, I think   
any other convenient character, such as the colon already proposed,  
would be just fine.




--
Jonathan Buhacoff
jonathan at buhacoff.net
--



On Nov 7, 2009, at 9:58 PM, Zenaan Harkness wrote:

> On Sat, Nov 07, 2009 at 02:12:22PM -0800, Terence Parr wrote:
>> Ok, I have a proposed mechanism for whitespace and indentation now
>> which I can summarize.
>>
>> Whitespace is left alone except that the first whitespace character  
>> of
>> multi-line templates is ignored. So <<...>> and {...} templates but
>> not "..." templates. So, for example,
>
> What about:
>
> t() ::= << foo
>   bar
>   blah
>>>
>
> ??
>
> In this case, the template probably wants to emit a single space
> character at the start. How would a multi-line template be written to
> emit a single space character?
>
>
>> t() ::= <<
>> foo
>>>>
>>
>> ignores the first \n and yields a template with four characters: "foo
>> \n". similarly,
>>
>> { x | foo}
>>
>> yields "foo" as does
>>
>> { x |
>> foo}
>>
>> Indentation for IF statements is now ignored unless the entire IF is
>> on a line by itself. So
>>
>> begin
>>   <if(x)>
>>   foo
>>   <endif>
>> end
>>
>> gives
>>
>> begin
>>   foo
>> end
>>
>> whereas now in v3 you'd get a double indent: one for the IF M1 for  
>> the
>> indent in front of foo. Currently we have to keep the IF up against
>> the left edge.
>
> Here we are already breaking backward compatibility.
>
> I'd prefer strict default templates (no messing with ANY whitespace!),
> and syntax pre- or in-fix operator to get "nice pretty layout"
> behaviour.
>
> Q.1:
> Can we say that the advantages of strict, deterministic, non- 
> whitespace-
> consuming, low-cognitive-overhad templates take a back seat to "the
> prettiest template layout we can achieve"?
>
> Q.2:
> Ter, since your the primary implementer, can you please comment on the
> possibility of an in-fix or pre-fix template operator syntax for  
> "please
> remove some or all of {first, leading, last} whitespace in this
> template"?
>
> best
> zen
>
> -- 
> Free Australia: www.UPMART.org
> Please respect the confidentiality of this email as sensibly  
> warranted.
> _______________________________________________
> stringtemplate-interest mailing list
> stringtemplate-interest at antlr.org
> http://www.antlr.org/mailman/listinfo/stringtemplate-interest