RE: mode line eol char indication

[Drew Adams]

> > * The non-"nontrivial" eol convention, represented by `:', is
> >   presumably what is meant by "usually", that is, a newline char.
> >   But a newline eol is also sometimes represented by `(Unix)'.
> >   Why?  And why is this called "nontrivial" - why is it more
> >   nontrivial and more usual than the other possibilities?

I meant "trivial", sorry. The doc claims that line endings other than newline
are nontrivial.

> In Emacs 20, only the single character indications were used, 
> but people found them confusing. But the full word indications
> are too long for many people, so now we use the single
> character when the newline format is native for the platform
> Emacs is running on, and the full word when it is non-native -
> this change occurred in 21.1 IIRC. Unix line ends are
> non-trivial

(I think you too meant "trivial" here, for UNIX.)

> because they are what Emacs uses internally - no conversion 
> is required.

What's trivial for the implementation shouldn't be behind characterizing this
line ending to the user as more trivial. Why would a user care which is easier
to implement?

> They are more usual for users of GNU based platforms 
> because GNU is based on unix conventions.

Yes, and less usual for users of other platforms. But who cares?

My argument is not that one or the other is more trivial or more usual. It's
that:

* Neither is more trivial (for the user) or more usual (for the user).

* It's unimportant whather one is in fact more trivial or more usual. Such a
characterization is not explained in the doc anyway, and it just makes the doc
less understandable.
 
> > Why `:'?  Why `\' (is there some relation to the DOS directory
> > separator?)?  Why `/'?
>
> Originally : was was based on the unix PATH separator, and \ 
> on the DOS directory separator. / was made the Mac indicator
> because like the DOS separator, it is not straight up and down,
> but it leans a different direction than DOS. I think at some
> point during 20.1 pretest, we had / for Unix and : for Mac,
> until someone pointed out that : was less noticeable, so that
> should indicate the trivial Unix line-end.

Well, all of that is a historical explanation, and it gives a bit of the
rationale accepted at the time, but it's not very convincing as to why it's the
best choice or why we should have two different representations for each line
ending. Not to mention why the doc should be so convoluted trying to explain it.

To me:

1. There is no logical connection with the path separator or the directory
separator that is used for a given platform and the line ending used for that
platform.

That's an artificial connection that is too cute by half. We're asking users to
guess the line ending based on the platform, and guess the platform based on
either a path separator (for UNIX) or a directory separator (for Mac/DOS).
(Guess what this means: `:'? It's the UNIX path separator, so this buffer has
UNIX line endings.)

If we're trying to indicate the _line ending characters_, then lets just say
what they are: C-j, C-m, or C-j C-m.

2. Unix, DOS, an Mac are preferable to :, \, and /. Much clearer.

3. \n, \n\r, and \r would also be preferable to :, \, and /.

4. C-j, C-j C-m, and C-m would also be preferable to :, \, and /.

5. We should pick just one label for each line-ending, not have two alternatives
for each. Either name the platform or name the line ending, consistently,
always.

6. If the aim is to indicate the platform, then use Unix, DOS, and Mac. If the
aim is to indicate the line ending, then use \n, \n\r, and \r.