RE: mode line eol char indication

[Drew Adams]

> I agree with Juanma on the exactness issue.  Emacs is still first and 
> foremost a text editor, line endings are a pretty unavoidable 
> aspect of editing text files. And LF-ending files are not particularly
> uncommon on windows in my experience (which mostly involves windows
> boxes being used as little more than access terminals for less sucky 
> computers, mind).
> 
> I kinda dislike \n since in C \n doesn't mean LF in general 
> since it's defined to translate to whatever the native newline
> sequence is in files opened in text mode IIRC.
> 
> CR/LF/CRLF are nicely descriptive, though CRLF is a bit long.

It's 2 chars shorter than `(Unix)'.

> CR/LF/CL are all the same length, and there is no ASCII nonprinting 
> character called CL AFAIK.

`CL' is not readily recognizable. `CRLF' is - it uses standard abbreviations.

> ^M/^J/^M^J are similarly descriptive, and have the possible advantage 
> that one can directly concatenate them to other things and they will 
> still stand out somewhat, like /\: do, thanks to the caret.

I agree. Emacs users will sooner or later come to recognize ^M as carriage
return and ^J as line feed (newline). Might as well use these in the UI. They
are succinct and clear.

My vote is for ^M, ^J, and ^M^J, unless a more convincing argument can be made
for using platform names.

> BTW,  Unicode specs printable representations for ascii control 
> characters - see U+240A and U+240D.  On unicode text terminals and 
> graphical displays, might be nice to just use them?
> 
> http://unicode.org/charts/PDF/U2400.pdf
> 
> ?/?/??
> 
> Possible disadvantage being that not all fonts might include them I 
> guess, and some might supply peculiar glyphs for them (on my system
> they're just quite nice little mini cr and lf signs, shrug).

The disadvantage (which you mention, and which your text quoted above as ?/?/??
shows) outweighs the advantage of having a cute (admittedly standard) symbol:
just CR is fine; no need for 

C
 R