TODO

   1 TODO reminder for the maintainer.
   2 Before you start making additions to Heirloom mailx and S-nail,
   3 subscribe to the development mailing list at
   4 <https://lists.sourceforge.net/lists/listinfo/nail-devel>
   5 to coordinate your efforts with the maintainer and other people.
   6
   7 - [v13:started] Reformat the manual.
   8   roff style is fine, but lines should be ~64 characters, not only ~25.
   9 - IDNA.
  10 - Mail-Followup-To:.
  11 - NetBSD mailx(1) removes all recipients in up Cc: and To: that are also
  12   specified in Bcc.
  13   [Note: i plan to make this default.  Please complain.]
  14 - At least optionally disallow silent discarding of invalid addresses,
  15   i.e., cause sending to be aborted if not all recipient addresses pass the
  16   validity test.
  17   And shouldn't it generally be marked as an error and reported when the
  18   program exits?  At least in non-interactive mode??  Yet there is no
  19   indication that anything has happened at all!
  20   [Note: i plan to report error in non-interactive mode.  Please complain.]
  21 - Think about a name bypass hashmap cache, and whenever we have to skin or
  22   nalloc() or whatever, look in there.  Maybe even an additional link for
  23   non GFULL(/GSKIN) and fully skinned struct name objects.
  24   The amount of duplicated work in this codebase if frustrating, but the
  25   real healing would make necessary a complete rewrite of the name handling!
  26   Such a cache would work without touching the current code flow ... or
  27   allow a smooth transition to a new one anyway.
  28 - Deal with faulty message selection that may occur when selecting threads
  29   via & (when at least mixed with other selectors).
  30 - Try to add command line editing; problems may be signals and even
  31   more longjmp()s, and how they are used at the moment.  Check that.
  32 - Add the possibility to simply place whatever header in the editor (and
  33   in the mail read in due to the -t command line option, and...).
  34 - Make it possible to really edit mails "in place" (in that they are stored
  35   back in the MBOX and replace the original).
  36 - Check against RFC 5322.
  37   Really recheck all the header parsing code.
  38 - What about RFC 6531?
  39 - Check against newest POSIX.
  40 - Maybe add a bash(1)ish POSIXLY_CORRECT (or so) switch that can be used to
  41   disallow extensions (e.g. specification of "full" addresses on command
  42   line).
  43
  44 - Revise the code:
  45   + Add C99-likeish typedefs for integers and use them everywhere.
  46   + Don't use magic constants/values.
  47   + Document the functions in the interface declarators.
  48   + Try to thin out the onion and reduce work that is done over and over
  49     again.  Maybe introduce objects to represent header[field/body] and
  50     content and find a way to pass those all through that vegetable.
  51   + The current codebase assumes that in multibyte encodings plains ASCII
  52     characters can be tested "as-is".  This assumption is wrong for some
  53     encodings that use U+001B (escape) or another ASCII thing to introduce
  54     shift states.  The only real solution to this problem would be to
  55     rewrite the entire codebase and use wide characters (IMO) everywhere.
  56   + [v13:started] Resort the functions and where they are implemented.
  57 - The current maintainer doesn't like longjmp()s.
  58 - The current maintainer doesn't like signals.
  59 - The current maintainer would like to see that compilation with a C++
  60   compiler is possible, though that would be a long way and be especially
  61   problematic due to the (C ish) way enums are used.  He never understood
  62   why there is not "bitenum", btw.
  63 - The current maintainer worked with all-tabs for almost one and a half
  64   decade and turned over to all-spaces afterwards.
  65
  66 vim:set fenc=utf-8 syntax=txt ts=8 sts=2 sw=2 et tw=75: