X-Git-Url: http://git.madism.org/?a=blobdiff_plain;f=legacy%2FTODO;fp=legacy%2FTODO;h=809c90ff6e2694700f7abb388032649e81c90ec0;hb=3ad8157bbbc6b9fae1c3252aad1c07fcccd92004;hp=0000000000000000000000000000000000000000;hpb=2fea7732a573b94a4d5dcf7e641ef067472e9cab;p=apps%2Fmadmutt.git

diff --git a/legacy/TODO b/legacy/TODO
new file mode 100644
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 $