Re: Emacs 22 branch created.

[Stefan Monnier]

> A new idea just occurred to me.  Moving to a message could copy that
> message in the buffer, decode the copy, and display that copy using
> narrowing instead of the original message.  If you edit the message,
> exiting the editing mode will reencode it and put that in place
> of the original message.

The non-decoded part of the buffer should be in unibyte mode.
The decoded part of the buffer has to be in multibyte mode.
I.e. it'll get ugly.
And of course very inefficient when you'll constantly be editing a very
large rmail buffer.

> We could have a new feature to omit part of the buffer when saving the
> file.  Rmail could use it so that this copy is not saved.  This
> feature should not affect auto-saving.

If you need such a low-level hack, I think it's a good indication that
you're headed for a bad solution.

> As an optimization, if there are attachments, don't copy them.  Just
> copy and decode the main text of the message.  (Attachments don't need
> character set decoding, since they are in ASCII.)  Put the copy after
> the original, and the attachments will effecvtively become part of it.

> Does anyone see a flaw in this?

See above.  Some more flaws:
- you assume that a MIME message has only one "main text".  It may have
  several, with "inlined attachments" in-between (e.g. images).  Some of the
  attachments may contain text which you may want to display as well.
  All solvable of course, just an indication that your optimization will
  work less often and will be a potential source of more bugs.
- you will not be able to reuse the Gnus code.  I.e. you'll end up
  reinventing the wheel yet again once more.

In any case, I don't use Rmail, don't intend to, and don't intend to work
on its code either, so do as you please.  


        Stefan