Repository cleanse.

[apps/madmutt.git] / legacy / TODO

diff --git a/legacy/TODO b/legacy/TODO
new file mode 100644 (file)
index 0000000..809c90f
--- /dev/null
+++ b/legacy/TODO
@@ -0,0 +1,66 @@
+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 $