NYD: maildir.c
[s-mailx.git] / TODO
blobe6141c8d8f7701c9f8f5b4efa96ff3700e448a0d
1 TODO reminder.
3 Release S-nail v20 on 2018-03-25, the 40th anniversary of Mail.
4 With a clean, conforming and efficient codebase, then.
6 Backward-compatibility breakers
7 -------------------------------
9 - Recipients specified on the command line should be added to those
10   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.]
17 - At least optionally disallow silent discarding of invalid addresses,
18   i.e., cause sending to be aborted if not all recipient addresses pass the
19   validity test.
21 - Ditto if a resource file can't be found that has been explicitly set via
22   environment variables there should be some feedback.
24 - I.e., it is fine to be silent unless an error occurs, but then please
25   report errors and offer (in interactive mode) the possibility to act at
26   a glance.
28 -- While there.  There should be some kind of "verbose" switch that - in
29    interactive mode - also gives *positive* feedback, as in "added
30    attachment X, charset Y", but without giving details about protocol
31    delivery etc.
33    [It is terrible that there is almost no feedback in the UI.  When
34    i temporarily implemented a sorted cmdtab i've often used wrong commands,
35    but got no feedback at all!  E.g., wanted to "undelete 14", first did "u
36    14", then "und 14" and then realized my fault and did "undelete 14".
37    *Nothing*.]
39 - POSIX says that, when written to DEAD: "If the file exists, the message
40   shall be written to replace the contents of the file".  This is mentioned
41   for ASYNCHRONOUS EVENTS, but it's the only description of what should be
42   done in which way to DEAD.  savedeadletter() yet appends.  See ZOMBIE ,)
44 - Furthermore, *all* file operations yet append, even recipient target
45   files are appended.  I don't know if this is really desirable behaviour,
46   but i have not thought about that for real.  Maybe this should be at
47   least configurable.
49 - Maybe we should not use pipes to pagers at all.
50   This would also (beside getting rid of longjumps that cross allocations
51   afaik etc.) make it possible to honour the *crt* variable in respect
52   to what really is displayed, not in respect to message size.
53   It irritates me that a message with 5 visible lines but 115 header lines
54   goes through the pager, even if i have *crt=*.
55   P.S.: we could simply count the headers in addition?
57 - The IMAP cache is file-based, which is quite nice, since a filesystem
58   is a database.  On the other hand it may be better if we could hook
59   into sqlite3, which is available almost everywhere by default, with
60   a clearly documented DB content (so that users can use sqlite3(1) to
61   dig into it).  (And just in case S-nail will ever be able to read news
62   and/or have MTA functionality.)
63   One question would be wether compression should be applied.
65 - We should possibly get away of using command line utilities for
66   compression.  (At least optionally?)  Instead we should link against
67   zlib(3), bz2lib(3) and lzma(3), if found.  Or we may use dlopen(3)
68   instead, if found, to avoid linking (though those libraries don't need
69   much linker work unless actually used afaik, 'should look in detail).
70   We should also drop lzw.c, it is used for the IMAP cache.
72 - We should maybe turn -~ into the meaning "force interactive".
73   We should extend cc-test.sh, then, to test some interactive things.
75 Non-breakers
76 ------------
78 - We need a "void" box that can be jumped to, i.e., a state in which no box
79   at all is active.
81   (schdir(): realpath() local files before leaving CWD.., 2013-01-08)
82   did a first step to avoid "getting stuck" when the current folder becomes
83   unaccessible.
84   That is however only a command-specific workaround for a deeper design
85   problem.
87 -- When a MBOX mailbox is removed while it is opened then changing the
88   folder is not possible.  (At least when the only mail that was present
89   therein has been "move"d off that MBOX.)  While trying this i got
90   a deallocation abort trap in lex.c:commands():385:
91         if (linebuf)
92                 free(linebuf);
93   Note that Berkeley Mail (NetBSD mail(1) that is) seems to have the same
94   problem in respect to not allowing a hard-change, but only allows an exit
95   (not a quit thus).  The error may still exist even there, it maybe that
96   it simply doesn't show up because a stack buffer is used ...
98   In interactive mode, dump the temporary file to the TMPDIR and inform the
99   user; it's up to him to decide what should happen.
101   Otherwise it must be possible to switch the folder (to the *void* one)
102   forcefully.
104 -- Also, when the folder is modified concurrently we should bail, or, in an
105   interactive session, prompt the user what to do.
107 - IDNA decoding.  It may be that this will never be supported.  But
108   wouldn't it be nice for at least viewing messages?
110 - Mail-Followup-To:.
112 - Make it possible to reply to/save/write/xy part X.Y[.Z] by allowing its
113   specification directly, as in, e.g., ':w 1.2'.  If doing so on an
114   embedded message/rfc822, e.g., a message embedded in a digest, it should
115   be possible to reply to the very message in respect to its header fields,
116   but (optionally?) keep the original Cc:'d.  (Parts by Martin Neitzel)
118 - mutt(1) quotes all text parts of a message, not only the first one!
119   This should at least be optionally available.
121 - If pipes fail for part viewers then at least the usual PART X.Y should be
122   shown, maybe even including some error message.
123   I had 'set pipe-text/html="lynx -dump -force_html /dev/stdin"' but NetBSD
124   does not have lynx(1), and i thought i've found a S-nail(1) bug.
125   And so it was.
127 - I want to have a ~R tilde command that works like ~r except it performs
128   quoting of the input just as ~m does.  Also see -q above.
130 - Offer the possibility to work with certificate fingerprints instead of
131   full certificates, in equal spirit to the current maintainers S-Postman
132   and Mercurial.  S-nail(1) could simply offer something in equal spirit to
133   the formers --fingerprint, so that no other tool is necessary for
134   certificate management (for at least secure transport).
136 - It would be nice if it would be possible to define a format string for
137   *quote*, like 'set quote="format=some formats"'.
138   In general the current approach is somewhat messy IMO.  I.e., it would
139   make more sense to act rather like mutt(1) and as written elsewhere in
140   this document, i.e., have some toggles that act on the display and use it
141   for multiple modes (show/reply/forward etc.)
142   Otherwise introduce commands which include all the headers plus, e.g.,
143   "hreply" or "freply", and then the ditto series, i.e., "hReply" ...
145 -- This would also mean that interactive message editing would work
146   accordingly.  PleasE!
148 - Command line editing should gain possibility of context sensitive tab
149   completion.
151 -- Note that the TTY is sick.  If ^C on input it simply jumps to next
152    input, instead of saying "Interrupted, one more to die hard" or
153    something (talking about ~@ charset selection prompts in particular).
155 - For those who use S-nail(1) only with a MTA it may be desirable to have
156   some "smopts" expansion mechanism in equal spirit to NetBSD mailx(1).
158 - While talking about NetBSD mailx(1), the author can imagine that being
159   able to use the optional -H:xy stuff is sometimes nice.
161 - Check against RFC 5322.
162   Rework all the header parsing code.  Actually understand the content,
163   classify the stuff so that it matches what is defined in RFC dependent on
164   header field.  Place the result in objects that know what they represent.
165   See the name extraction topic below.
167 - Maybe there should be an additional ZOMBIE directive that is served in
168   equal spirit to DEAD, but that could be a valid MBOX... ?
169   What i want is a *real* resend, best if possible from command line.
170   Meaning, also the possibility to postpone a message.  In general.
172 - POP3 doesn't support "newmail" for real.  If implemented, should it sync?
173   Look at POP3 impl. in general..
175 - Having a newsreader would be a really cool thing.  (RFC 977 and 2980)
177 - There should be a way to ignore the From_ line, as opposed to the From:
178   line, i.e., distinctively.
180 - There should be a variable that controls wether leading and trailing
181   empty lines of parts and/or messages as such should be printed or not.
183 - RFC 2387: multipart/related.
185 - rfc2384.txt etc.  I.e., Much better URL support.
187 - printhead()/hprf(): support %n newline format (%t tab?).
188   Make it possible to use the *datefield* algorithm for plain From_ derived
189   dates (needs a From_ parser, i.e., strptime()-alike).
190   Once we have that, rename *datefield-markout-older* to
191   *date-markout-older* ??
192   Note that NetBSD's mail(1) has some other nice things.
193   Note also that our code is quite unflexible.
195 -- NetBSD's mail(1) has nice *indentprefix* and *indentpostscript*
196    variables (though prefix and appendix or prefix and suffix, but..).
197    Note that our code is quite unflexible.
199 - The "top" command should honour ignoretab, or there should be a very
200   special "top" ignoretab.  It simply doesn't make sense to "top" 5 lines
201   when all that you get are Received: lines...
203 - In the very end it is not that hard to add (optional) MTA
204   functionality at a most simple level.
205   Use sqlite for aliases (and possibly cache), then.
207 - We should support IMAP compression over the wire.
209 Low-Level
210 ---------
212 - Ftemp(): offer an operation mode enum that includes "do-unlink".
213   In general: now there is O_CLOEXEC etc. ...
215 - [v13:started] Improve name extraction rules.  And field parsing.  There
216   are structured and unstructured fields.  There are quoted pairs and
217   comments etc.  Rewrite the entire parsing mechanism to comply to RFC
218   5322, and try to merge all those many subparsers around in the codebase,
219   and accordingly.  So much duplicated work ...
220   Name parsing has been improved a bit for v13, but it's still broken.
221   yankword(), *extract(), etc.: RFC 5322 says that comments in address
222   fields SHOULD NOT be used (mutt(1) maps them to full name-addr forms if
223   approbiate, even if that actually changes content!!?), and that full
224   name-addr SHOULD be used.  Our functions are yet quite silly (i.e.,
225   leading comments remain, as in "(bier2) <a2@b2.de>", unless the address
226   doesn't come in angle brackets, trailing go away, as in "<a6@b6.de>
227   (bier6)", that becomes "<a6@b6.de>").
228   Something silly like
229     (co$mm1) abc@däf.de (cö,mm,2)   ('c'o"m"m.3)
230   Should eventually become
231     co$mm1 cö,mm,2 'c'o"m"m.3 <abc@xn--df-via.de>
232   on the display, or, with IDNA decoding (and thus rather unlikely)
233     co$mm1 cö,mm,2 'c'o"m"m.3 <abc@däf.de>
234   It should NOT become this mutt(1)ism:
235     "co$mm1 cö,mm,2 'c'omm.3" <abc@däf.de>
236   Or?
238 -- Think about a name bypass hashmap cache, and whenever we have to skin or
239    nalloc() or whatever, look in there.  Maybe even an additional link for
240    non GFULL(/GSKIN) and fully skinned struct name objects.
241    The amount of duplicated work in this codebase is frustrating, but the
242    real healing would make necessary a complete rewrite of the name handling!
243    Such a cache would work without touching the current code flow ... or
244    allow a smooth transition to a new one anyway.
246 ++  NOTE: 'alternates' tracking happens BEFORE we enter composing, this
247     means that an account switch during message composing will NOT cause
248     reevaluation of all that very very clumy
249     elide/delete_alternates/gexpand/is_myname etc. handling.
251 - Think about replacing the IMAP cache with an SQLITE3 interface.
252   Or rewrite it.  Error handling etc. etc. is peculiar.
254 - The char classification stuff can be improved; currently each character
255   has exactly one classification bit set, even if multiple would apply
256   (e.g., HT=\t == CNTRL|SPACE|ASCII|BLANK).  This would allow better
257   testing using our own classification functions in quite some places.
259 - The quoted-printable Content-Transfer-Encoding: supports soft linebreaks;
260   it happens that a lot of mailers (Apple Mail?, Microsoft Word, Yahoo!
261   Webmail) create HTML parts which solely consist of a single line,
262   created via soft linebreaks.
263   To handle such mess we need to be able to break out of the input-line ==
264   output line relationship that is still fixated in the codebase.
265   I.e., it is not even sufficient to convert "rest" into an array, but best
266   would be if we would be able to sequentially work what we have, and
267   detect when it is safe to "dump that out".
268   This MUST be part of the send/mime layer rewrite in 15.0.
270 -- In v15.0, when we can address attachments of a message individually,
271    it would be nice to provide even more access, just like nmh(1) does
272    (Johan Commelin: Are s-nail and mh related?).
274 - I want a clean PTF interface for the actual layers.  There should be no
275   switch() statements around that test for the type of BOX that is
276   currently open.  Especially important for possible NEWS support, but the
277   code is a mess in general...
279 - I hate longjmp()s and signals.  I suspect some pitfalls in the codebase.
280   All that stuff should at least be collected in a single place.
281   Just imagine how easy it could be done with a non-blocking select(2)
282   based event loop, ISIG off termios flags, etc.  ach!!
284   I would like to see that compilation with a C++ compiler is possible,
285   though that would be a long way and be especially problematic due to the
286   (C ish) way enums are used.
288 - I never used anything but the *datefield* option, and it would really be
289   nice if the date strings would be parsed off into some 16 byte or what
290   storage when about to producing the summary, so that it would be directly
291   available and there would be no need to reread the mail.  Moreover, or
292   even more than that - the m_date field exists and should possibly simply
293   be init, at least in these cases.  (P.S.: this doesn't contradict the
294   statement somewhere else in this file that the structure should be
295   slacked; simply use multiple thereof or so)
297 - All error messages should not go to stderr but instead we should add our
298   own n_warn() family and use that.  In the background we should have
299   a ring of error messages (oldest fall off), and a command that is capable
300   to display the ring.  The command loop should recognize whenever an error
301   happened during the last command, and print something like "XY errors
302   occurred", followed by a (truncated as necessary) error report.
303   It simply doesn't make any sense to print errors on stderr if normal
304   output goes to stdout and scrolls it off the screen.
305   Note that yet some errors messages still go to stdout.
307 - It would be very nice if it would be possible to have
308    account-specific macros that will be lost when a user switches off
309    an account.
311 -- It would also be very nice if we could define macros while defining
312    account, i.e., recursive definition of macros...
314 - At some later time extend the logic behind -# -- it should not have
315   a current folder, but start in VOID mode (...), and unless one is
316   explicitly chosen..  We need a reliable batch mode.
318 - (Support for mailcap files?  As of RFC 1524?  Unlikely.  Though the
319   % expansions would be very helpful, especially once we can address
320   individuals parts as of v15.0!)
322 - After I/O layer rework we should optionally be able to read RSS
323   (Atom?) feeds -- Expat should be available almost everywhere and
324   should be able to parse that?
325   Atom is harder because it may support html+.
326   I mean, yeah, it's stupid, but we could fill in header fields with
327   dummies and still use S-nail to look into the separated feeds as if
328   they were mail messages; anyway i would like to save me from using too
329   many tools -- three seems reasonable.
331 - Add TODO notes for those RFCs:
332   RFC 5322 - The basic format of email messages.
333   MIME (Multimeda) email extensions
334   RFC 2405 - The format of MIME message bodies.
335   RFC 2406 - Common multimedia types.
336   RFC 2017 - URL External-Body Access-Type
337   RFC 3676 - Updates to the text/plain MIME type and extensions for flowed
338     text (format=flowed).   (Martin Neitzel)
339   RFC 2407 - Encoding of non-ASCII text in message headers.
340   RFC 2183 - The Content-Disposition Header
341   RFC 2231 - Encoding of character set and language information in MIME
342     parameter values.
343   SMTP (Simple Mail Transfer Protocol)
344   RFC 5321 - Simple Mail Transfer Protocol.
345   RFC 6409 - Message Submission for Mail
346   RFC 4954 - SMTP Authentication
347   RFC 3207 - SMTP over TLS
348   RFC 6152 - SMTP Service Extension for 8-bit MIME Transport
349   Post Office Protocol (POP)
350   RFC 1939 - Post Office Protocol v3
351   RFC 2449 - POP3 Extensions (including SASL)
352   RFC 2595 - TLS for POP3 (among others)
353   Security
354   RFC 4422 - Simple Authentication and Security layer (SASL)
355   RFC 5246 - Transport Layer Security (TLS)
356   RFC 977 - Network News Transfer Protocol
357   RFC 2980 - Common NNTP Extensions
359 TODO S-nail 14.6:
360 -----------------
362 - Deal with faulty message selection that may occur when selecting threads
363   via & (when at least mixed with other selectors).
365 -- Also (?same problem?) the thread sort doesn't get
367     [A is deleted]
368     B answers A
369       C answers B
370       D answers B
371     E is unrelated
372     F answers A
374   The current sort fails to recognize that F and the thread starting at
375   B are related, which results in a mess.
377 - Make *password* and *password-USER@HOST* global, introduce
378   *PROTOCOL-auth-password* and *PROTOCOL-auth-password-USER@HOST*.
379   Then, drop smtp_auth_var(), and change lookup_password_for_token() to
380   work like (PROTOCOL, user,host|TOKEN) -- *password* is a global override,
381   only if that is not set lookup protocol specific.
382   Use that single function from everywhere.
384 - Change **use-starttls* to the opposite.  I.e., CAPA or whatever, if TLS
385   is supported, use automatically.  *UNLESS* explicitly disabled.
387 - NOTE: we do not really support IPv6 sofar in that we are not prepared to
388   deal with IPv6 addresses.
389   Introduce an URI abstraction structure in 14.5, and start using it, i.e.,
390   _pop3_user() and, very important, sopen().
391   Note this shit software use a lot of places which mess around...
393 - The account command involves a lot of code but it's only difference to
394   define is that a "fi" is executed.  If we would have the possibility to
395   explicitly jump to VOID boxes, we could use QUIT->FOLDER instead of
396   FOLDER[OK? -> QUIT], and then it'd be up to the use to simply use a "fi"
397   at the end of a define.  Or so.
398   See above for more on account/define though.
400 -- If *folder* is set to an IMAP box, and we're about to "mbox" data to
401    there, and we're currently on a POP3 server, and the connection fails,
402    we're completely lost and cannot even interrupt...
404 - mutt(1) dotlock ..., "mbox" command doesn'T work?
406 - ARGH!  Should `folders' auto-login if *folder* is an IMAP account that is
407   not active?  Why does _expand() use *mailname* to expand `@', not
408   getfold() (care: res may point into cbuf, savestr() or so!).
409   Why does demail() etc. treat *mailname* as a file (more or less), why do
410   we need *mailname* at all;  we should have Folder objects, multiple of
411   which concurrently, one the active; a Folder may not become *folder*
412   unless it has write (store) capabilities).  Maybe then `mbox' works fine
413   if connected to a POP3 server with a *MBOX* on an IMAP account that yet
414   never was connected and needs to read a password on the terminal before
415   the login works ... note the latter situation yet kills us since i think
416   INT is blocked during all that ;-((
418 - I had a connection collapse during a POP3 download, and neither was
419   there a chance to get access to the 22 yet downloaded mails (after
420   five minutes of waiting followed by CNTRL-C), nor did the layer
421   recognize this very well (got myriads of `POP3 connection already
422   closed.' messages, btw., the thirty-something messages which were not
423   yet downloaded caused (after CNTRL-C) this:
425     POP3 connection already closed.
426     POP3 connection already closed.
427     POP3 connection already closed.
428     POP3 connection already closed.
429     POP3 connection already closed.
430     POP3 connection already closed.
431      U 23                    Thu Jan  1 0    /    0
432     POP3 connection already closed.
433     POP3 connection already closed.
434     POP3 connection already closed.
435     POP3 connection already closed.
436     POP3 connection already closed.
437     POP3 connection already closed.
438      U 24                    Thu Jan  1 0    /    0
440   i had to switch off and back).  At least we didn't crash.
441   Thereafter, still very unstable connection, i tried to login again:
443     ? fi xpop
444     Resolving host pop.gmail.com . . . done.
445     Connecting to 173.194.70.109:pop3s . . . connected.
446     Comparing DNS name: "pop.gmail.com"
447     POP3 connection already closed.
448     +OK Gpop ready for requests from XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
449   [..nothing!..]
450     ^CInterrupt
451     ? fi %
452     "/private/var/mail/steffen": 0 messages
453     ? fi xpop
454     Resolving host pop.gmail.com . . . done.
455     Connecting to 173.194.70.109:pop3s . . . connected.
456     Comparing DNS name: "pop.gmail.com"
457     ? fi
458     ? fi
459     ? fi
461   Can of worms.
463 - Add a value-duplication command, i.e.,
464     clone _x header
465     unset header
466     ...
467     clone header _x
468     unset _x
470 - Add a boolify() function, so that things like `localopts' and yorn()
471   may be less strict on user input
473 - Ensure that `.' and EOF on a line works with all TTY modes (*ignoreeof*
474   relationship, too)!  EOF conditions in general!
476 -- NCL / current expand-on-tab: fexpand() should take additional size_t* to
477    store the number of the results OR should "return char** array", so that
478    individual results can be addressed.
479    Then we could simply print "\nALL-RESULTS\n" and NOT expand the current
480    line if the result is ambiguous, i.e., we have more than one possible
481    expansion.
482    However, we would then need something to print the results page-wise,
483    in case we have so many of them that they don't fit on the screen.
484    ...  Etc. ...
486 - IMAP: if i `d' a message then this is a local change (in the meanwhile);
487   yet, when i `u' it, that will go through the server, needlessly.
489 - I got an email in base64 that obviously used CRNL line endings, and once
490   i've replied the CR where quoted as *control* characters.
491   Get rid of those (kwcrtest.mbox; may be hard to do everywhere for some
492   time). (2013-08-06)
494 - Yet another one:
496   :>>> T1026 NOOP
497   Received SIGPIPE during IMAP operation
498   IMAP write error: error:00000000:lib(0):func(0):reason(0)
500   [DOING STUFF]
502   ? newmail
503   >>> T1027 FETCH 51:52 (FLAGS UID)
504   IMAP write error: Bad file descriptor
505   >>> T1028 FETCH 51:52 (RFC822.HEADER)
506   IMAP write error: Bad file descriptor
507   IMAP connection closed.
508   IMAP connection closed.
509   IMAP connection closed.
510   IMAP connection closed.
511   IMAP connection closed.
512   IMAP connection closed.
513   IMAP connection closed.
514   IMAP connection closed.
515   New mail has arrived.
516   Loaded 2 new messages.
517   >>> T1029 FETCH 51:52 (RFC822.HEADER)
518   IMAP write error: Bad file descriptor
519   IMAP connection closed.
520   IMAP connection closed.
521   IMAP connection closed.
522   IMAP connection closed.
523   IMAP connection closed.
524    U 51                    Thu Jan  1 0    /    0
525    IMAP connection closed.
526    IMAP connection closed.
527    IMAP connection closed.
528    IMAP connection closed.
529    IMAP connection closed.
531 - edit.c doesn't do NEED_BODY (yeah, IMAP won't work anyway).
533 - Some (configurable?) verbosity for certificate validation.
534   See, e.g., 'curl -v' output, which is quite nice (not only in respect
535   ot certificates).
536   (Martin Neitzel)
537   Rework certificate handling to match RFC 6125!  14.4!
539   .. s-nail </dev/null should work interactively when STDERR_FILENO is
540     a terminal!  (Builtin editor; how do editline and readline work?
541     should this be documented?  What does NetBSD Mail do?  Should we NOT
542     be interactive??  POSIX says for sh(1) (APPLICATION USAGE): 'sh
543     2>FILE' is not interactive, even though it accepts terminal input.)
544   . Automatically track message attachments when switching off the
545     folder.
546     NOTE: 'alternates' tracking happens BEFORE we enter composing, this
547     means that an account switch during message composing will NOT cause
548     reevaluation of all that very very clumy
549     elide/delete_alternates/gexpand/is_myname etc. handling.
550     We REALLY need an object based rework of all that.
551   . It would be cool if ghosts, shortcuts, alternates could
552     (optionally?) be tracked via localopts.
553   . The spam* series (spam.c:_spam_action()) should abort if the command
554     execution failed, instead of iterating the entire list.  Look into
555     that.
556   . DESTDIR= should not be taken into account when deciding wether
557     a rebuild is necessary (not wrong to give that to Gaetan Bisson).
558   . Just like the RFC 3676 link above, it would be nice if it would be
559     somehow possible to recognize links in a document; i don't know yet
560     how this could be achieved without loosing formatting information (i
561     mean, we could enable this and inject terminal colour sequences, but
562     one should be able to say 'follow link x', starting an action
563     handler, and the 'x' must come from somwhere - simply injecting
564     '[NUMBER]' references distorts visual).  Anyway, it's just a filter
565     that recognized the usual <SCHEME:/> stuff, and of course we can
566     simply have a buffer which records all such occurrences, so that
567     user can say '? xy NUMBER', but without the context it soon gets
568     hard.
569   . TTY layer: the tc*() family may fail with EINTR, which MUST be
570     handled; setting also generates SIGTTOU when we're not in foreground
571     pgrp, so we better deal with all that and ENSURE WE GET THROUGH when
572     resetting terminal attributes!
573   . Remove all occurrences of mbtowc() with mbrtowc(); temporarily add (some)
574     global mbstate_t objects until the send / MIME layer rewrite is done and
575     has the carrier.  Use flip states and add aux funs with only update the
576     state+toggle on success -- CURRENTLY MBTOWC FAILURES ARE PRACTICALLY NOT
577     HANDLED!!
578   . Ypnose (linuxien AT legtux DOT org) pointed out that for the IMAP
579     cache we have some kind of UID validity check -- couldn't that be
580     used to perform some kind of automatic reconnection when we get that
581     much-too-frequent connection breaks in IMAP mode??
582     Also, and also for POP3, don't let the ALARM based (ugh!  I'm
583     starting to dream wet from select(2), almost truly) timer blindly
584     tick, but restart it with a full interval when we did regular
585     conversation with a server.  Don't forget the SSL timeouts (300
586     seconds) and their interaction with normal (user) keepalives.
587     Add a global *keepalive*, add *keepalive-USER@HOST*.  (Add and use
588     a generic, single function to get the value for either protocol.)
589   . if.else.endif conditionals should REALLY be nestable.  Thank you.
590   . HAVE_HISTORY plus: for WANT_EDITLINE and WANT_READLINE the
591     mk-conf.sh yet always tests anything, i.e., we could fail due to
592     history related stuff even though the user doesn't WANT_HISTORY.
593   .. We should in fact convert our NCL history to a shared history
594      implementation, and only hook editline(3) and readline(3) so that
595      ^R and Cursor-(Up|Down) work as expected everywhere.
596      Like that we would have duplicate elimination for readline(3), too.
597   .. tty_addhist() should take a struct str.  Anyway, evaluate() should
598      enter a history entry if the caller allows so, and it should trim
599      also trailing whitespace; also, the expanded command should be
600      stored, not the abbreviation, so that 'sst' and 'sstats' will no
601      longer produce two separate entries.
602   . Commands should take a struct callargs*, not void*. asap.
604 vim:set fenc=utf-8:s-ts-mode