Re: EOL: unix/dos/mac

[Stephen J. Turnbull]

Richard Stallman writes:

 > > The end-of-line indicators for coding systems are unix, dos, and
 > > mac.  I suggest they are replaced with lf, crlf, and cr.
 > 
 > Someone needs to check how this would affect non-wizard users.

I don't see why it would.  Non-wizards rarely want to see it at all,
and usually have a very incomplete understanding of what it means.
IME that's what it means to be a non-wizard.  Even in Japan, where
users encounter 4 or 5 (!!) encodings *every* *day* (ISO-2022-JP in
mail headers, EUC-JP and Shift JIS in text files from older *nix and
Micros*ft environments, UTF-8 in text files from modern environments,
and UTF-16 in file names on NT file systems), younger users don't even
realize that they're there.  They just call coding problems "mojibake"
and ask for corrected data.

I think a better way to present this information would be to put it in
a separate "troubleshoot this buffer" function.  Perhaps adding it to
C-u C-x =, or a separate function on C-h = (both with the nuance
"troubleshoot around point").  Caveat: I have no empirical evidence
for the feeling that this would be better, just introspection and
experience with helping users who are not much helped by the current
UI.

The idea is that ordinarily, Emacs just Does The Right Thing, so
there's no need to know what the EOL suffix (or for that matter the
EOL modeline indicator) means, and many users forget or never learn.
If they *do* run into trouble like "stair-stepping" or "^M" in a
buffer, they can use C-u C-x = to find out "what's different about
this linebreak".