X-Git-Url: http://git.madism.org/?p=apps%2Fmadmutt.git;a=blobdiff_plain;f=TODO;fp=TODO;h=0000000000000000000000000000000000000000;hp=809c90ff6e2694700f7abb388032649e81c90ec0;hb=3ad8157bbbc6b9fae1c3252aad1c07fcccd92004;hpb=2fea7732a573b94a4d5dcf7e641ef067472e9cab diff --git a/TODO b/TODO deleted file mode 100644 index 809c90f..0000000 --- a/TODO +++ /dev/null @@ -1,66 +0,0 @@ -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] - 2 [message/rfc822, 7bit, 6.1K] A test message - 3 [text/plain, 7bit, 0.1K] |-> - 4 [message/rfc822, base64, 2.5K] |-> - 5 [message/rfc822, base64, 2.7K] `-> - - (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 $