Re: ~<newline> format operator

Gary Byers wrote:
> 
> On Thu, 27 Mar 2003, james anderson wrote:
> 
> [example of problem with "unexpected" eol-encoding in format control strings]
>
> > i've come to expect this from allegro, but it would be nice if openmcl
> > recognized all macintosh end-of-line encodings.
> 
> I'm very leery of attempts to automatically intuit whether a potential
> line-termination character is intended to terminate a line or is intended
> to be taken literally.  I think that it should be possible to say things
> like:
> 
> (defvar *crlf-string* "^M^J")  ; two embedded control characters, both
>                                ; potential line terminators
> 
> and be confident that no loss of information takes place.

i do not suggest that there should be any general normalization.

> 
> I don't think that that example's particularly pathological, though I'd
> agree that the majority of Mac text files:
> 
>   a) contain at most 1 of #\Return, #\Linefeed
>   b) always use that line-termination character as a line-termination
>      character

usually i would agree. at the moment, however, i'm dealing with sources which
have made several round-trips through linux and would make no claims about consistency.

> 
> In general, I think that it's better for the user to specify what type
> of newline-translation (if any) is appropriate; for some users (and
> some sets of files), it may be most appropriate to allow the system to
> infer the newline convention.  See
> 
> <http://openmcl.clozure.com/Doc/line-termination.html>

i'll look at that.

> 
> By default, OpenMCL allows either #\Return or #\Linefeed to terminate
> a #\; comment (the argument being that very few source files
> will contain control characters of any sort embedded in comments
> and that this behavior allows a high percentage of source files to
> be correctly processed without further concern for line-termination
> issues.)

were this not true, it ie easy enough to work around by just replacing the #\;
reader. the problem with format controls is that there is no alternative to
translating the string. which means one needs to keep separate sources for
different os-bases. i've given up on that and just turn on line wrap in my
editor buffers, but that does not fix the problem.

> 
> Someone suggested not too long ago that making ~<return> behave the
> same way as ~<newline> was justified on similar grounds, and I tend
> to agree with that argument.

i would say more so, since there is no legal format control operator for the
respectively "other" eol encoding.

...