From: Kenichi Handa <handa@m17n.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 7626@debbugs.gnu.org
Subject: bug#7626: 23.2.91; Rmail shows incorrect message encoding in the mode line
Date: Tue, 18 Jan 2011 20:44:21 +0900 [thread overview]
Message-ID: <tl7pqruxwq2.fsf@m17n.org> (raw)
In-Reply-To: <E1Peo84-0006Nu-O4@fencepost.gnu.org> (message from Eli Zaretskii on Mon, 17 Jan 2011 07:24:12 -0500)
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
next prev parent reply other threads:[~2011-01-18 11:44 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-12 22:21 bug#7626: 23.2.91; Rmail shows incorrect message encoding in the mode line Eli Zaretskii
2010-12-13 0:29 ` Kenichi Handa
2010-12-13 3:47 ` Eli Zaretskii
2011-01-01 11:20 ` Eli Zaretskii
2011-01-14 4:28 ` Kenichi Handa
2011-01-14 17:22 ` Eli Zaretskii
2011-01-17 1:22 ` Kenichi Handa
2011-01-17 11:06 ` Eli Zaretskii
2011-01-17 11:35 ` Kenichi Handa
2011-01-17 12:24 ` Eli Zaretskii
2011-01-18 11:44 ` Kenichi Handa [this message]
2011-01-18 15:23 ` Eli Zaretskii
2011-01-20 3:53 ` Kenichi Handa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=tl7pqruxwq2.fsf@m17n.org \
--to=handa@m17n.org \
--cc=7626@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.