Re: Editting Unix files using MCL.

[dblamkins@aol.com]

Mark Peot writes:

> The problem only pertains to files that are *editted*. Lisp itself
> does not care about the kind of white space it encounters... The
> problem concerns the appearance of the file in different editors. Gnu
> Emacs uses the linefeed character to mark the end of a line. MCL uses
> a carriage return. When I read MCL files using Emacs, I see lots of
> ^M's where carriage returns ought to be. When I read Emacs files
> using FRED, I see lots of boxes (the unprintable character is the
> linefeed character) where the carriage returns ought to be.
>
> Tell me if the following 'bombs' in your environment.  *Create* a new file:

> ------------------
> foo
> bar
> ------------------
> using MCL.  Save it to your Unix file server.  Look at it using Emacs.  On
my
> machine it looks like:
> ------------------
> foo^Mbar
> ------------------
> This happens 'cause the natural newline character for emacs is the linefeed
> character, not the carriage return character...

MCL is saving a normal Macintosh text file, which (correctly, for the Mac)
uses CRs to delimit lines. From your description, it seems that you are
saving a file to a Unix-hosted disk volume from MCL. No doubt the file
server software goes to great lengths to make the volume appear just like a
Mac volume -- why would you expect MCL to do anything _but_ save a normal
Macintosh text file?

I think it's more reasonable to expect the Unix-based Mac file server to
recognize a 'TEXT' file creator and perform the appropriate transformations
(perhaps when the file is closed?) on line delimiters. A Mac application
has no way to determine that the volume it's writing to has a semantics for
text files that's any different from the Mac standard...

BTW, the reason that Bob Hall doesn't see this problem is that he adds a
translation step to the process:

BH> I use Versaterm on the Mac to transfer the files to/from UNIX over
BH> a phone line.

Versaterm is doing a Mac->Unix text file translation on the fly...

Dave