Re: [SMARTY-DEV] Incorrect newline counters

If you are willing to put forth the effort to be sure all these changes are tested and accurate, I don't have a problem with them. I can see where the leading whitespace removal could be useful, there are many instances where I butt the tags against the left margin to avoid the white space. But, this is a change in behavior. Question is, how will this affect current templates that may expect the leading white space? It may require some folks to tweak their templates, but I think this change would be for the better. It seems to be a more intuitive and convienient behavior. (eg. keep the tag indenting, yet not introduce white space into the rendered template.) Dmitry Koteroff wrote:

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?