emacs-devel
[Top][All Lists]
Advanced

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

Re: Rmail-mbox branch


From: Stephen J. Turnbull
Subject: Re: Rmail-mbox branch
Date: Wed, 10 Sep 2008 18:10:54 +0900

Richard M. Stallman writes:
 >      > How do you reach that conclusion for text/html?
 > 
 >     I explained that already.
 > 
 > You didn't really try to explain, only to vent contempt.

Wrong on both counts.  You seem to think I was addressing my posts
only to you, but in fact I *succeeded* in explaining (as evidenced by
offline thanks I have received) to others.  The fact that that did not
succeed for you, and further attempts to explain for your personal
benefit met with no help from you, was frustrating.  I admit that.

Especially frustrating since in fact *you* are the most prominent
beneficiary of a better Rmail; most of the world has long since moved
on to more capable MUAs, and has no need of improvements in Rmail.

I do not appreciate your attempt to blame me for your lack of effort
in communicating.  You have your reasons for terseness, I'm aware, but
that is no excuse for this rudeness.

 > Someone else did really explain, which I appreciate.

If you are referring to David de la Harpe's explanation of why
text/html is not "plain ASCII", you are still missing the main point
(though his post was a complete and useful explanation of the
subsidiary point it addresses).

I do not appreciate you putting me down by calling that a "real
explanation" in this context.

You see, "charset=us-ascii" doesn't really matter here.  As I pointed
out to Francesco, there's no reason at all not to transcode body text
to UTF-8, and as I pointed out to Stefan, for many users it would be
very convenient and would cause no harm to transcode the headers too.
(I suspect that *you* are one user who would greatly benefit from that
feature, which will be easy to implement, and I had you in mind when I
exerted the effort to propose it to Stefan.)

The main point, on the other hand, is that for Rmail to be generally
useful and interoperable these days, it needs to support non-text
objects, at least to the extent of not harming them.  The straight-
forward way to avoid loss of information is simply to store messages
containing such objects in their "straight from the wire" form in an
mbox-format file, and decode the parts that Rmail supports for
presentation every time the message is presented.





reply via email to

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