Re: Emacs 22 branch created.

[Richard Stallman]

    The non-decoded part of the buffer should be in unibyte mode.

Why does it have to be in unibyte mode?
Decoding can be done in a multibyte buffer.

    And of course very inefficient when you'll constantly be editing a very
    large rmail buffer.

Not really, because the gap makes such operations efficient.

    > 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.

The other approach also needs peculiar changes in lower-level features
to work right.  Various operations on the message buffer would have to
operate on the file buffer as well.  These include set-buffer-file-name,
rename-buffer, as well as saving.

    - 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.

This has no effect on the validity of this optimization.
Rmail does not handle attachments now.

We might want to implement support for displaying attachments, but if
we display them in separate buffers, the optimization won't interfere.

If we wanted to make Rmail decode text attachments in the same buffer,
that too can work easily enough together with this optimization.

So I think there is no difficulty, really.