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