Re: line endings in Lout

[Robert A Duff]

Giovanni Zezaz said:

> Of course it is desirable, but it seems to me that it is actually feasible
> only as long as every file has either only one or only another end-of-line
> marker. If you edit DOS files in Unix or in Mac and vice versa with a not
> smart enough editor (Epsilon, for one, wisely preserves what it find), you
> may end with a mixed thing theoretically impossible to resolve: is CR+LF a
> single DOS end-of-line, or a Mac one followed by a Unix one, that are two
> end-of-line's?

You're right -- there are corner cases like that.  The answer in this
particular case should be, "CR+LF is an end-of-line", even though it
might "really" be a garbled concoction from two different systems.

I think the goal should be that if a file uses any of the four
conventions consistently, and is copied in binary mode to some other
system, it will be interpreted correctly.  If editors do weird things,
that's a secondary concern.

So if a file uses a mix of conventions, then:

> The best one can do is an educated guess, 

...educated guess is the best possible answer.  Even in this case, the
tool reading the "text" files should not blow up -- it just might get
line-counts off by 1 or so, which is not such a big deal.

>...it seems to me. Usually that will
> be enough, but sometimes it might lead to strange and difficult to
> understand behaviors. Or it's just my usual paranoia, and you have already
> considered and resolved this problem (in fact, it has nothing to do with
> DOS)?

The rule I would use is: a CR, LF, CR+LF, or LF+CR represents a single
end of line.  Use whichever is longest in the source file -- the usual
greedy sort of lexing algorithm.  So if the program sees something weird
like CR+LF+LF+LFxxx, that's interpreted as end-of-line, end-of-line,
end-of-line, then "xxx".  It is not hard for a lexer to do this.
Not rocket science, as they say.  ;-)

- Bob