GNU bug report logs - #7626
23.2.91; Rmail shows incorrect message encoding in the mode line

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kenichi Handa <handa <at> m17n.org>
Cc: 7626 <at> debbugs.gnu.org
Subject: bug#7626: 23.2.91; Rmail shows incorrect message encoding in the mode line
Date: Mon, 17 Jan 2011 07:24:12 -0500

> From: Kenichi Handa <handa <at> m17n.org>
> Cc: 7626 <at> debbugs.gnu.org
> Date: Mon, 17 Jan 2011 20:35:38 +0900
> 
> In article <E1Pemui-00053A-Iv <at> fencepost.gnu.org>, Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > But the mbox format uses Unix EOLs.
> 
> On Windows too?  I didn't know that.

It must, because Rmail reads the mbox file or stream with
no-conversion.

> > In fact, Rmail will barf if you
> > say "C-u g FILE RET", and FILE has DOS EOLs.  So the EOL format is
> > known in advance in this case.
> 
> Are you arguing that typing 'o' (rmail-output) will write
> DOS EOL file when EOL type of buffer-file-coding-system of
> rmail buffer is undecided and the system_eol_type is DOS?
> Then, isn't it a bug of rmail-output?

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.  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.

> 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?
Why is this use-case different?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.