Subject: EOL conversion on MSDOS and MS-Windows

From: Eli Zaretskii <[email-masked]>
Date: Thu, 14 Aug 1997 19:31:42 +0300 (IDT)

Geoff, there's something that bothers me in the way Emacs 20.0.93 
computes and displays the EOL conversion.  There is a seeming 
inconsistency between the setting of coding system for reading and for 
writing.

When Emacs reads a file that is not in the alist of known file types, it 
sets the coding system to undecided.  If the file happens to be a 
Unix-style (like e.g. those in Emacs source distribution), it ends up 
being *-unix, and Emacs displays `:' in the modeline.  However, if you
then save the file, the coding system is set to undecided-dos, and Emacs 
adds CR characters.  But the coding system displayed on the modeline does 
not change.  It will only change if you revert the buffer or restart 
Emacs.

I think this is confusing.  When users look at the modeline, they should 
be able to determine how will the file be written to disk.  So I think 
the coding system should be by default set to undecided-dos on reading 
the file (unless the file matches in the buffer-type-alist or is on 
untranslated filesystem etc.).

---

From: Richard Stallman <[email-masked]>
Date: Fri, 15 Aug 1997 03:41:01 -0400

When Emacs reads a file that is not in the alist of known file types, it 
    sets the coding system to undecided.  If the file happens to be a 
    Unix-style (like e.g. those in Emacs source distribution), it ends up 
    being *-unix, and Emacs displays `:' in the modeline.

That sounds correct.
     
							   However, if you
    adds CR characters.

If the file existed, and used LF to separate lines,
Emacs should save it with LF between lines.

So this sounds like a bug right there.

Can you fix it?

      So I think 

Definitely not.  This would just cause the same bug in a different way.

undecided-dos should be used (on MSDOS) when you visit a nonexistent file.

Can you implement this?

---

From: Richard Stallman <[email-masked]>
Date: Fri, 15 Aug 1997 15:19:23 -0400

I think you are right, Eli.  I came to the same conclusion when I went
    back to look at the code when answering some of Marc Fleischeuers'
    questions, and I have made the change in my local version but have yet
    to check it in.

Please don't!  It is wrong to alter the end-of-line convention
for an existing file unless the user explicitly asks for it.
We need to fix this bug, not reimplement it differently.

      My
    confusion when I first wrote the code was that I thought "undecided"
    referred to the eol format (so when the file was read in, undecided
    would figure out and use dos eol format

It does mean that, and it does do that.  At least it does for me.
When I read in a file which uses CRLF between lines, and then look at
buffer-file-coding-system, I get undecided-dos, which is exactly what
it should be.

But when I read a file that uses LF between lines,
buffer-file-coding-system is undecided-unix, which is also correct.

Both of these things should happen exactly the same on MSDOS as
they do on GNU and Unix systems.