Emacs (Gnus), mail, news, and multiple encodings

[Ivan Shmakov]

>>>>> Stainless Steel Rat <rat...@gweep.net> writes:
>>>>> On Thu, 28 Mar 2013 09:46:10 +0000, Ivan Shmakov wrote:

[Well, cross-posting to news:news.software.readers and
news:comp.mail.misc. Perhaps news:gnu.emacs.gnus might have
been a better choice, but I'm somewhat cautious as to cross-post
to a Mailman-backed newsgroup.]

>> Frankly, I can't readily recall of /any/ text editor that would
>> allow for multiple encodings for a single file. Could you please
>> name one?

> Not that it's terribly relevant since there are no text editors out
> there other than Emacs that can be used to read mail and news (that I
> know of).

But then, in what I'd consider the "proper" setup, Emacs
accesses IMAP and NNTP servers to get mail and news, and not
some files directly. So, yes, the lack of multiple encodings
per file support is irrelevant for the task.

> But the answer is: Emacs but only if the coding system for the buffer
> is set to 'binary.

Yes.

>> As with virtually all the other editors I ever encountered.

> Perhaps, but I can't name one besides Emacs that has ever been
> responsible for corrupting an entire mail spool because of it.
> Because MULE's developers think that automatic detection is always
> correct.

> It isn't. There are three or four places in pop3.el where I had to
> explicitly set the coding system to 'binary because MULE's automatic
> detection would eat Gnus users' mail. And then some thick-headed
> MULE maintainer removed those settings after pop3.el was submitted
> for packaging because auto-detection is always correct, so I was
> told.

> But I'm out of it at this point. I had this argument with the Emacs
> maintainers some 10-15 years ago. The results of that argument,
> along with issues regarding code forks and responsibility thereof, so
> angered and disgusted me with the FSF's development processes that I
> dropped Emacs development entirely.

Incidentally, some 10 years ago was the time when I dropped both
POP3 and the Unix mbox format entirely.

Nowadays, it's the Dovecot IMAP server that manages my Maildir
mail boxes (including the local ones.) Never has Gnus corrupted
someone's "entire mail spool" (in my sphere of responsibility)
ever since.

(But I have to agree that multiple encodings support in Emacs
has improved considerably over the last decade.)

> And I don't read comp.emacs any more, either.

--
FSF associate member #7257 np. Birdeca bird' -- Marchela Fasani

[Julian Bradfield]

On 2013-04-03, Ivan Shmakov <onei...@gmail.com> wrote:
> But then, in what I'd consider the "proper" setup, Emacs
> accesses IMAP and NNTP servers to get mail and news, and not
> some files directly. So, yes, the lack of multiple encodings
> per file support is irrelevant for the task.

But a single message may contain multiple encodings...which are
correctly dealt with by VM, for example, just as it has to deal with
multiple encodings in a mailbox file.

[Γιώργος Κεραμίδας]

Are you talking about multiple encoding in a single 'MIME part' too, or
something else though?

Each MIME part can have its own charset attribute, so Gnus, VM, or any
other email client, can recognize that this is happening and try to
recode / display the MIME part in the appropriate way.

But multiple character sets / encodings within a _single_ MIME part
sounds a bit silly.

[Shmuel Metz]

In <876201e...@kobe.laptop>, on 04/05/2013

at 11:26 AM, <kera...@ceid.upatras.gr> said:

>Are you talking about multiple encoding in a single 'MIME part' too,
>or something else though?

From RFC 2045:

An initial set of seven top-level media types is defined in RFC
2046. Five of these are discrete types whose content is
essentially opaque as far as MIME processing is concerned. The
remaining two are composite types whose contents require
additional handling by MIME processors.

In a composit entity, each body part can have a different charset.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org

[Γιώργος Κεραμίδας]

On Fri, 05 Apr 2013 09:01:45 -0400, Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> wrote:
> In <876201e...@kobe.laptop>, on 04/05/2013
> at 11:26 AM, <kera...@ceid.upatras.gr> said:
>
>>Are you talking about multiple encoding in a single 'MIME part' too,
>>or something else though?
>
> From RFC 2045:
>
> An initial set of seven top-level media types is defined in RFC
> 2046. Five of these are discrete types whose content is
> essentially opaque as far as MIME processing is concerned. The
> remaining two are composite types whose contents require
> additional handling by MIME processors.
>
> In a composit entity, each body part can have a different charset.

Exactly.

I admit I have only worked with semi-compatible encodings, like two
different parts of the same MIME message which are encoded in utf-8 and
iso-8859-7 respectively. So I am missing something here, because I have
seen Gnus running as utf-8 display both parts of such a message with the
appropriate conversion to the 'wider' encoding.

Is there any combination of MIME parts that makes Gnus barf? This is
probably a bug if it happens, and we should let the Gnus maintainers
know about it.

--
Giorgos Keramidas; gkera...@gmail.com

[Ivan Shmakov]

>>>>> Γιώργος Κεραμίδας <kera...@ceid.upatras.gr> writes:

[…]

> I admit I have only worked with semi-compatible encodings, like two
> different parts of the same MIME message which are encoded in utf-8
> and iso-8859-7 respectively. So I am missing something here, because
> I have seen Gnus running as utf-8 display both parts of such a
> message with the appropriate conversion to the 'wider' encoding.

I guess the only point to miss is that it was (AIUI) a
pop3.el-specific bug that the OP (= other poster) stumbled upon
some 10 years ago.

> Is there any combination of MIME parts that makes Gnus barf? This is
> probably a bug if it happens, and we should let the Gnus maintainers
> know about it.

FWIW, there aren't any such bug that I know in Gnus 5.13.

--
FSF associate member #7257 http://hfday.org/

[Γιώργος Κεραμίδας]

On Tue, 09 Apr 2013 20:49:29 +0000, Ivan Shmakov <onei...@gmail.com> wrote:
>Γιώργος Κεραμίδας <kera...@ceid.upatras.gr> writes:
>> I admit I have only worked with semi-compatible encodings, like two
>> different parts of the same MIME message which are encoded in utf-8
>> and iso-8859-7 respectively. So I am missing something here, because
>> I have seen Gnus running as utf-8 display both parts of such a
>> message with the appropriate conversion to the 'wider' encoding.
>
> I guess the only point to miss is that it was (AIUI) a
> pop3.el-specific bug that the OP (= other poster) stumbled upon some
> 10 years ago.

Ah, I see now. Thanks :-)

I found the original message and read it more carefully. Now, having
done a bit of reading, I understand better what the OP wrote. I haven't
used MULE with POP3 as extensively as the OP says he did, and it's a
10-year old problem that even he doesn't really want to talk about.

I was curious because I use Gnus with IMAP a /lot/ now to access, read
and compose multipart MIME messages, and it seemed like there's a
problem with the current codebase. Now, having read more, I don't think
there's a lot to worry about -- at least not until we have an indication
that there /is/ a bug and we have something to work with.

My apologies for the extra noise, until I grasped what was going on.