Re[3]: [SMARTY-DEV] Incorrect newline counters

> > Mark Rogers <mark@more-solutions.co.uk> (More Solutions Ltd) > > Can we be more specific in these examples to avoid confusion? Eg, what > should the following produce: > xxx > {if $foo} > bar > {/if} > yyy > Note the leading whitespace on the {if} block. So, example: ------------- xxx {if $foo} bar {/if} yyy ------------- Original Smarty writes: ------------- xxx bar yyy ------------- My patch writes: ------------- xxx bar yyy ------------- Suppose both are logically wrong, aren't? > I'm not to be honest sure what Smarty currently does or which I > think it should do, but we should be able to create some > documented test cases from which to work, and define their > required behaviour, if these don't already exist? That way any > proposed patch which breaks documented behavior can be easily > picked up on. Of course. But first, maybe, we need to standartize Smarty behavour? So, in the example - ------------- xxx {if $foo} bar {/if} yyy ------------- output, apparently, must be: ------------- xxx bar yyy ------------- So, we need NOT ONLY to eat trailing newline, but also leading spaces (today's Smarty does not trim leading spaces at all, before all kind of tags). So, the algorythm is the following. First, there are 2 kind of tags - "trimming" and "nontrimming". Nontrimming tags are replaced by its output one-by-one (keeping newlines). Trimming tags are more clever - they a) ALWAYS remove trailing spaces (including newline); b) remove LEADING spaces, but IF and only if these tags are placed in the line ALONE. For example, this IF tag is left-trimming ("_" is "space": ___000 ___{if ...}__ _____aaa ___{/if} ___111 Result: ___000 _____aaa ___111 And that IF - is not left-trimmed: ___000___{if ...}__ _____aaa ___{/if} ___111 Result: ___000___ _____aaa ___111 I am ready to carefully realize this functionality (keeping line number synchronization, of course), but first I need your sanction. > [The simplest definition of what they should do would be to > require the same behaviour as the current release, of-course, > unless there's a good reason to consider current behaviour > "wrong".] MO>> I'd say in theory, any function on a line **by itself** that does not MO>> produce output directly should not create a line in the output. So, #2 MO>> would probably be the expected output. Similar example: MO>> {if $foo} MO>> bar MO>> {/if} MO>> should output: MO>> bar\n MO>> and not: MO>> \nbar\n\n DK> Stop. It is identical to PHP's behaviour: DK> <?if (...) {?> DK> bar DK> <?}?> DK> Result is "bar\n". DK> But you had said before that newlines MUST not be ignored after DK> {...} constructions! DK> Can you explain this? Maybe newlines must be always deleted after DK> block-tags, but not after function-tag? DK> Can you explain the FULL behavour of different tags? -- Best regards, Dmitry Koteroff.