emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rmail-mbox branch


From: Evil Boris
Subject: Re: Rmail-mbox branch
Date: Mon, 01 Sep 2008 19:46:46 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (windows-nt)

Eli Zaretskii <address@hidden> writes:

>> From: Evil Boris <address@hidden>
>> Date: Mon, 01 Sep 2008 07:46:23 -0400
>> 
> I don't see why the mbox branch would support this any worse than the
> trunk.  The decoding stuff is pretty much stable and well understood,
> after so many releases.

I was trying to dig up where I found something that made me suspect the
abitility of Rmail-mbox to deal with non-ASCII, and after much digging
through archives found the following:

>From: Henrik Enberg <henrik.enberg <at> telia.com>
>Subject: Re: status of the rmail-mbox branch?
>Newsgroups: gmane.emacs.devel
>Date: 2007-03-06 14:01:27 GMT (1 year, 25 weeks, 5 days, 3 hours and 36 
>minutes ago)
>
> Francesco Potorti` <pot <at> gnu.org> writes:
> > What is the current status of the rmail-mbox branch?
> > 
> > Does it have the same functionalities as the regular rmail?
>
> Not entirely.  It is certainly possible to use it to read email, but is
> has some deficencies in the area of coding-systems.  It currently
> doesn't do any decoding from raw-text at all.  The main problem is that
> if we want interoperability with other tools (which I guess is the main
> reason to switch to the mbox format), we can't really encode the
> mailboxes with emacs-mule anymore as is done with BABYL boxes.

It may not be relevant now.

>> PS. Reading a multipart/alternative email with a text/plain component
>> encoded in quoted-printable [in a non-latin-based character set] or
>> base64 is currently a pain, as I have to detach and then play around
>> with decoding the character set in the raw RMAIL file...
>
> ??? For me, it's as easy as
>
>   . Type 'e' to make the message editable
>
>   . Make region around the attachment
>
>     . For base64-encoded attachments:
>
>         M-x base64-decode-region RET
>
>     . For quoted-printable: 
>
>         M-: (mail-unquote-printable-region (mark) (point) nil nil t) RET
>
>   . C-c (to exit rmail-edit)
>
>   . M-x rmail-redecode-body RET CHARSET-NAME RET
>
> where CHARSET-NAME is whatever appears in the charset= header of the
> attachment, if different from US-ASCII.
>
> (Of course, the above are just the primitives; wrapping them with a
> single command is left as an exercise for the interested readers.)

I have been doing this on and off (mostly by hand) and have occasionally
gotten completely incomprehensible gibberish, and a time or two an RMAIL
file that RMAIL would not recognize.  Sorry, no examples lying around
[on a slightly different topic, my RMAIL file is filled with non-ASCII
msgs that used to be perfectly legible and now do not display properly.
I guess this is what happens when one uses cutting edge CVS version, and
cannot affort to do a full "make bootstrap" on every update...
separate story.]

But there is a more general problem with this:  I do not like losing
data or making irreversible changes.  If the said msg contained another
alternative (say, HTML) that I later would discover contained some
information I needed, I am not sure how easy it would be to get it
back.  Maybe I am just being paranoid.

--Boris





reply via email to

[Prev in Thread] Current Thread [Next in Thread]