main.c: set -S twice! And about command line processing..
[s-mailx.git] / TODO
blob0915686bc95b8c253ba76549fe064ab0b4e0e358
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.
7 Backward-compatibility breakers
8 -------------------------------
10 - Recipients specified on the command line should be added to those
11   specified in the message when the -t option is set.
12 - The -q option makes me sad as it doesn't use *indentprefix* for the
13   quoted file.  So either there should be -Q which does so, or -q should be
14   changed.  Also see ~R below.
15   [Note: i think i go for the latter.  Please complain.]
16 - NetBSD mailx(1) removes all recipients in up Cc: and To: that are also
17   specified in Bcc.  I think some kind of "yet-exists stack" as in
18   Cc:->To:->Bcc would be a win.
19 - At least optionally disallow silent discarding of invalid addresses,
20   i.e., cause sending to be aborted if not all recipient addresses pass the
21   validity test.
22 - IIRC some error messages go to STDOUT, some to STDERR.  Only latter.
23 - IIRC i saw invocations that returned with a 0 exit status and that
24   surprised me, then.  Errors should truly be reported.
25 - POSIX says that, when written to DEAD: "If the file exists, the message
26   shall be written to replace the contents of the file".  This is mentioned
27   for ASYNCHRONOUS EVENTS, but it's the only description of what should be
28   done in which way to DEAD.  savedeadletter() yet appends.
29 - Furthermore, *all* file operations yet append, even recipient target
30   files are appended.  I don't know if this is really desirable behaviour,
31   but i have not thought about that for real.  Maybe this should be at
32   least configurable.
33 - The current maintainer really would like to make the new
34   *rfc822-no-body-from_* option the default, or, even better, get rid of
35   these "pseudo From_"s that were introduced in
36   50fef89 (* A mbox-style "From " line is now generated.., 2004-11-06).
37 - Implement true RFC 4155 MBOX parsing; since that may not work with
38   incompatible mailboxes (any?), add an option to turn this behaviour off.
39   (The code practically exists already for many years, almost complete..)
40 - The current maintainer hates the way the command line arguments are
41   processed.  Because, many things that come in from the command line may
42   depend on what the configuration files say.
43   It would be much better to collect the command line once, then load all
44   the configuration files that are desired, then process the command line
45   again (that way most likely faster than creating dynamic storage for all
46   the command line arguments).  This will enable +PATH expansions for
47   attachments, IDNA settings for addresses etc.  Until then -Svariable sets
48   its argument after loading of the RC files as documented, *and* directly
49   once parsed.
51 Non-breakers
52 ------------
54 - [v13:started] Reformat the manual.
55   roff style is fine, but lines should be ~70 characters, not only ~25.
56 - IDNA decoding.  It may be that this will never be supported.  But
57   wouldn't it be nice for at least viewing messages?
58 - Mail-Followup-To:.
59 - Make it possible to reply to/save/write/xy part X.Y[.Z] by allowing its
60   specification directly, as in, e.g., ':w 1.2'.  If doing so on an
61   embedded message/rfc822, e.g., a message embedded in a digest, it should
62   be possible to reply to the very message in respect to its header fields,
63   but (optionally?) keep the original Cc:'d.  (Parts by Martin Neitzel)
64 - Yet the first part is used for forwarding and replying etc..  In MIME
65   multipart messages it is however possible to make the HTML version the
66   first, etc., so in case the normal "pick first part" algorithm is used
67   that should maybe do "pick first plain text part if present, else first"
68   insteadl.
69 - I want to have a ~R tilde command that works like ~r except it performs
70   quoting of the input just as ~m does.  Also see -q above.
71 - Offer the possibility to work with certificate fingerprints instead of
72   full certificates, in equal spirit to the current maintainers S-Postman
73   and Mercurial.  S-nail(1) could simply offer something in equal spirit to
74   the formers --fingerprint, so that no other tool is necessary for
75   certificate management (for secure transport at least).
76 - It would be nice if it would be possible to define a format string for
77   *quote*, like 'set quote="format=some formats"'.
78 - Deal with faulty message selection that may occur when selecting threads
79   via & (when at least mixed with other selectors).
80 - On the long run -- try to add command line editing.
81 - For those who use S-nail(1) only with a MTA it may be desirable to have
82   some "smopts" expansion mechanism in equal spirit to NetBSD mailx(1).
83 - While talking about NetBSD mailx(1), the author can imagine that being
84   able to use the optional -H:xy stuff is sometimes nice.
85 - Add the possibility to simply place whatever header in the editor (and
86   in the mail read in due to the -t command line option, and...).
87 - Check against RFC 5322.
88   Rework all the header parsing code.  Actually understand the content,
89   classify the stuff so that it matches what is defined in RFC dependent on
90   header field.  Place the result in objects that know what they represent.
91 - Check against newest POSIX.
92 - Maybe add a bash(1)ish POSIXLY_CORRECT (or so) switch that can be used to
93   disallow extensions (e.g. specification of "full" addresses on command
94   line).
95 - Maybe there should be an additional ZOMBIE directive that is served in
96   equal spirit to DEAD, but that could be a valid MBOX... ?
97   What i want is a *real* resend, best if possible from command line.
98   Meaning, also the possibility to postpone a message.
100 Low-Level
101 ---------
103 - Revise the code:
104   + Add C99-likeish typedefs for integers and use them everywhere.
105   + Don't use magic constants/values.
106   + Try to thin out the onion and reduce work that is done over and over
107     again.  Maybe introduce objects to represent header[field/body] and
108     content and find a way to pass those all through that vegetable.
109   + The current codebase assumes that in multibyte encodings plains ASCII
110     characters can be tested "as-is".  This assumption is wrong for some
111     encodings that use U+001B (escape) or another ASCII thing to introduce
112     shift states.  The only real solution to this problem would be to
113     rewrite the entire codebase and use wide characters (IMO) everywhere.
114   + Document the functions in the interface declarators.
115   + [v13:started] Resort the functions and where they are implemented.
116     It's really terrible.  Just think about outof(), savedeadletter(),
117     savemail() etc..
118   + Make more use of struct str, and offer more support functions for it.
119   + Make more use of value carriers in the call stack.  There are functions
120     with an incredible amount of arguments, needlessly.
121   + makeconfig: link_check/compile_check.  More of the latter suffice.
122 - Check all Popen() calls, i've had the impressions that Popen() doesn't
123   close all resources on failure.  Also, Popen() callers often do a lot of
124   work in respect to signals.  Try to find a solution that all problems are
125   encapsulaten in Popen(), at least better than today.
126 - Think about a name bypass hashmap cache, and whenever we have to skin or
127   nalloc() or whatever, look in there.  Maybe even an additional link for
128   non GFULL(/GSKIN) and fully skinned struct name objects.
129   The amount of duplicated work in this codebase if frustrating, but the
130   real healing would make necessary a complete rewrite of the name handling!
131   Such a cache would work without touching the current code flow ... or
132   allow a smooth transition to a new one anyway.
133 - mime.c:prefixwrite() tracks state internally instead of having a cookie
134   argument.  That doesn't really make sense.  Either it is capable to work
135   with multiple files concurrently and prefix-quotes them correctly in the
136   same fashion, or it doesn't track anything at all.  It even tracked those
137   calls that do not write a prefix at all before, just to make this
138   mechanism work ... Or not?  Well, if you track the last file and if there
139   was a newline last, and you switch files, then the last newline state is
140   lost, and you do write the prefix even if in the other file there was no
141   newline last.  I'm confused now.  Change this, please.
142 - The current maintainer doesn't like longjmp()s.
143 - The current maintainer doesn't like signals.
144 - The current maintainer would like to see that compilation with a C++
145   compiler is possible, though that would be a long way and be especially
146   problematic due to the (C ish) way enums are used.  He never understood
147   why there is not "bitenum", btw.
148 - The current maintainer worked with all-tabs for almost one and a half
149   decade and turned over to all-spaces afterwards.
151 vim:set fenc=utf-8 syntax=txt ts=8 sts=2 sw=2 et tw=75: