TODO

   1 Problems are listed in approximate order of priority.
   2
   3 - When displaying MIME headers, rfc 2047 decoding is applied (which
   4   should not happen), and rfc 2231 decoding is not applied (which
   5   should happen).
   6
   7 - Help formatting could be revamped a bit.
   8
   9 - In the "attachment" menu, assume this:
  10
  11         1 [text/plain, 7bit, 1.1K]           <no description>
  12         2 [message/rfc822, 7bit, 6.1K]       A test message
  13         3 [text/plain, 7bit, 0.1K]           |-><no description>
  14         4 [message/rfc822, base64, 2.5K]     |-><no description>
  15         5 [message/rfc822, base64, 2.7K]     `-><no description>
  16
  17   (please note the "message/rfc822" attachments encoded as
  18   Base64; that's illegal, but Sun's Mailtool sends that
  19   kind of messages); then go to, say, attachment "4",
  20   delete it, and go to the main menu; you won't be able to
  21   quit the mailbox (ok, 'x' works, but 'q' doesn't).
  22
  23   The problem here lies in the fact that mutt uses mailbox
  24   handling functions to access message/rfc822 type
  25   attachments.  We'd need to perform an additional
  26   decoding step before using these functions to fix this
  27   bug.
  28
  29   Please note that mutt's just assuming RFC-compliant mail
  30   here.  Fixing this stuff may become a PITA.
  31
  32
  33
  34
  35 - BODY struct should probably have a pointer to its
  36   corresponding HEADER struct.  this is needed for
  37   mh/maildir mailboxes so the correct pathname can be
  38   found.  Or perhaps all we need is a .hdr member of the
  39   STATE struct so that all of the MIME handlers can look
  40   up the corresponding HEADERs if need be?
  41
  42 - handle message/external-body in some fashion
  43
  44 - handle message/partial reconstruction
  45
  46 - make patterns generic (I have patches for this -tlr), and
  47   introduce generic menu limiting, menu pattern searching, and the
  48   like.
  49
  50   Note: This still requires some thought, since we'd have to store
  51   per-entry data in the menu structure.  As an alternative, we could
  52   extend the tag method to do something to more general flags. The
  53   latter approach would make the implementation of propper
  54   tag-prefix behaviour more simple: Functions should only be applied
  55   when a message is tagged and visible.  Additionally, we must not
  56   access a menu's max field directly any more: Adding an entry to a
  57   menu will require re-allocating and possibly updating the v2r
  58   array.  How do we handle "in-the-middle additions" properly?  Do
  59   they happen at all?