jcs.org
mutt stable branch with some hacks
1Problems are listed in approximate order of priority.
2
3- When displaying MIME headers, rfc 2047 decoding is applied (which
4 should not happen), and rfc 2231 decoding is not applied (which
5 should happen).
6
7- Help formatting could be revamped a bit.
8
9- In the "attachment" menu, assume this:
10
11 1 [text/plain, 7bit, 1.1K] <no description>
12 2 [message/rfc822, 7bit, 6.1K] A test message
13 3 [text/plain, 7bit, 0.1K] |-><no description>
14 4 [message/rfc822, base64, 2.5K] |-><no description>
15 5 [message/rfc822, base64, 2.7K] `-><no description>
16
17 (please note the "message/rfc822" attachments encoded as
18 Base64; that's illegal, but Sun's Mailtool sends that
19 kind of messages); then go to, say, attachment "4",
20 delete it, and go to the main menu; you won't be able to
21 quit the mailbox (ok, 'x' works, but 'q' doesn't).
22
23 The problem here lies in the fact that mutt uses mailbox
24 handling functions to access message/rfc822 type
25 attachments. We'd need to perform an additional
26 decoding step before using these functions to fix this
27 bug.
28
29 Please note that mutt's just assuming RFC-compliant mail
30 here. Fixing this stuff may become a PITA.
31
32
33
34
35- BODY struct should probably have a pointer to its
36 corresponding HEADER struct. this is needed for
37 mh/maildir mailboxes so the correct pathname can be
38 found. Or perhaps all we need is a .hdr member of the
39 STATE struct so that all of the MIME handlers can look
40 up the corresponding HEADERs if need be?
41
42- handle message/external-body in some fashion
43
44- handle message/partial reconstruction
45
46- make patterns generic (I have patches for this -tlr), and
47 introduce generic menu limiting, menu pattern searching, and the
48 like.
49
50 Note: This still requires some thought, since we'd have to store
51 per-entry data in the menu structure. As an alternative, we could
52 extend the tag method to do something to more general flags. The
53 latter approach would make the implementation of proper
54 tag-prefix behaviour more simple: Functions should only be applied
55 when a message is tagged and visible. Additionally, we must not
56 access a menu's max field directly any more: Adding an entry to a
57 menu will require re-allocating and possibly updating the v2r
58 array. How do we handle "in-the-middle additions" properly? Do
59 they happen at all?