From: Christopher C. Stacy
Subject: newline incompatability on Unix vs. Windows (CMUCL)
Date:
Message-ID: <u8ygn9a9t.fsf@news.dtpq.com>
CMUCL barfs on FORMAT control strings like:
(format nil "SELECT ~A FROM ~A ~
WHERE THIS SOURCE FILE ~
ORIGINATED IN emacs ON windows")
Any suggestions?
Maybe there's something I should be doing in Emacs
to control the EOF encoding better.
I think Lispworks, which is the Windows side,
is tolerant of either newline encoding.
I wish CMUCL was, too, by the way.
In article <·············@news.dtpq.com>,
······@news.dtpq.com (Christopher C. Stacy) wrote:
> CMUCL barfs on FORMAT control strings like:
>
> (format nil "SELECT ~A FROM ~A ~
> WHERE THIS SOURCE FILE ~
> ORIGINATED IN emacs ON windows")
>
> Any suggestions?
I think it should barf because there are no parameters corresponding to
the ~A codes in the format string.
>
> Maybe there's something I should be doing in Emacs
> to control the EOF encoding better.
Are you running the program on Unix or Windows? I would expect a Unix
implementation to make use of Unix newlines, and a Windows
implementation to use Windows newlines.
If you wrote the source file on Windows and then transferred it to a
Unix box, you should use a text-mode file transfer that performs newline
translations.
> I think Lispworks, which is the Windows side,
> is tolerant of either newline encoding.
> I wish CMUCL was, too, by the way.
What if it were a Unix file that intended to have a literal CR character
before its newline? If it's accepting of Windows newlines, it will
interpret this CR-LF combination as a single newline, effectively
ignoring the CR.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
From: Christopher C. Stacy
Subject: Re: newline incompatability on Unix vs. Windows (CMUCL)
Date:
Message-ID: <u3c6vrh0z.fsf@news.dtpq.com>
>>>>> On Thu, 22 Apr 2004 14:11:04 -0400, Barry Margolin ("Barry") writes:
Barry> In article <·············@news.dtpq.com>,
Barry> ······@news.dtpq.com (Christopher C. Stacy) wrote:
>> CMUCL barfs on FORMAT control strings like:
>>
>> (format nil "SELECT ~A FROM ~A ~
>> WHERE THIS SOURCE FILE ~
>> ORIGINATED IN emacs ON windows")
>>
>> Any suggestions?
Barry> I think it should barf because there are no parameters
Barry> corresponding to the ~A codes in the format string.
That's obviously not what I was talking about.
>>
>> Maybe there's something I should be doing in Emacs
>> to control the EOF encoding better.
Barry> If you wrote the source file on Windows and then transferred
Barry> it to a Unix box, you should use a text-mode file transfer
Barry> that performs newline translations.
I'm using SMB to access the files and I don't think
I have control over the transfer mode like that.
What I am wondering, I guess, is if there is an Emacs command
that will alter the file encoding on Windows, so that when Unix
sees the file it will have the Newlines that CMUCL likes.
Or maybe there's something in CMUCL that I could do to
get rid of the problem.
From: Edi Weitz
Subject: Re: newline incompatability on Unix vs. Windows (CMUCL)
Date:
Message-ID: <m37jw7x23i.fsf@bird.agharta.de>
On Thu, 22 Apr 2004 18:42:20 GMT, ······@news.dtpq.com (Christopher C. Stacy) wrote:
> What I am wondering, I guess, is if there is an Emacs command that
> will alter the file encoding on Windows, so that when Unix sees the
> file it will have the Newlines that CMUCL likes.
(defun unix-file ()
"Change the current buffer to Latin 1 with Unix line-ends."
(interactive)
(set-buffer-file-coding-system 'iso-latin-1-unix t))
Edi Weitz <···@agharta.de> writes:
> (defun unix-file ()
> "Change the current buffer to Latin 1 with Unix line-ends."
> (interactive)
> (set-buffer-file-coding-system 'iso-latin-1-unix t))
This one is more general:
(defun unix-file ()
(interactive)
(set-buffer-file-coding-system
(coding-system-change-eol-conversion buffer-file-coding-system 'unix)))
--
Alan Shutko <···@acm.org> - I am the rocks.
Kind of stupid game, isn't it ? - Calvin
From: Christopher C. Stacy
Subject: Re: newline incompatability on Unix vs. Windows (CMUCL)
Date:
Message-ID: <ullknzuyw.fsf@news.dtpq.com>
>>>>> On Thu, 22 Apr 2004 21:08:17 +0200, Edi Weitz ("Edi") writes:
Edi> On Thu, 22 Apr 2004 18:42:20 GMT, ······@news.dtpq.com (Christopher C. Stacy) wrote:
>> What I am wondering, I guess, is if there is an Emacs command that
>> will alter the file encoding on Windows, so that when Unix sees the
>> file it will have the Newlines that CMUCL likes.
Edi> (defun unix-file ()
Edi> "Change the current buffer to Latin 1 with Unix line-ends."
Edi> (interactive)
Edi> (set-buffer-file-coding-system 'iso-latin-1-unix t))
Thanks!!
From: Tim Bradshaw
Subject: Re: newline incompatability on Unix vs. Windows (CMUCL)
Date:
Message-ID: <ey3k707kf8q.fsf@cley.com>
* Christopher C Stacy wrote:
> I think Lispworks, which is the Windows side,
> is tolerant of either newline encoding.
> I wish CMUCL was, too, by the way.
I think you need external formats to work in CMUCL - LW does some
fairly clever trick I think to look into the file and decide what the
end of line convention is and select an appropriate external format.
You can tell it to use a specific one though.
--tim