On Wed, 3 Mar 2010, Russell McMahon wrote:

> > end-of-line needs to be well defined and strictly observed. What
> > combination of CR/LF is treated as a end-of-line? If the compiler
> > encounters CR on its own should it be treated as end-of-line? Should CR/LF
> > be treated the same as LF/CR? Should CR/CR/LF be treated as 1 end-of-line
> > or 2? What about LF/LF/CR? what happens when you mix and match LF and CR
> > as end-of-line in the same source? How many end-of-line is one "vertical
> > tab" or "form feed" equivalent too?
> 
> 
> Your pint is well taken but, seing you asked ;-), a wrokable rulle seems to be.
> 
> - Any contiguous group of CR or LF caharcters is taken a s single EOL.
> 
> This may break some visual formatting but seems liable to work for
> code compilation.

But visual formatting (line numbers) is VERY important. The compiler needs 
to be consistant with your editor and debugger. Yes you can do anything 
you want in the compiler but it needs to be consistant with the other apps 
in your system. If the compiler tells you there is a problem on line 1000 
of your source you want to be able to open your source with ANY editor you 
choose, go to line 1000 and fix it. You don't want to hunt around trying 
to figure out that the compiler's understanding of line 1000 is actually 
the editors line 950. Worse still, when you are debugging, you want the 
next source line under the hammer to really be the one you think it is 
(the one you are looking at) not a different one that the debugger thinks 
it is because the compiler got the line numbers wrong.

It needs to be consistant across all your apps. What better way to ensure 
this than to use the system definition of EOL. Ok, we've seen a problem 
but that was really down to the editor trying to be clever and doing its 
own thing rather than respecting the system definition of EOL.

Friendly Regards
Sergio Masci
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist