59 lines
2.3 KiB
Text
59 lines
2.3 KiB
Text
Problems are listed in approximate order of priority.
|
|
|
|
- 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.
|
|
|
|
- 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?
|
|
|
|
- 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 proper
|
|
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?
|