TODO

   1 TODO reminder.
   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 Backward-compatibility breakers
   8 -------------------------------
   9
  10 - Recipients specified on the command line should be added to those
  11   specified in the message when the -t option is set.
  12
  13 - The -q option makes me sad as it doesn't use *indentprefix* for the
  14   quoted file.  So either there should be -Q which does so, or -q should be
  15   changed.  Also see ~R below.
  16   [Note: i think i go for the latter.  Please complain.]
  17
  18 - NetBSD mailx(1) removes all recipients in up Cc: and To: that are also
  19   specified in Bcc.  I think some kind of "yet-exists stack" as in
  20   Cc:->To:->Bcc would be a win.
  21
  22 - At least optionally disallow silent discarding of invalid addresses,
  23   i.e., cause sending to be aborted if not all recipient addresses pass the
  24   validity test.
  25
  26 - IIRC some error messages go to STDOUT, some to STDERR.  Only latter.
  27
  28 - IIRC i saw invocations that returned with a 0 exit status and that
  29   surprised me, then.  Errors should truly be reported.
  30
  31 - POSIX says that, when written to DEAD: "If the file exists, the message
  32   shall be written to replace the contents of the file".  This is mentioned
  33   for ASYNCHRONOUS EVENTS, but it's the only description of what should be
  34   done in which way to DEAD.  savedeadletter() yet appends.
  35
  36 - Furthermore, *all* file operations yet append, even recipient target
  37   files are appended.  I don't know if this is really desirable behaviour,
  38   but i have not thought about that for real.  Maybe this should be at
  39   least configurable.
  40
  41 - The current maintainer really would like to make the new
  42   *rfc822-no-body-from_* option the default, or, even better, get rid of
  43   these "pseudo From_"s that were introduced in
  44   50fef89 (* A mbox-style "From " line is now generated.., 2004-11-06).
  45
  46 - Implement true RFC 4155 MBOX parsing; since that may not work with
  47   incompatible mailboxes (any?), add an option to turn this behaviour off.
  48   (The code practically exists already for many years, almost complete..)
  49
  50 - The current maintainer hates the way the command line arguments are
  51   processed.  Because, many things that come in from the command line may
  52   depend on what the configuration files say.
  53   It would be much better to collect the command line once, then load all
  54   the configuration files that are desired, then process the command line
  55   again (that way most likely faster than creating dynamic storage for all
  56   the command line arguments).  This will enable +PATH expansions for
  57   attachments, IDNA settings for addresses etc.  Until then -Svariable sets
  58   its argument after loading of the RC files as documented, *and* directly
  59   once parsed.
  60
  61 Non-breakers
  62 ------------
  63
  64 - [v13:started] Reformat the manual.
  65   roff style is fine, but lines should be ~70 characters, not only ~25.
  66
  67 - IDNA decoding.  It may be that this will never be supported.  But
  68   wouldn't it be nice for at least viewing messages?
  69
  70 - Mail-Followup-To:.
  71
  72 - Make it possible to reply to/save/write/xy part X.Y[.Z] by allowing its
  73   specification directly, as in, e.g., ':w 1.2'.  If doing so on an
  74   embedded message/rfc822, e.g., a message embedded in a digest, it should
  75   be possible to reply to the very message in respect to its header fields,
  76   but (optionally?) keep the original Cc:'d.  (Parts by Martin Neitzel)
  77
  78 - Yet the first part is used for forwarding and replying etc..  In MIME
  79   multipart messages it is however possible to make the HTML version the
  80   first, etc., so in case the normal "pick first part" algorithm is used
  81   that should maybe do "pick first plain text part if present, else first"
  82   insteadl.
  83
  84 - I want to have a ~R tilde command that works like ~r except it performs
  85   quoting of the input just as ~m does.  Also see -q above.
  86
  87 - Offer the possibility to work with certificate fingerprints instead of
  88   full certificates, in equal spirit to the current maintainers S-Postman
  89   and Mercurial.  S-nail(1) could simply offer something in equal spirit to
  90   the formers --fingerprint, so that no other tool is necessary for
  91   certificate management (for secure transport at least).
  92
  93 - It would be nice if it would be possible to define a format string for
  94   *quote*, like 'set quote="format=some formats"'.
  95
  96 - Deal with faulty message selection that may occur when selecting threads
  97   via & (when at least mixed with other selectors).
  98
  99 - On the long run -- try to add command line editing.
 100
 101 - For those who use S-nail(1) only with a MTA it may be desirable to have
 102   some "smopts" expansion mechanism in equal spirit to NetBSD mailx(1).
 103
 104 - While talking about NetBSD mailx(1), the author can imagine that being
 105   able to use the optional -H:xy stuff is sometimes nice.
 106
 107 - Add the possibility to simply place whatever header in the editor (and
 108   in the mail read in due to the -t command line option, and...).
 109
 110 - Check against RFC 5322.
 111   Rework all the header parsing code.  Actually understand the content,
 112   classify the stuff so that it matches what is defined in RFC dependent on
 113   header field.  Place the result in objects that know what they represent.
 114   See the name extraction topic below.
 115
 116 - Also check against newest POSIX.
 117   Maybe add a bash(1)ish POSIXLY_CORRECT (or so) variable?  Though..
 118
 119 - Maybe there should be an additional ZOMBIE directive that is served in
 120   equal spirit to DEAD, but that could be a valid MBOX... ?
 121   What i want is a *real* resend, best if possible from command line.
 122   Meaning, also the possibility to postpone a message.
 123
 124 Low-Level
 125 ---------
 126
 127 - Revise the code:
 128   + Add C99-likeish typedefs for integers and use them everywhere.
 129   + Don't use magic constants/values.
 130   + [v13:started] Use const arguments whenever possible.  Yet started, but
 131     with ugly casts at some places because this is a can of worms.
 132   + Inline functions?  [Restrict pointers?]
 133   + Document the functions in the interface declarators.
 134   + [v13:started] Resort the functions and where they are implemented.
 135     It's really terrible.  Just think about outof(), savedeadletter(),
 136     savemail() etc..
 137   + Make more use of struct str, and offer more support functions for it.
 138   + Make more use of value carriers in the call stack.  There are functions
 139     with an incredible amount of arguments, needlessly.
 140   + makeconfig: link_check/compile_check.  More of the latter suffice.
 141
 142 - [v13:started] Improve name extraction rules.  And field parsing.  There
 143   are structured and unstructured fields.  There are quoted pairs and
 144   comments etc.  Rewrite the entire parsing mechanism to comply to RFC
 145   5322, and try to merge all those many subparsers around in the codebase,
 146   and accordingly.  So much duplicated work ...
 147   Name parsing has been improved a bit for v13, but it's still broken.
 148   yankword(), *extract(), etc.: RFC 5322 says that comments in address
 149   fields SHOULD NOT be used (mutt(1) maps them to full name-addr forms if
 150   approbiate, even if that actually changes content!!?), and that full
 151   name-addr SHOULD be used.  Our functions are yet quite silly (i.e.,
 152   leading comments remain, as in "(bier2) <a2@b2.de>", unless the address
 153   doesn't come in angle brackets, trailing go away, as in "<a6@b6.de>
 154   (bier6)", that becomes "<a6@b6.de>").
 155   Something silly like
 156     (co$mm1) abc@däf.de (cö,mm,2)   ('c'o"m"m.3)
 157   Should eventually become
 158     co$mm1 cö,mm,2 'c'o"m"m.3 <abc@xn--df-via.de>
 159   on the display, or, with IDNA decoding (and thus rather unlikely)
 160     co$mm1 cö,mm,2 'c'o"m"m.3 <abc@däf.de>
 161   It should NOT become this mutt(1)ism:
 162     "co$mm1 cö,mm,2 'c'omm.3" <abc@däf.de>
 163   Or?
 164
 165 - Think about a name bypass hashmap cache, and whenever we have to skin or
 166   nalloc() or whatever, look in there.  Maybe even an additional link for
 167   non GFULL(/GSKIN) and fully skinned struct name objects.
 168   The amount of duplicated work in this codebase is frustrating, but the
 169   real healing would make necessary a complete rewrite of the name handling!
 170   Such a cache would work without touching the current code flow ... or
 171   allow a smooth transition to a new one anyway.
 172
 173 - Check all Popen() calls, i've had the impressions that Popen() doesn't
 174   close all resources on failure.  Also, Popen() callers often do a lot of
 175   work in respect to signals.  Try to find a solution that all problems are
 176   encapsulaten in Popen(), at least better than today.
 177
 178 - is_myname() shows it, others too - there are variables which are
 179   interpreted, and those should be interpreted once they are assigned, not
 180   over and over again.  Even better: lazy evalution -- use a special lookup
 181   method for those.  The mentioned method should indeed even go away?
 182
 183 - mime.c:prefixwrite() tracks state internally instead of having a cookie
 184   argument.  That doesn't really make sense.  Either it is capable to work
 185   with multiple files concurrently and prefix-quotes them correctly in the
 186   same fashion, or it doesn't track anything at all.  It even tracked those
 187   calls that do not write a prefix at all before, just to make this
 188   mechanism work ... Or not?  Well, if you track the last file and if there
 189   was a newline last, and you switch files, then the last newline state is
 190   lost, and you do write the prefix even if in the other file there was no
 191   newline last.  I'm confused now.  Change this, please.
 192
 193 - The current codebase assumes that in multibyte encodings plain ASCII
 194   characters can be tested "as-is".  This assumption is wrong for some
 195   encodings that use U+001B (escape) or another ASCII thing to introduce
 196   shift states.  The only real solution to this problem would be to rewrite
 197   the entire codebase and use wide characters (IMO) everywhere.
 198   (Really.  For at least header content.)
 199
 200 - The current maintainer doesn't like longjmp()s.
 201
 202 - The current maintainer doesn't like signals.
 203
 204 - The current maintainer would like to see that compilation with a C++
 205   compiler is possible, though that would be a long way and be especially
 206   problematic due to the (C ish) way enums are used.  He never understood
 207   why there is not "bitenum", btw.
 208
 209 - The current maintainer worked with all-tabs for almost one and a half
 210   decade and turned over to all-spaces afterwards.
 211
 212 Release S-nail v20 on 2018-03-25, the 40th anniversary of Mail.
 213 With a clean, conforming and efficient codebase, then.
 214
 215 vim:set fenc=utf-8 syntax=txt ts=8 sts=2 sw=2 et tw=75: