Subject: Questions about MULE

From: Andrew Innes <[email-masked]>
Date: Tue, 15 Apr 1997 14:14:36 +0100 (BST)

On Tue, 15 Apr 1997 00:39:58 -0400, Richard Stallman <[email-masked]> said:
>I see nothing problematical in these changes.
>The ones that have to do with cr conversion will have to be
>redone totally differently for the next Emacs release, though,
>because MULE affects this very much.

I am only dimly aware of what the MULE work for 19.35 entails, so if you
have time I would like to ask a few questions about it.

Since the issue of DOS vs Unix line ending conventions for text files is
currently handled poorly in 19.34 (in the DOS and Windows ports), there
has been a fair bit of discussion recently on the ntemacs-users mailing
list about possible mechanisms for improving this in the future.  This
applies primarily in the context of working with a mixture of text files
using both line ending conventions.

The main difficulties at present are that Emacs doesn't, in general,
correctly identify text vs. binary files, and for text files doesn't
remember which line ending convention was used.  The general thrust of
suggestions for improvement is to implement some kind of
mostly-automatic mechanism to detect which files are text, and remember
the line ending convention in use (DOS, Unix or possibly Mac).  Obvious
heuristics based on scanning the first part of each file when loaded for
"funny" characters could be used.  More sophisticated extensions which
detect mistakes in the assumed format follow on from that.

I know this issue overlaps somewhat with the more general language and
character encoding issues that are handled by MULE, but I'm not sure how
exactly.  Is there any documentation about MULE, as being implemented in
19.35, that I could read?

It seems to me that the line ending convention employed by text files is
often orthogonal to the character encoding convention (at least for
single-and multi-byte encoding, and for Unicode as well after allowing
for wider characters), and so a mechanism for automatically detecting
and propagating the convention in use could still be of value.

AndrewI