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
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
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
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".
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
49 - It irritates me that a message with 5 visible lines but 115 header lines
50 goes through the pager, even if i have *crt=*.
51 P.S.: we could simply count the headers in addition?
53 - We should possibly get away of using command line utilities for
54 compression. (At least optionally?) Instead we should link against
55 zlib(3), bz2lib(3) and lzma(3), if found. Or we may use dlopen(3)
56 instead, if found, to avoid linking (though those libraries don't need
57 much linker work unless actually used afaik, 'should look in detail).
58 We should also drop lzw.c, it is used for the IMAP cache.
60 - We should maybe turn -~ into the meaning "force interactive".
61 We should extend cc-test.sh, then, to test some interactive things.
66 - We need a "void" box that can be jumped to, i.e., a state in which no box
69 (schdir(): realpath() local files before leaving CWD.., 2013-01-08)
70 did a first step to avoid "getting stuck" when the current folder becomes
72 That is however only a command-specific workaround for a deeper design
75 -- When a MBOX mailbox is removed while it is opened then changing the
76 folder is not possible. This is an inherent problem of the Berkeley
77 Mail codebase, and we need to have a fully functional intermediate
78 VOID box mechanism plus an object-based mailbox implementation to
81 -- Also, when the folder is modified concurrently we should bail, or, in an
82 interactive session, prompt the user what to do.
84 - IDNA decoding. Needs a complete design change.
88 - Make it possible to reply to/save/write/xy part X.Y[.Z] by allowing its
89 specification directly, as in, e.g., ':w 1.2'. If doing so on an
90 embedded message/rfc822, e.g., a message embedded in a digest, it should
91 be possible to reply to the very message in respect to its header fields,
92 but (optionally?) keep the original Cc:'d. (Parts by Martin Neitzel)
94 - mutt(1) quotes all text parts of a message, not only the first one!
95 This should at least be optionally available.
97 - If pipes fail for part viewers then at least the usual PART X.Y should be
98 shown, maybe even including some error message.
99 I had 'set pipe-text/html="lynx -dump -force_html /dev/stdin"' but NetBSD
100 does not have lynx(1), and i thought i've found a S-nail(1) bug.
103 - I want to have a ~R tilde command that works like ~r except it performs
104 quoting of the input just as ~m does. Also see -q above.
106 - Offer the possibility to work with certificate fingerprints instead of
107 full certificates, in equal spirit to the current maintainers S-Postman
108 and Mercurial. S-nail(1) could simply offer something in equal spirit to
109 the formers --fingerprint, so that no other tool is necessary for
110 certificate management (for at least secure transport).
112 - It would be nice if it would be possible to define a format string for
113 *quote*, like 'set quote="format=some formats"'.
114 In general the current approach is somewhat messy IMO. I.e., it would
115 make more sense to act rather like mutt(1) and as written elsewhere in
116 this document, i.e., have some toggles that act on the display and use it
117 for multiple modes (show/reply/forward etc.)
118 Otherwise introduce commands which include all the headers plus, e.g.,
119 "hreply" or "freply", and then the ditto series, i.e., "hReply" ...
121 -- This would also mean that interactive message editing would work
124 - Command line editing should gain possibility of context sensitive tab
127 -- Note that the TTY is sick. If ^C on input it simply jumps to next
128 input, instead of saying "Interrupted, one more to die hard" or
129 something (talking about ~@ charset selection prompts in particular).
131 - For those who use S-nail(1) only with a MTA it may be desirable to have
132 some "smopts" expansion mechanism in equal spirit to NetBSD mailx(1).
134 - Maybe there should be an additional ZOMBIE directive that is served in
135 equal spirit to DEAD, but that could be a valid MBOX... ?
136 What i want is a *real* resend, best if possible from command line.
137 Meaning, also the possibility to postpone a message. In general.
139 - POP3 doesn't support "newmail" for real. If implemented, should it sync?
140 Look at POP3 impl. in general..
142 - Having a newsreader would be a really cool thing. (RFC 977 and 2980)
144 - There should be a way to ignore the From_ line, as opposed to the From:
145 line, i.e., distinctively.
147 - There should be a variable that controls wether leading and trailing
148 empty lines of parts and/or messages as such should be printed or not.
150 - RFC 2387: multipart/related.
152 - rfc2384.txt etc. I.e., Much better URL support.
154 - printhead()/hprf(): support %n newline format (%t tab?).
155 Make it possible to use the *datefield* algorithm for plain From_ derived
156 dates (needs a From_ parser, i.e., strptime()-alike).
157 Once we have that, rename *datefield-markout-older* to
158 *date-markout-older* ??
159 Note that NetBSD's mail(1) has some other nice things.
160 Note also that our code is quite unflexible.
162 -- NetBSD's mail(1) has nice *indentprefix* and *indentpostscript*
163 variables (though prefix and appendix or prefix and suffix, but..).
164 Note that our code is quite unflexible.
166 - The "top" command should honour ignoretab, or there should be a very
167 special "top" ignoretab. It simply doesn't make sense to "top" 5 lines
168 when all that you get are Received: lines...
170 - In the very end it is not that hard to add (optional) MTA
171 functionality at a most simple level.
172 Use sqlite for aliases (and possibly cache), then.
174 - We should support IMAP compression over the wire.
179 - Improve name extraction rules. And field parsing. There
180 are structured and unstructured fields. There are quoted pairs and
181 comments etc. Rewrite the entire parsing mechanism to comply to RFC
182 5322, and try to merge all those many subparsers around in the codebase,
183 and accordingly. So much duplicated work ...
184 Name parsing has been improved a bit for v13, but it's still broken.
185 yankword(), *extract(), etc.: RFC 5322 says that comments in address
186 fields SHOULD NOT be used (mutt(1) maps them to full name-addr forms if
187 approbiate, even if that actually changes content!!?), and that full
188 name-addr SHOULD be used. Our functions are yet quite silly (i.e.,
189 leading comments remain, as in "(bier2) <a2@b2.de>", unless the address
190 doesn't come in angle brackets, trailing go away, as in "<a6@b6.de>
191 (bier6)", that becomes "<a6@b6.de>").
193 (co$mm1) abc@däf.de (cö,mm,2) ('c'o"m"m.3)
194 Should eventually become
195 co$mm1 cö,mm,2 'c'o"m"m.3 <abc@xn--df-via.de>
196 on the display, or, with IDNA decoding (and thus rather unlikely)
197 co$mm1 cö,mm,2 'c'o"m"m.3 <abc@däf.de>
198 It should NOT become this mutt(1)ism:
199 "co$mm1 cö,mm,2 'c'omm.3" <abc@däf.de>
202 -- Think about a name bypass hashmap cache, and whenever we have to skin or
203 nalloc() or whatever, look in there. Maybe even an additional link for
204 non GFULL(/GSKIN) and fully skinned struct name objects.
205 The amount of duplicated work in this codebase is frustrating, but the
206 real healing would make necessary a complete rewrite of the name handling!
207 Such a cache would work without touching the current code flow ... or
208 allow a smooth transition to a new one anyway.
210 ++ NOTE: 'alternates' tracking happens BEFORE we enter composing, this
211 means that an account switch during message composing will NOT cause
212 reevaluation of all that very very clumy
213 elide/delete_alternates/gexpand/is_myname etc. handling.
215 - Think about replacing the IMAP cache with an SQLITE3 interface.
216 Or rewrite it. Error handling etc. etc. is peculiar.
218 - The char classification stuff can be improved; currently each character
219 has exactly one classification bit set, even if multiple would apply
220 (e.g., HT=\t == CNTRL|SPACE|ASCII|BLANK). This would allow better
221 testing using our own classification functions in quite some places.
223 - The quoted-printable Content-Transfer-Encoding: supports soft linebreaks;
224 it happens that a lot of mailers (Apple Mail?, Microsoft Word, Yahoo!
225 Webmail) create HTML parts which solely consist of a single line,
226 created via soft linebreaks.
227 To handle such mess we need to be able to break out of the input-line ==
228 output line relationship that is still fixated in the codebase.
229 I.e., it is not even sufficient to convert "rest" into an array, but best
230 would be if we would be able to sequentially work what we have, and
231 detect when it is safe to "dump that out".
232 This MUST be part of the send/mime layer rewrite in 15.0.
234 -- In v15.0, when we can address attachments of a message individually,
235 it would be nice to provide even more access, just like nmh(1) does
236 (Johan Commelin: Are s-nail and mh related?).
238 - I want a clean PTF interface for the actual layers. There should be no
239 switch() statements around that test for the type of BOX that is
240 currently open. Especially important for possible NEWS support, but the
241 code is a mess in general...
243 - I would like to see that compilation with a C++ compiler is possible,
244 though that would be a long way and be especially problematic due to the
245 (C ish) way enums are used.
247 - I never used anything but the *datefield* option, and it would really be
248 nice if the date strings would be parsed off into some 16 byte or what
249 storage when about to producing the summary, so that it would be directly
250 available and there would be no need to reread the mail. Moreover, or
251 even more than that - the m_date field exists and should possibly simply
252 be init, at least in these cases. (P.S.: this doesn't contradict the
253 statement somewhere else in this file that the structure should be
254 slacked; simply use multiple thereof or so)
256 - All error messages should not go to stderr but instead we should add our
257 own n_warn() family and use that. In the background we should have
258 a ring of error messages (oldest fall off), and a command that is capable
259 to display the ring. The command loop should recognize whenever an error
260 happened during the last command, and print something like "XY errors
261 occurred", followed by a (truncated as necessary) error report.
262 It simply doesn't make any sense to print errors on stderr if normal
263 output goes to stdout and scrolls it off the screen.
264 Note that yet some errors messages still go to stdout.
266 - It would be very nice if it would be possible to have
267 account-specific macros that will be lost when a user switches off
270 -- It would also be very nice if we could define macros while defining
271 account, i.e., recursive definition of macros...
273 - At some later time extend the logic behind -# -- it should not have
274 a current folder, but start in VOID mode (...), and unless one is
275 explicitly chosen.. We need a reliable batch mode.
277 - (Support for mailcap files? As of RFC 1524? Unlikely. Though the
278 % expansions would be very helpful, especially once we can address
279 individuals parts as of v15.0!)
281 - After I/O layer rework we should optionally be able to read RSS
282 (Atom?) feeds -- Expat should be available almost everywhere and
283 should be able to parse that?
284 Atom is harder because it may support html+.
285 I mean, yeah, it's stupid, but we could fill in header fields with
286 dummies and still use S-nail to look into the separated feeds as if
287 they were mail messages; anyway i would like to save me from using too
288 many tools -- three seems reasonable.
290 - Add TODO notes for those RFCs:
291 RFC 5322 - The basic format of email messages.
292 MIME (Multimeda) email extensions
293 RFC 2405 - The format of MIME message bodies.
294 RFC 2406 - Common multimedia types.
295 RFC 2017 - URL External-Body Access-Type
296 RFC 3676 - Updates to the text/plain MIME type and extensions for flowed
297 text (format=flowed). (Martin Neitzel)
298 RFC 2407 - Encoding of non-ASCII text in message headers.
299 RFC 2183 - The Content-Disposition Header
300 RFC 2231 - Encoding of character set and language information in MIME
302 SMTP (Simple Mail Transfer Protocol)
303 RFC 5321 - Simple Mail Transfer Protocol.
304 RFC 6409 - Message Submission for Mail
305 RFC 4954 - SMTP Authentication
306 RFC 3207 - SMTP over TLS
307 RFC 6152 - SMTP Service Extension for 8-bit MIME Transport
308 Post Office Protocol (POP)
309 RFC 1939 - Post Office Protocol v3
310 RFC 2449 - POP3 Extensions (including SASL)
311 RFC 2595 - TLS for POP3 (among others)
313 RFC 4422 - Simple Authentication and Security layer (SASL)
314 RFC 5246 - Transport Layer Security (TLS)
315 RFC 977 -> 3977 - Network News Transfer Protocol
316 RFC 1036 - Standard for USENET Messages
317 RFC 2980 - Common NNTP Extensions
319 - This is how the codebase has to be reworked in respect to signals and
322 1. We introduce some environment/carrier structs: struct eval_ctx,
323 struct cmd_ctx, (struct send_ctx). All of these form lists.
324 eval_ctx gets a new instance every time evaluate() is entered; for
325 the interactive mode, commands() instantiates an outermost eval_ctx
326 that "cannot be left".
327 cmd_ctx knows about the eval_ctx in which it is was created; it is
328 created for each command that has an entry in cmd_tab and is passed
329 as the new argument of these kind of functions.
330 (send_ctx is the carrier for the MIME and send layer rewrite.)
331 2. We'll get a signal manager. This is a global layer which is the
332 sole object-in-charge for signals. We'll install a complete set of
333 handlers once -- those will only set has-occurred bits.
334 All interested parties have to peek at the signal manager when they
335 are in the position to deal with signals, via a series of
336 "ha(s|ve)_occurred", "needs_action", "would_raise" or whatever, as
338 3. We need a sort of non-local return, everything else would require
339 a totally different way of programming. Also, non-local returns
340 are not *that* bad, generally speaking. We'll be easy and add the
341 possibility to define a jump target location in eval_ctx and
342 cmd_ctx, by peeking at the signal manager (for object design
343 reasons, though done by a macro, say), just like saying "i need to
344 have the chance to perform some actions shall a jump be necessary".
345 4. So, somewhere deep down the still recursive codebase, shall the
346 necessity to honour a jump request occur, we peek the signal
347 manager to "unroll" the current cmd_ctx/eval_ctx chain(s), which
348 will result in none-to-multiple jumps to locations which require
349 cleanup actions, ultimately ending in the non-leavable commands()
350 eval_ctx or whatever.
351 6. Hot: we save us from thousands of syscalls, and get rid of the
352 fucking sig* shit. It rhymes, it rhymes :)
353 Should we even be able to go the non-blocking select(2) way in the
354 end -- that would be fantastic!
355 10. The line buffer used in evaluate() that is passed through to
356 commands (thus: in cmd_ctx, then) needs to become `const'.
357 (I tried to do so in the past, but some commands write into it,
358 thus i stopped and iirc even added some changes on my own which
359 take favour of reusing that buffer.)
360 + Macro execution then no longer needs to clone the macro content
361 lines before executing then.
362 11. Macro execution is potentially recursive. Meaning that
363 `undefine', etc. can occur while macros are executing.
364 The simplemost approach would be to have some recursion counter for
365 each macro and a delete_later flag that gets honoured when the
366 recursion counter gets zero. It would be already possible to
367 immediately remove the macro from the hashtable, so that deeper
368 levels wouldn't find it anymore. To avoid leaks (which *are*) we
369 need to have a jump location for our upcoming signal handler
370 anyway. (Also to get rid of the temporary_localopts_free() hack.
371 + The same is true for `account's. Here things are complicated by
372 the global `account_name', i.e., the account could be the current
374 12. It is annoying that you cannot `source' your MAILRC multiple times.
375 Defining a macro/account/xy should overwrite the current thing,
376 just as it does anyway for normal variables!
377 This is no different than 11. plus additional re-addition.
378 (Same exception: what if the currently active account is
379 overwritten? Same answer, plus a message "new settings take effect
380 when account is switched to the next time".)
381 20. The attachment charset selection loop can then be rewritten to
382 check wether an ^C occurred and treat that as end-of-loop
383 condition. In v14.6.3 this was introduced, but it should act
384 differently depending on wether the interrupt occurred during
385 character set selection or attachment filename input.
386 Also in respect wether the interrupt is "propagated" or not.
387 It's ugly, and documented accordingly.
388 30. Mail protocols and mail messages are accessed through a "VFS".
389 31. Flag updates of individual messages must find their way through to
391 32. Use deque (on partial views).
392 33. It must be possible to open individual boxes read-only, new command
393 `cfile' (and `cfolder') as a last resort.
394 34. We need a new abstraction: `vie[ws]'. I.e, viewset, viewclear,
395 view(show|look)? We will have (possibly readonly) boxes, a summary
396 cache file, which is created when a mailbox is read in, and all
397 that crap that we currently have (setptr(), setmsize(), etc.!) must
398 vanish. Instead there is another, in-memory abstraction, the view.
399 Some views are builtin and are somehow selectable (the "all" view,
400 for example, and the "new" view).
401 It is possible to make a view persistent by giving it a name, e.g.,
402 'viewset NAME MSG-SPEC' -- 'viewset allnew :n' (and 'viewset XY `'
403 or something must be capable to tag the last a.k.a current).
404 Switching to a named view would thus look over the entire current
405 view (!) for all messages that comply to the message-spec of the
406 view, then create a sorted/threaded display of that subset and
407 create a new anonymous "result" view. It must be possible to
408 specify that a view is to be applied to the entire mailbox instead
409 of the current view, via a simple easy understandable syntax.
410 99. Now i'm dreaming some more: with the new object-based approach
411 multiple mailboxes could be in an open state. And it should be
412 possible to do so for the user (`file' and `folder' are required to
413 quit the current mailbox [first -- this not yet]), which is why we
414 either need new trigger characters or new commands (then also in
415 a readonly version, again, it gets lengthy).
416 The absolute sensation would be joinable operations over multiple
417 open mailboxes, e.g., views over multiple such!
422 - Deal with faulty message selection that may occur when selecting threads
423 via & (when at least mixed with other selectors).
425 -- Also (?same problem?) the thread sort doesn't get
434 The current sort fails to recognize that F and the thread starting at
435 B are related, which results in a mess.
437 - Make *password* and *password-USER@HOST* global, introduce
438 *PROTOCOL-auth-password* and *PROTOCOL-auth-password-USER@HOST*.
439 Then, drop smtp_auth_var(), and change lookup_password_for_token() to
440 work like (PROTOCOL, user,host|TOKEN) -- *password* is a global override,
441 only if that is not set lookup protocol specific.
442 Use that single function from everywhere.
444 - Change **use-starttls* to the opposite. I.e., CAPA or whatever, if TLS
445 is supported, use automatically. *UNLESS* explicitly disabled.
447 - NOTE: we do not really support IPv6 sofar in that we are not prepared to
448 deal with IPv6 addresses.
449 Introduce an URI abstraction structure in 14.5, and start using it, i.e.,
450 _pop3_user() and, very important, sopen().
451 Note this shit software use a lot of places which mess around...
453 - The account command involves a lot of code but it's only difference to
454 define is that a "fi" is executed. If we would have the possibility to
455 explicitly jump to VOID boxes, we could use QUIT->FOLDER instead of
456 FOLDER[OK? -> QUIT], and then it'd be up to the use to simply use a "fi"
457 at the end of a define. Or so.
458 See above for more on account/define though.
460 -- If *folder* is set to an IMAP box, and we're about to "mbox" data to
461 there, and we're currently on a POP3 server, and the connection fails,
462 we're completely lost and cannot even interrupt...
464 - mutt(1) dotlock ..., "mbox" command doesn'T work?
466 - ARGH! Should `folders' auto-login if *folder* is an IMAP account that is
467 not active? Why does _expand() use *mailname* to expand `@', not
468 getfold() (care: res may point into cbuf, savestr() or so!).
469 Why does demail() etc. treat *mailname* as a file (more or less), why do
470 we need *mailname* at all; we should have Folder objects, multiple of
471 which concurrently, one the active; a Folder may not become *folder*
472 unless it has write (store) capabilities). Maybe then `mbox' works fine
473 if connected to a POP3 server with a *MBOX* on an IMAP account that yet
474 never was connected and needs to read a password on the terminal before
475 the login works ... note the latter situation yet kills us since i think
476 INT is blocked during all that ;-((
478 - I had a connection collapse during a POP3 download, and neither was
479 there a chance to get access to the 22 yet downloaded mails (after
480 five minutes of waiting followed by CNTRL-C), nor did the layer
481 recognize this very well (got myriads of `POP3 connection already
482 closed.' messages, btw., the thirty-something messages which were not
483 yet downloaded caused (after CNTRL-C) this:
485 POP3 connection already closed.
486 POP3 connection already closed.
487 POP3 connection already closed.
488 POP3 connection already closed.
489 POP3 connection already closed.
490 POP3 connection already closed.
492 POP3 connection already closed.
493 POP3 connection already closed.
494 POP3 connection already closed.
495 POP3 connection already closed.
496 POP3 connection already closed.
497 POP3 connection already closed.
500 i had to switch off and back). At least we didn't crash.
501 Thereafter, still very unstable connection, i tried to login again:
504 Resolving host pop.gmail.com . . . done.
505 Connecting to 173.194.70.109:pop3s . . . connected.
506 Comparing DNS name: "pop.gmail.com"
507 POP3 connection already closed.
508 +OK Gpop ready for requests from XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
512 "/private/var/mail/steffen": 0 messages
514 Resolving host pop.gmail.com . . . done.
515 Connecting to 173.194.70.109:pop3s . . . connected.
516 Comparing DNS name: "pop.gmail.com"
523 - Add a value-duplication command, i.e.,
530 - Add a boolify() function, so that things like `localopts' and yorn()
531 may be less strict on user input
533 - Ensure that `.' and EOF on a line works with all TTY modes (*ignoreeof*
534 relationship, too)! EOF conditions in general!
536 -- NCL / current expand-on-tab: fexpand() should take additional size_t* to
537 store the number of the results OR should "return char** array", so that
538 individual results can be addressed.
539 Then we could simply print "\nALL-RESULTS\n" and NOT expand the current
540 line if the result is ambiguous, i.e., we have more than one possible
542 However, we would then need something to print the results page-wise,
543 in case we have so many of them that they don't fit on the screen.
546 - IMAP: if i `d' a message then this is a local change (in the meanwhile);
547 yet, when i `u' it, that will go through the server, needlessly.
549 - I got an email in base64 that obviously used CRNL line endings, and once
550 i've replied the CR where quoted as *control* characters.
551 Get rid of those (kwcrtest.mbox; may be hard to do everywhere for some
554 - edit.c doesn't do NEED_BODY (yeah, IMAP won't work anyway).
556 - Some (configurable?) verbosity for certificate validation.
557 See, e.g., 'curl -v' output, which is quite nice (not only in respect
560 Rework certificate handling to match RFC 6125.
563 .. s-nail </dev/null should work interactively when STDERR_FILENO is
564 a terminal! (Builtin editor; how do editline and readline work?
565 should this be documented? What does NetBSD Mail do? Should we NOT
566 be interactive?? POSIX says for sh(1) (APPLICATION USAGE): 'sh
567 2>FILE' is not interactive, even though it accepts terminal input.)
568 . Automatically track message attachments when switching off the
570 NOTE: 'alternates' tracking happens BEFORE we enter composing, this
571 means that an account switch during message composing will NOT cause
572 reevaluation of all that very very clumy
573 elide/delete_alternates/gexpand/is_myname etc. handling.
574 We REALLY need an object based rework of all that.
575 . It would be cool if ghosts, shortcuts, alternates could
576 (optionally?) be tracked via localopts.
577 (Additional entry on xy-local xy somewhere above)
578 . The spam* series (spam.c:_spam_action()) should abort if the command
579 execution failed, instead of iterating the entire list. Look into
581 . DESTDIR= should not be taken into account when deciding wether
582 a rebuild is necessary (not wrong to give that to Gaetan Bisson).
583 . Just like the RFC 3676 link above, it would be nice if it would be
584 somehow possible to recognize links in a document; i don't know yet
585 how this could be achieved without loosing formatting information (i
586 mean, we could enable this and inject terminal colour sequences, but
587 one should be able to say 'follow link x', starting an action
588 handler, and the 'x' must come from somwhere - simply injecting
589 '[NUMBER]' references distorts visual). Anyway, it's just a filter
590 that recognized the usual <SCHEME:/> stuff, and of course we can
591 simply have a buffer which records all such occurrences, so that
592 user can say '? xy NUMBER', but without the context it soon gets
594 . TTY layer: the tc*() family may fail with EINTR, which MUST be
595 handled; setting also generates SIGTTOU when we're not in foreground
596 pgrp, so we better deal with all that and ENSURE WE GET THROUGH when
597 resetting terminal attributes!
598 . Remove all occurrences of mbtowc() with mbrtowc(); temporarily add (some)
599 global mbstate_t objects until the send / MIME layer rewrite is done and
600 has the carrier. Use flip states and add aux funs with only update the
601 state+toggle on success -- CURRENTLY MBTOWC FAILURES ARE PRACTICALLY NOT
603 . Ypnose (linuxien AT legtux DOT org) pointed out that for the IMAP
604 cache we have some kind of UID validity check -- couldn't that be
605 used to perform some kind of automatic reconnection when we get that
606 much-too-frequent connection breaks in IMAP mode??
607 Also, and also for POP3, don't let the ALARM based (ugh! I'm
608 starting to dream wet from select(2), almost truly) timer blindly
609 tick, but restart it with a full interval when we did regular
610 conversation with a server. Don't forget the SSL timeouts (300
611 seconds) and their interaction with normal (user) keepalives.
612 Add a global *keepalive*, add *keepalive-USER@HOST*. (Add and use
613 a generic, single function to get the value for either protocol.)
614 . HAVE_HISTORY plus: for WANT_EDITLINE and WANT_READLINE the
615 mk-conf.sh yet always tests anything, i.e., we could fail due to
616 history related stuff even though the user doesn't WANT_HISTORY.
617 .. We should in fact convert our NCL history to a shared history
618 implementation, and only hook editline(3) and readline(3) so that
619 ^R and Cursor-(Up|Down) work as expected everywhere.
620 Like that we would have duplicate elimination for readline(3), too.
621 .. tty_addhist() should take a struct str. Anyway, evaluate() should
622 enter a history entry if the caller allows so, and it should trim
623 also trailing whitespace; also, the expanded command should be
624 stored, not the abbreviation, so that 'sst' and 'sstats' will no
625 longer produce two separate entries.
626 . getprompt() is not multibyte safe in that it should mbrtowc() before
627 calling expand_shell_escape() (i.e., only call that if ASCII,
628 otherwise pass through if fits as such).
629 . Make S/MIME an option separate of SSL/TLS
630 . pop3,mime_cte +++: \r,\n -> \015,\012, to avoid ANY problems..
631 . send.c:_print_part_info(): the filename is truncated to a maximum of
632 25 characters, which of course may mess up multibyte encodings!
633 We need a multibyte safe clamp function, even if this means that
634 an already encoded string is again parsed... We can take advantage
635 of UTF-8 here, however.
636 FURTHERMORE: don't go and separate ISO C90 Amend. 1 and wcwidth(3);
637 only support wide and multibyte stuff if we have them all.
638 Alternatively we could support ONLY UTF-8 locales via ISO C90 and
639 implement our own wcwidth(3) IFF it's only the latter is missing.
640 Though that sounds crappy.
642 v14.7 MUST use only mbrtowc() and have solved all these multibyte
643 problems (that i've introduced, mostly, and mostly for new
644 features). It has to last for well over a year!
645 . which_protocol(), *newmail* mechanism, displayname, mailname: all of
646 this <rude>SHIT</rude> must be rewritten completely and can be
647 overcome by an object-based mailbox implementation that carries all
648 the necessary state (user given path, expanded realpath(3),
649 abbreviated display path, box-protocol, etc.). Once we have this,
650 we may as well also re-introduce automatic detection of compressed
651 file-based folders based upon .gz/.bz2/.xz extension.
653 If not mentioned somehwere else: struct message should be splitted
654 into a tree of objects, with a base class that has as few fields as
655 possible; the global *message should be a deque, only accessible via
656 iterator; it should store pointers to (the actually used subtype of)
657 message structures instead; i.e., for maildir boxes the path is yet
658 allocated separately, then it could be part of the message object,
660 It should contain a ui8_t that tracks the number of contained parts,
661 so that the "fits-onto-the-screen" tests are more useful than today;
662 i think 8-bit is sufficient, with 0xFF meaning more-than-fits-here.
663 . Given how many temporary files we use, it would make sense to
664 support a reusable single temporary file, as in singletmp_take() and
665 singletmp_release(), where singletmp_release() would close and thus
666 drop the file if it excesses a specific (configurable) size, and the
667 mainloop tick would close it (after X (configurable) ticks))
668 otherwise. I guess this would improve performance for searching
670 . Searching code *could* perform a prepass, joining stuff together,
671 dropping useless cases etc.
672 But anyway: if there are multiple search expressions, it shouldn't
673 be an error if at least one of them matches at least one message.
674 . catset(3) is plain shit, and ever was. Remove IDs from all tr()s,
675 use GNU tools for extraction etc., and write a simple helper program
676 which converts these files to a serialized hashmap, just like we did
677 for the okeys (and *exactly* so); add a config check wether the ({})
678 extension is supported and finally use that for some ({static char
679 const *tr_res;}) injection optimization, then. (Think SFSYS)
680 . Searching body/text yet includes headers from attachments and
681 attachment data. This is shit. :)
682 . Btw.: (with IMAP) when opening a folder the hook gets executed after
683 the flags but before the headers are loaded, but for `newmail' it is
684 *after* the headers have been loaded.
685 . /* TODO *batch-exit-on-error*: sourcing and loading MUST BE FLAGS!
686 * TODO the current behaviour is suboptimal AT BEST! */
687 . there MUST be a way to specify that a single SPECIFIC box has to be
688 opened readonly. only the global -R flag is NOT ENOUGH!
689 . the "nifty" unregister_file()->_compress() mechanism that even
690 shovels '-Sfolder=imaps://user1@localhost -Srecord="+Sent Items"'
691 *records* calls clearerr() on the descriptor before performing it's
692 action anyway. when we really make it even to the I/O rewrite, it
693 should be possible to dis-/allow such -- it doesn't make sense to
694 add something faulty to whatever was not faulty before!
695 . The message from Andy Switala on nail-devel made me think about some
696 mechanism that invokes a macro after a message has been sent.
697 Unless macros can have args (or do we introduce $*/$@/$1..).
698 Even if the codebase will at some future time be stable and really
699 reliable, sending a message via multiple channels will never be
700 atomic, so that it would make sense for a user to be able to restore
701 *the complete message* in a save place if any of the sends failed,
702 but to remove it from our temporary place otherwise. A simple
703 version of this would be a matter of five minutes, but since
704 mightrecord() may internally (via _compress()) instantiate
705 a complete IMAP session and try to send incomplete data etc.,
706 and all that may jump, i refrained from doing so.
707 . (RFC 6409 and) SMTPS should go for port 587. Also /etc/services
708 doesn't deal with SMTPS but on NetBSD, here the (original, now wrong,
709 and still used in our codebase: IPv4) port 465 is used for SMTPS.
710 This means: users which use smtps:// alone will most likely not be
711 able to use SMTPS, they have to add a :PORTSTR.
712 (Ooops - i think this should go to Gianluca Ramunno!)
713 . `dp' prints EOF at the end of a thread even if unread messages
715 . [-- #2 : 41/2761, text/plain, 0001-Israel-DST-transitio --]
716 If not fit, it should do `...'
717 It is not multibyte safe anyway, implement a generic function (or
718 two, one that takes an iconv_t) to trim a string into a buffer
719 . Explicit `setenv' command!
720 . When doing `~w FILE' and FILE cannot be written to (was a directory)
721 then the composed mail is lost completely, it seems we jump to the
723 . Shouldn't `resend' store to +record? It .. doesn't?
724 . The capability to save a message under the name of a recipient is in
725 the standard etc., but i've never used it.
726 What would be cool, otoh, would be if there would be the possibility
727 to register a regular expression, and if just *any* recipient of
728 a message matches, store the message in the given folder instead.
729 I.e., if i send a message to s-nail-users@ then i most likely want
730 to get a copy to the corresponding box, regardless of whoever the
731 message was sent To: Cc: or Bcc: else..
732 . in my ~xother with *nohold* if at the begin i have many large
733 messages i ended up with a truncated *mbox*? what was that?
735 vim:set fenc=utf-8:s-ts-mode