-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?
-
-- 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: TODO,v 3.1 2005/02/12 19:29:52 roessler Exp $
projects / apps / madmutt.git / blobdiff