bug#7626: 23.2.91; Rmail shows incorrect message encoding in the mode line

[Kenichi Handa <handa@m17n.org>]

In article <E1Peo84-0006Nu-O4@fencepost.gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> That's a separate issue.  I just don't like seeing a buffer whose file
> was read with no-conversion show ":" as the EOL mnemonic.

After the change of rmail to mbox-base, the buffer whose
file was read with no-conversion is " *message-viewer
RMAIL*", and the buffer "RMAIL" is what showing the decoding
result of a part of " *message-viewer RMAIL*".  Even if you
see "-1:" or "-1(unix)" in the modeline, it doesn't mean the
mbox file is read with iso-8859-1.

So, I don't understand why you so much care EOL part even if
you don't care that the text-encoding part is shown as "1"
(meaning iso-8859-1) instead of "=" (meaning no-conversion).

> It's not a
> catastrophe, I just don't see why we should change this aspect of
> Rmail which is how it behaved for several Emacs releases.

I haven't realized that the change results in the actual
difference on screen on Windows.  On GNU/Linux, both *-unix
and undecided are indicated by ":".

Anyway, if Windows users are already familiar with seeing
"(unix)" in the modeline of RMAIL buffer, don't want to
change it, and want to make M-x write-region to write out a
region of RMAIL buffer with Unix-style EOL as before, I'll
change the current behavior.

> > The reason I decided to leave EOL type undecided is for the
> > case of M-x write-region on rmail buffer.  In that case, I
> > think, following system_eol_type is the right thing.

> But we don't behave like that with buffers that visit files, do we?

Of course no, because in that case, it's the right thing to
follow the file's EOL format.  But, when you open a new
buffer, write a few lines of text, and save some region into
a file, the EOL type of the saved file is CRLF on Windows.

> Why is this use-case different?

As I wrote above, RMAIL buffer's buffer-file-coding-system
doesn't reflect how the corresponding mbox file is read.

---
Kenichi Handa
handa@m17n.org