Re[8]: Incorrect newline counters

Dmitry Koteroff <[email protected]>
Newsgroups gmane.comp.php.smarty.devel
Message-ID <[email protected]>
B> --- Dmitry Koteroff <[email protected]> wrote:
B>> Yes, this is a known behaviour that is suboptimal. What do you
B>> expect  I  have  done  to-date?

DK>> I  expect  nothing,  of  course. On the contrary - I offer to fix
DK>> this by myself (later or soon), modifying and automatizing method
DK>> which is used to generate compiled code (tags must not care about
DK>> \n's and line sync at all, newlines are not their business).

B> Of  course  my question was rhetorical as I answered it myself
B> (but  you  cut that part out)--I workaround this issue. That's
B> why  I  continutally  quote  "fix"  in this regard; it isn't a
B> "fix"  if  it  breaks  working code, but rather is a change. A
B> subtle but important difference, IMO. If there was a published
B> spec   that   Smarty   was   breaking,   that  is  one  thing;
B> unfortunately,  this  was  never formalized--but at least it's
B> behaviour was understood to lesser and greater degrees ;-)

I'd  like  to  return  back  to the subject of this thread - line
numbers  synchronization.  To  achieve  this  purpose, we need to
break  some  lines of code, it's obviously. But simultaneously we
could  improve  whitespace  behavour  -  it is hardly depended on
line-number sync. Two dependent tasks.

DK>> Proposals of new behavour (eating leading whitespaces) are here:
DK>> http://news.php.net/article.php?group=php.smarty.dev&article=2371
B> Yes, that is one of the posts I am refering to :)
Later I can formalize it more.

B>> It appears that there is now some discussion and documentation
B>> occuring  around  that  point  and that is far more acceptable
B>> than a patch to a sensitive area that merely purports to be an
B>> improvement  without  providing  even  test  cases let alone a
B>> thorough examination of the issues.
DK>> We  should  reach  agreement  first about whitespace concept, and
DK>> only after that write test cases.
B> Conversely,   the   current   behaviour  must  be  documented,
B> otherwise  it  will  be  hard to explain what changes one will
B> need to make to their existing codes.
Leading space eating may be optional - it may be turned on by any
Smarty property, for example.

B> Instead of taking all of this on yourself, what would help you
B> get these goals accomplished?
Time, only some time - and assurance that I am do it not only for
myself, but for later official releases. I think I've got it?


I'd  like  to bring on some clarifications about line sync in one
place  now. My patch (for line sync) now does satisfy me fully in
my  applications  (though  it does not work as original Smarty in
case  of  whitespaces).  But  I'd  like  to share it with others,
because  it opens new perspectives for Smarty as template library
(for  example, using in slave controller environment, not in lead
controller,  as  usual).  Moreover,  it allows to debug templates
easily, forgetting about compilation process at all.

Imagine  that  C language compiler does not have #line directive.
What  do  we have in this case? Let's see output generated by cpp
preprocessor:

[root@alpha dk]# cat >a.c
#include <stdio.h>
void main(void) {}
^D

[root@alpha dk]# cpp a.c
# 1 "a.c"
# 28 "/usr/include/stdio.h" 1 3
# 284 "/usr/include/features.h" 1 3
...
# 634 "/usr/include/stdio.h" 3
# 2 "a.c" 2
void main(void) {}

You  see  that it it has 879 lines, and main() is defined only at
last line! But thanks to #line - when we compile all this heap of
code,  and  make  error in main(), compiler report about error in
line 2, not in line 879.

PHP  unfortunately  does  not  support #line (as Perl and C), but
when we use Smarty, we get the same situation as described above.
And  the  only  way  to  correct  it  -  to  automatize  PHP code
generation  to  centralized  control each \n which is inserted by
tags.

I  think  that  one  of  the  most important thing while creating
compiling system is to provide easy way for debugging. We can see
a  lot of mistakes in this field (JSP, for example), and I'd like
to free Smarty from this weakness.

-- 
Best regards,
  Dmitry Koteroff.

-- 
Smarty Development Mailing List (http://smarty.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.