[stringtemplate-interest] [ST4 Beta4] Inconsistent handling of starting/trailing newline in embedded region

[Udo Borkowski]

A minor correction to my earlier message:

The redefinition of the embedded regions didn't included the indentation. Here the correct ones:

==========
@embedded.e1() ::= <<r1>>

@embedded.e2() ::= <<
	r2
>>

@embedded.e3() ::= <<
	r3
>>

@embedded.e4() ::= <<
	r4
>>
==========

As a consequence the output now looks like this:

==========
---------
	ar1b
---------
	ar2b
---------
	a
	r3b
---------
	a
	r4b
---------
==========


In the meantime I had a look at the grammar file for the STParser. 

Currently the embedded region is defined as:

region
	:	INDENT? LDELIM '@' ID RDELIM NEWLINE?
		template
		INDENT? LDELIM '@end' RDELIM NEWLINE?
		-> ^(REGION ID template?)
	;

The starting newline is already discarded (good), so we only need to deal with the trailing newline.
Currently the last "NEWLINE?" eats the newline behind the <@end>. Moving the "NEWLINE?" behind the template solves half of the problem: the text following the <@end> is now used completely. 

region
	:	INDENT? LDELIM '@' ID RDELIM NEWLINE?
		template  NEWLINE?
		INDENT? LDELIM '@end' RDELIM
		-> ^(REGION ID template?)
	;

However the "NEWLINE?" behind the template has no effect. I assume the template is parsed in a "greedy" way and "NEWLINE?" is always matched to the empty string. I assume ANTLR could be configured to handle this differently but I am not that familiar with ANTLR. Ter?

For now I am using this workaround:

region
	:	INDENT? LDELIM '@' ID RDELIM NEWLINE?
		template  NEWLINE
		INDENT? LDELIM '@end' RDELIM
		-> ^(REGION ID template?)
	;

I.e. the <@end> must always start in a new line. 


Udo




On 19.02.2011, at 12:22, Udo Borkowski wrote:

> Hi,
> 
> I suggest to discard a trailing and leading newline in an embedded region. Also the newline following an <@end> should not be discarded.
> 
> This is consistent with the way these newlines are handled for templates and externally defined regions (trimOneStarting/TrailingNewline).
> 
> Currently a starting/trailing newline in an embedded region is handled differently than ones in an external region definition. This leads to problems e.g. when an embedded region is later redefined (by an external region in a sub group).
> 
> E.g.
> 
> This template using embedded regions:
> 
> ==========
> embedded() ::= <<
> ---------
> 	a<@e1>e1<@end>b
> ---------
> 	a<@e2>
> 	e2
> 	<@end>b
> ---------
> 	a
> 	<@e3>
> 	e3
> 	<@end>b
> ---------
> 	a
> 	<@e4>
> 	e4
> 	<@end>
> 	b
> ---------
> >>
> ==========
> 
> generates this output:
> 
> ==========
> ---------
> 	ae1b
> ---------
> 	ae2
> b
> ---------
> 	a
> 	e3
> b
> ---------
> 	a
> 	e4
> 	b
> ---------
> ==========
> 
> If one defines the same template using external regions, e.g.:
> 
> ==========
> nonEmbedded() ::= <<
> ---------
> 	a<@r1()>b
> ---------
> 	a<@r2()>b
> ---------
> 	a
> 	<@r3()>b
> ---------
> 	a
> 	<@r4()>
> 	b
> ---------
> >>
> 
> @nonEmbedded.r1() ::= <<r1>>
> 
> @nonEmbedded.r2() ::= <<
> r2
> >>
> 
> @nonEmbedded.r3() ::= <<
> r3
> >>
> 
> @nonEmbedded.r4() ::= <<
> r4
> >>
> ==========
> 
> the result is different (and more what I would have expected):
> ==========
> ---------
> 	ar1b
> ---------
> 	ar2b
> ---------
> 	a
> 	r3b
> ---------
> 	a
> 	r4
> 	b
> ---------
> ==========
> 
> Back to the embedded case: 
> when I now redefined the embedded regions in a different group with the same stuff as for the "nonEmbedded" case, with this
> ==========
> @embedded.e1() ::= <<r1>>
> 
> @embedded.e2() ::= <<
> r2
> >>
> 
> @embedded.e3() ::= <<
> r3
> >>
> 
> @embedded.e4() ::= <<
> r4
> >>
> ==========
> 
> I got a completely different picture:
> 
> ==========
> ---------
> 	ar1b
> ---------
> 	ar2b
> ---------
> 	a
> r3b
> ---------
> 	a
> r4b
> ---------
> ==========
> 
> 
> Udo
> 
> _______________________________________________
> stringtemplate-interest mailing list
> stringtemplate-interest at antlr.org
> http://www.antlr.org/mailman/listinfo/stringtemplate-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/stringtemplate-interest/attachments/20110219/47b9536b/attachment-0001.html