Re: ~<newline> format operator

On Thu, 27 Mar 2003, james anderson wrote:

> this operator appears to insist on pc/unix eol conventions. that is, a
> file which ex edited with classic eol encoding causes errors, where
> something like (please don't mind the formulation - it's just as close
> to the actual code as possible; only the ~@<newline> operator matters)
> causes an error
>
> (apply #'format t "~%~%~@R. ~@? :~%"
>         1 (rest '(dummy
>                   "a change of the prefix specified for a local
> namespace binding ~
>                    has the expected effect on the serialized document,
> even though~@
>                     ~s.name.prefix remains = ~s"
>                   <child-elem> "prefix")))
>
> 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 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

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>

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.)

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.