Subject: Re: EOL conversion on MSDOS and MS-Windows

From: Eli Zaretskii <[email-masked]>
Date: Tue, 19 Aug 1997 15:59:17 +0300 (IDT)

On Mon, 18 Aug 1997, Geoff Voelker wrote:

> !   if (coding.eol_type != CODING_EOL_UNDECIDED 
> !       && coding.eol_type != CODING_EOL_LF)
>       current_buffer->buffer_file_type = Qnil;
>     else
>       current_buffer->buffer_file_type = Qt;

Hmm...  If the EOL coding is still undecided, why should the file be 
marked as binary?  Shouldn't it be text by default?  The above code means 
that if I read a file which has no newlines, it will be treated as 
binary.  Is this correct?

---

From: Richard Stallman <[email-masked]>
Date: Tue, 19 Aug 1997 14:45:24 -0400

If this question concerns ONLY the case of a file with no newlines,
then I agree with you, that should be considered a text file by default.

But there is a related question: what will happen with the actual
writing of the file?  If buffer-file-coding-system is undecided
as regards the eol conversion, what will happen if the user
inserts some newlines and then saves the file?  What eol convention
will be used for saving the file?

---

From: Eli Zaretskii <[email-masked]>
Date: Wed, 20 Aug 1997 17:37:14 +0300 (IDT)

> will be used for saving the file?

I think Emacs will use the EOL convention that is determined by 
buffer-file-type.

Here's the last fragment from find-buffer-file-type-coding-system (on 
lisp/dos-w32.el) in its current incarnation:

	((eq op 'write-region)
	 (if buffer-file-coding-system
	     (cons buffer-file-coding-system
		   buffer-file-coding-system)
	   (if buffer-file-type
	       '(no-conversion . no-conversion)
	     '(undecided-dos . undecided-dos)))))))

So if the buffer type is text (nil), Emacs will add CR characters, if 
it's binary (t), it won't.

Personally, I tend to make it text file, so it will be written in DOS
text format.  But I'm afraid that this tendency is a left-over from
the previous Emacs behavior whereby it would rewrite LF-only files
with CRLF EOLs.  And we have changed that behavior.  So now I'm not
sure whether my gut feelings are correct.

Geoff, what do you think?

---

From: Richard Stallman <[email-masked]>
Date: Wed, 20 Aug 1997 13:20:31 -0400

Looking at the code, I think that is true only if
buffer-file-coding-system is nil:

	((eq op 'write-region)

If buffer-file-coding-system is non-nil, that overrides
buffer-file-type.  And buffer-file-coding-system should always be
non-nil, if you have visited an existing file.

When you visit a file that contains no newlines,
buffer-file-coding-system gets set to undecided.  It will still be
undecided when you save the buffer.  So the question is, what does
saving the buffer do when buffer-file-coding-system is undecided?
Handa, can you tell us?

---

From: Eli Zaretskii <[email-masked]>
Date: Wed, 20 Aug 1997 21:36:12 +0300 (IDT)

On Wed, 20 Aug 1997, Richard Stallman wrote:

> undecided when you save the buffer.

Hmm... for some reason when I read a file without newlines, the coding 
system gets set to undecided-dos, although that function on dos-w32.el 
indeed sets it to undecided.  I will have to debug this.

>  So the question is, what does

I have set the coding system manually to undecided, added a newline and 
saved it.  It got a Unix-style linefeed (as I'd expect, since that is the 
default when EOL type is not set).

---

From: Richard Stallman <[email-masked]>
Date: Wed, 20 Aug 1997 20:44:10 -0400

Hmm... for some reason when I read a file without newlines, the coding 
    system gets set to undecided-dos,

That might be a good default on DOS.

Or perhaps, on DOS, if the buffer-file-coding-system is still
undecided when you first save the file, save it using undecided-dos
instead.  More precisely, if the eol conversion is still undecided
when saving the file, on DOS, then save it using the DOS eol
conversion.

(I am assuming that this will have no effect on files whose names or
file systems are recognized as determining which eol convention to
use; I'm assuming that in those cases buffer-file-coding-system will
specify the eol convention precisely.  If that's not true,
my proposal won't be good.)

---

From: Kenichi Handa <[email-masked]>
Date: Thu, 21 Aug 1997 09:46:23 +0900

> default when EOL type is not set).

How about setting default-buffer-file-coding-system to 'undecided-dos
on DOS?

---
Ken'ichi HANDA
[email-masked]

---

From: Richard Stallman <[email-masked]>
Date: Thu, 21 Aug 1997 01:54:49 -0400

That might be right, but I am not sure.
What effect would that have, in the various cases?

For example, what effect would this have when you visit a file
with no line separators in them?

What would happen if you add some newlines and save the file?

What effect would this have when you visit a file
that uses the Unix EOL convention?

What effect would this have when you create a buffer
with C-x b, and then save it in a file?

---

From: Kenichi Handa <[email-masked]>
Date: Thu, 21 Aug 1997 20:00:51 +0900

> with no line separators in them?

buffer-file-coding-system of the new buffer is set to 'undecided-dos
if the file contains only ASCII.  If the file contains Japanese text
encoded in iso-2022-7bit, buffer-file-coding-system is set to
iso-2022-7bit-dos.

Thus,

> What would happen if you add some newlines and save the file?

the file is saved by DOS EOL convention.

> that uses the Unix EOL convention?

Unix EOL convention is detected correctly, and
buffer-file-coding-system of the new buffer is set to XXXX-unix.

> with C-x b, and then save it in a file?

buffer-file-coding-system of the new buffer is still nil, but since
default-buffer-file-coding-system is undecided-dos, it is saved by DOS
EOL convention.

I think all these behaviours are appropriate.

---
Ken'ichi HANDA
[email-masked]

---

From: Richard Stallman <[email-masked]>
Date: Thu, 21 Aug 1997 17:48:24 -0400

>     How about setting default-buffer-file-coding-system to 'undecided-dos

Ok, this sounds like a good idea.  Could someone please make the change?

---

From: Eli Zaretskii <[email-masked]>
Date: Mon, 25 Aug 1997 08:07:49 +0300 (IDT)

> Ok, this sounds like a good idea.  Could someone please make the change?

No need to do anything, it is already set this way.  See lisp/dos-w32.el.