Dear Jan,
Thanks for your reply
[…] this is more complex. MIME, a standard
which defines how e-mail boddies look like, is quite complex. In
short, an e-mail might be an arbitrarily nested tree-like
structure. Trojita can reasonably easily parse all of that, and
also render and display that in the regular message viewer. When
it comes to editting or creating new e-mails, then it's a
different thing.
I hadn't worried about MIME too much, because my aim was to do this at the
same level of sophistication that replies are handled: whatever Trojitá now
quotes, put that in the editor (prefixed with a forwarding header as
needed); the rest goes along as attachments. But of course this becomes
more complex if we want to make full use of IMAP efficiency features, I
guess.
Right now, the composer only supports creating messages with a
single plaintext "main" part, and possibly some attachments.
I think that is enough for what I had in mind.
However, this would have to change, somehow, if we start
allowing edits of arbitrary e-mail messages. Take a look at the
MIME torture test by MArk Crispin [1], for example. How should
the composer look like after opening something like *that*?
[1] http://gd.tuwien.ac.at/infosys/mail/imap/mime-examples/torture-test.mbox
Well, that mail is easy: the (first) text/plain part in the editor and the
other parts as attachments. Currently, replying to that message, Trojitá
doesn't do what I would expect, i.e., just cite that first text/plain part;
it throws all parts it thinks are text into the editor (also Postscript, I
guess because it is in some way text-based). KMail does what I expect (and
think is the right approach) for replying, forwarding, and editing as new.
Throwing out the other parts of a multipart/alternative of which a
text/plain part is taken as the material to be put in the editor might be
another complicating factor.
We could probably define some thresholds, such as only allowing
edits of "supported" MIME tree shapes. That's doable, but it's
some work, and that work should -- IMHO -- start with describing
how the whole thing should behave.
Ok. First thing: how is it decided what is currently put into the body of a
reply?
Do we want to use the same material for the body of ‘Edit as new’ and
‘Forward inline’? Does that mean we first need to ‘fix’ what is taken as
the reply body?
As for what I would expect as behavior (read ‘consider’ recursively):
* text/plain message: use its body, success!
* multipart/related: consider root part (or first if we can't determine the
root part)
* multipart/alternative: iteratively consider parts from last to first
(stop with success, of course)
* multipart/encrypted: consider unencrypted part
* multipart/mixed|report|signed: consider first part
* multipart/digest or still other: failure, so empty body, throw everything
in attachment if forwarding or editing as new.
Is that doable? I guess we can request (the relevant part of) the MIME tree
from the IMAP server. (The MIME tree ‘debugging’ tool seems to work very
well.)
Best,
Erik
