Subject: New way to handle CRLF in Emacs 20.0

From: Eli Zaretskii <[email-masked]>
Date: Sun, 13 Jul 1997 20:59:41 +0300 (IDT)

> Actually, the new coding-system framework appears to obviate the need
> for buffer-file-type; file-coding-system-alist and
> buffer-file-coding-system appear to be flexible enough to supercede
> it.  I will need to think more about this, though, since it is a
> rather drastic change under DOS_NT.  (Eli and Andrew, if you get a
> chance to look at the coding system support, I would like to hear what
> you think about doing away with buffer-file-type, too.)

Here's what I think, after spending an evening reading the code and
playing with Emacs.

I also think that the coding system can supercede buffer-file-type.
We need to make a list of filename patterns that will automatically
guess the coding system given a filename.

If a given file is not in the list, Emacs should try to guess its
EOL format, like it does now.  Since this guess might be wrong (for
example, Emacs decides that the file is CRLF-style when it sees the
first CRLF pair, and might thus be fooled by a binary file), it would
be nice to have options e.g. to ask the user whether the guess is
correct, or require more than a single CRLF before a decision is
made.  (I didn't think about this too much, so I might be wrong.)

Emacs should only do the above for filesystems that aren't in the
untranslated list (for which all file I/O should be unconverted).

I'd like to see user options (other than to tell them set the coding
system) to have Emacs write files in specific (CRLF or LF) format.
the default behavior of preserving the original EOL encodings seems
reasonable.  The options would of course just set the coding system,
but I'd rather people who need to do this don't have to know too much
about coding systems.

I also think that the (un)?translated filesystem feature might be
useful to Unix users as well.  I can imagine NT or even DOS disks
mounted via networks, or people who run Linux-based systems and access
DOS partitions there (I actually see quite a few complaints from the
latter on gnu.emacs.help).  These might benefit by adding such disks
to translated systems' list and having Emacs handle the conversion.

So maybe it's a good idea to move this feature to lisp/files.el?

> Currently, the default for file-coding-system-alist is 'undecided.
> Under DOS_NT, this should probably be 'emacs-mule so that CRLF is
> decoded and encoded by default.

I agree.  But shouldn't we also set coding.eol_type, for the EOL
conversion to take place?  I though 'emacs-mule is not enough, no?

> file-name-buffer-file-type-alist and the untranslate functions.  The
> last issue is whether to remove buffer-file-type, but I won't do
> anything about that until more people agree that it is no longer
> necessary.

I think that it can go once the coding system handles everything.  We
need to decide whether the T: or B: in the modeline is necessary (it
seems that the coding system characters show the same information).

---

From: Richard Stallman <[email-masked]>
Date: Sun, 13 Jul 1997 17:41:39 -0400

I think that is not worth the trouble, given that we still have
find-file-text and find-file-binary.

---

From: Richard Stallman <[email-masked]>
Date: Sun, 13 Jul 1997 17:44:11 -0400

mounted via networks,

A feature like this could be useful; but some of the present details
don't fit this new context.  If you are running Emacs on a GNU system,
"untranslated" file systems are the usual case; file systems for which
new files should be translated are the special case.  This is the
opposite of the situation for MSDOS.

---

From: Richard Stallman <[email-masked]>
Date: Sun, 13 Jul 1997 17:45:24 -0400

> Under DOS_NT, this should probably be 'emacs-mule

No, definitely not.

       so that CRLF is
    > decoded and encoded by default.

CRLF encoding is supposed to happen just the same for undecided
as it does for emacs-mule.

      We

Yes, that is something we should decide right now.

---

From: Eli Zaretskii <[email-masked]>
Date: Wed, 6 Aug 1997 07:10:51 +0300 (IDT)

> find-file-text and find-file-binary.

A typical DOS/NT user doesn't even know these functions exist.  I
think that `find-file' should in most of the cases do the right thing
automatically, leaving the text- and binary-specific functions for the
marginal cases.

I will return to this issue when the more urgent problems are solved.
Hopefully, by then I will also have enough experience to judge this
objectively.