emacs-devel
[Top][All Lists]
Advanced

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

Re: Rmail changes for Emacs 22


From: Paul Michael Reilly
Subject: Re: Rmail changes for Emacs 22
Date: Wed, 23 Oct 2002 05:57:07 -0400

 > From address@hidden  Wed Oct 23 03:12:21 2002
 > Reply-to: address@hidden
 > X-BABYL-V6-ATTRIBUTES: -------
 > 
 >     I said it should never *en*code.  Obviously, it will have to decode
 >     somewhere on the way between the mbox file and the display.
 > 
 > The question at hand is when and how to do the decoding.

I'm not sure that it is totally obvious, but AFAICS there are TWO
distinct coding system issues.  First is the message based decoding
that everyone seems to recognize that is necessary to view messages.
Second is the coding system used for mail file/buffer.  They are
mostly orthogonal.

The mail buffer coding system will be dynamic.  It should mostly be
iso-latin1 according to mail rfcs but Users will tend to abuse the
specs so Rmail needs to be robust enough to handle that abuse.  How
exactly remains to be decided.  Editing of messages is discussed
below.

As messages in the mail file are viewed, the buffer coding system will
very likely change, at least in the narrowed region viewing the
message.

My gut feel is that the use of special view buffers (apart from the
mail file buffer) will be necessary in certain cases (yet to be
determined) as we integrate MIME and IMAP for first class (default)
treatment.  I strongly agree with Richard that separate view buffers
are to be avoided like the plague.  If memory serves, VM uses special
viewing buffers on a limited basis.

Editing of messages opens up a huge can of worms wrt coding system.
If anyone can state a sensible and effective policy for dealing with
coding system conflicts while editing messages, more power to 'em.
I'm listening.  It is easy to foresee Users changing message headers
and bodies in ways that would render a message unmailable and/or
unviewable in another mail agent but are nevertheless doable within
Emacs.

FWIW, I fully support the notion of a front-end / multiple back-end
design and have already started on it.  Any opinions on a good model
in the current code base?  I've looked at Gnus in the past and found
it very, very complex.  VC is straightforward and Richard has
mentioned compose-mail.

-pmr




reply via email to

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