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 - 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.
78 - We need a "void" box that can be jumped to, i.e., a state in which no box
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
84 That is however only a command-specific workaround for a deeper design
87 -- When a MBOX mailbox is removed while it is opened then changing the
88 folder is not possible. This is an inherent problem of the Berkeley
89 Mail codebase, and we need to have a fully functional intermediate
90 VOID box mechanism plus an object-based mailbox implementation to
93 -- Also, when the folder is modified concurrently we should bail, or, in an
94 interactive session, prompt the user what to do.
96 - IDNA decoding. It may be that this will never be supported. But
97 wouldn't it be nice for at least viewing messages?
101 - Make it possible to reply to/save/write/xy part X.Y[.Z] by allowing its
102 specification directly, as in, e.g., ':w 1.2'. If doing so on an
103 embedded message/rfc822, e.g., a message embedded in a digest, it should
104 be possible to reply to the very message in respect to its header fields,
105 but (optionally?) keep the original Cc:'d. (Parts by Martin Neitzel)
107 - mutt(1) quotes all text parts of a message, not only the first one!
108 This should at least be optionally available.
110 - If pipes fail for part viewers then at least the usual PART X.Y should be
111 shown, maybe even including some error message.
112 I had 'set pipe-text/html="lynx -dump -force_html /dev/stdin"' but NetBSD
113 does not have lynx(1), and i thought i've found a S-nail(1) bug.
116 - I want to have a ~R tilde command that works like ~r except it performs
117 quoting of the input just as ~m does. Also see -q above.
119 - Offer the possibility to work with certificate fingerprints instead of
120 full certificates, in equal spirit to the current maintainers S-Postman
121 and Mercurial. S-nail(1) could simply offer something in equal spirit to
122 the formers --fingerprint, so that no other tool is necessary for
123 certificate management (for at least secure transport).
125 - It would be nice if it would be possible to define a format string for
126 *quote*, like 'set quote="format=some formats"'.
127 In general the current approach is somewhat messy IMO. I.e., it would
128 make more sense to act rather like mutt(1) and as written elsewhere in
129 this document, i.e., have some toggles that act on the display and use it
130 for multiple modes (show/reply/forward etc.)
131 Otherwise introduce commands which include all the headers plus, e.g.,
132 "hreply" or "freply", and then the ditto series, i.e., "hReply" ...
134 -- This would also mean that interactive message editing would work
137 - Command line editing should gain possibility of context sensitive tab
140 -- Note that the TTY is sick. If ^C on input it simply jumps to next
141 input, instead of saying "Interrupted, one more to die hard" or
142 something (talking about ~@ charset selection prompts in particular).
144 - For those who use S-nail(1) only with a MTA it may be desirable to have
145 some "smopts" expansion mechanism in equal spirit to NetBSD mailx(1).
147 - Check against RFC 5322.
148 Rework all the header parsing code. Actually understand the content,
149 classify the stuff so that it matches what is defined in RFC dependent on
150 header field. Place the result in objects that know what they represent.
151 See the name extraction topic below.
153 - Maybe there should be an additional ZOMBIE directive that is served in
154 equal spirit to DEAD, but that could be a valid MBOX... ?
155 What i want is a *real* resend, best if possible from command line.
156 Meaning, also the possibility to postpone a message. In general.
158 - POP3 doesn't support "newmail" for real. If implemented, should it sync?
159 Look at POP3 impl. in general..
161 - Having a newsreader would be a really cool thing. (RFC 977 and 2980)
163 - There should be a way to ignore the From_ line, as opposed to the From:
164 line, i.e., distinctively.
166 - There should be a variable that controls wether leading and trailing
167 empty lines of parts and/or messages as such should be printed or not.
169 - RFC 2387: multipart/related.
171 - rfc2384.txt etc. I.e., Much better URL support.
173 - printhead()/hprf(): support %n newline format (%t tab?).
174 Make it possible to use the *datefield* algorithm for plain From_ derived
175 dates (needs a From_ parser, i.e., strptime()-alike).
176 Once we have that, rename *datefield-markout-older* to
177 *date-markout-older* ??
178 Note that NetBSD's mail(1) has some other nice things.
179 Note also that our code is quite unflexible.
181 -- NetBSD's mail(1) has nice *indentprefix* and *indentpostscript*
182 variables (though prefix and appendix or prefix and suffix, but..).
183 Note that our code is quite unflexible.
185 - The "top" command should honour ignoretab, or there should be a very
186 special "top" ignoretab. It simply doesn't make sense to "top" 5 lines
187 when all that you get are Received: lines...
189 - In the very end it is not that hard to add (optional) MTA
190 functionality at a most simple level.
191 Use sqlite for aliases (and possibly cache), then.
193 - We should support IMAP compression over the wire.
198 - [v13:started] Improve name extraction rules. And field parsing. There
199 are structured and unstructured fields. There are quoted pairs and
200 comments etc. Rewrite the entire parsing mechanism to comply to RFC
201 5322, and try to merge all those many subparsers around in the codebase,
202 and accordingly. So much duplicated work ...
203 Name parsing has been improved a bit for v13, but it's still broken.
204 yankword(), *extract(), etc.: RFC 5322 says that comments in address
205 fields SHOULD NOT be used (mutt(1) maps them to full name-addr forms if
206 approbiate, even if that actually changes content!!?), and that full
207 name-addr SHOULD be used. Our functions are yet quite silly (i.e.,
208 leading comments remain, as in "(bier2) <a2@b2.de>", unless the address
209 doesn't come in angle brackets, trailing go away, as in "<a6@b6.de>
210 (bier6)", that becomes "<a6@b6.de>").
212 (co$mm1) abc@däf.de (cö,mm,2) ('c'o"m"m.3)
213 Should eventually become
214 co$mm1 cö,mm,2 'c'o"m"m.3 <abc@xn--df-via.de>
215 on the display, or, with IDNA decoding (and thus rather unlikely)
216 co$mm1 cö,mm,2 'c'o"m"m.3 <abc@däf.de>
217 It should NOT become this mutt(1)ism:
218 "co$mm1 cö,mm,2 'c'omm.3" <abc@däf.de>
221 -- Think about a name bypass hashmap cache, and whenever we have to skin or
222 nalloc() or whatever, look in there. Maybe even an additional link for
223 non GFULL(/GSKIN) and fully skinned struct name objects.
224 The amount of duplicated work in this codebase is frustrating, but the
225 real healing would make necessary a complete rewrite of the name handling!
226 Such a cache would work without touching the current code flow ... or
227 allow a smooth transition to a new one anyway.
229 ++ NOTE: 'alternates' tracking happens BEFORE we enter composing, this
230 means that an account switch during message composing will NOT cause
231 reevaluation of all that very very clumy
232 elide/delete_alternates/gexpand/is_myname etc. handling.
234 - Think about replacing the IMAP cache with an SQLITE3 interface.
235 Or rewrite it. Error handling etc. etc. is peculiar.
237 - The char classification stuff can be improved; currently each character
238 has exactly one classification bit set, even if multiple would apply
239 (e.g., HT=\t == CNTRL|SPACE|ASCII|BLANK). This would allow better
240 testing using our own classification functions in quite some places.
242 - The quoted-printable Content-Transfer-Encoding: supports soft linebreaks;
243 it happens that a lot of mailers (Apple Mail?, Microsoft Word, Yahoo!
244 Webmail) create HTML parts which solely consist of a single line,
245 created via soft linebreaks.
246 To handle such mess we need to be able to break out of the input-line ==
247 output line relationship that is still fixated in the codebase.
248 I.e., it is not even sufficient to convert "rest" into an array, but best
249 would be if we would be able to sequentially work what we have, and
250 detect when it is safe to "dump that out".
251 This MUST be part of the send/mime layer rewrite in 15.0.
253 -- In v15.0, when we can address attachments of a message individually,
254 it would be nice to provide even more access, just like nmh(1) does
255 (Johan Commelin: Are s-nail and mh related?).
257 - I want a clean PTF interface for the actual layers. There should be no
258 switch() statements around that test for the type of BOX that is
259 currently open. Especially important for possible NEWS support, but the
260 code is a mess in general...
262 - I hate longjmp()s and signals. I suspect some pitfalls in the codebase.
263 All that stuff should at least be collected in a single place.
264 Just imagine how easy it could be done with a non-blocking select(2)
265 based event loop, ISIG off termios flags, etc. ach!!
267 I would like to see that compilation with a C++ compiler is possible,
268 though that would be a long way and be especially problematic due to the
269 (C ish) way enums are used.
271 - I never used anything but the *datefield* option, and it would really be
272 nice if the date strings would be parsed off into some 16 byte or what
273 storage when about to producing the summary, so that it would be directly
274 available and there would be no need to reread the mail. Moreover, or
275 even more than that - the m_date field exists and should possibly simply
276 be init, at least in these cases. (P.S.: this doesn't contradict the
277 statement somewhere else in this file that the structure should be
278 slacked; simply use multiple thereof or so)
280 - All error messages should not go to stderr but instead we should add our
281 own n_warn() family and use that. In the background we should have
282 a ring of error messages (oldest fall off), and a command that is capable
283 to display the ring. The command loop should recognize whenever an error
284 happened during the last command, and print something like "XY errors
285 occurred", followed by a (truncated as necessary) error report.
286 It simply doesn't make any sense to print errors on stderr if normal
287 output goes to stdout and scrolls it off the screen.
288 Note that yet some errors messages still go to stdout.
290 - It would be very nice if it would be possible to have
291 account-specific macros that will be lost when a user switches off
294 -- It would also be very nice if we could define macros while defining
295 account, i.e., recursive definition of macros...
297 - At some later time extend the logic behind -# -- it should not have
298 a current folder, but start in VOID mode (...), and unless one is
299 explicitly chosen.. We need a reliable batch mode.
301 - (Support for mailcap files? As of RFC 1524? Unlikely. Though the
302 % expansions would be very helpful, especially once we can address
303 individuals parts as of v15.0!)
305 - After I/O layer rework we should optionally be able to read RSS
306 (Atom?) feeds -- Expat should be available almost everywhere and
307 should be able to parse that?
308 Atom is harder because it may support html+.
309 I mean, yeah, it's stupid, but we could fill in header fields with
310 dummies and still use S-nail to look into the separated feeds as if
311 they were mail messages; anyway i would like to save me from using too
312 many tools -- three seems reasonable.
314 - Add TODO notes for those RFCs:
315 RFC 5322 - The basic format of email messages.
316 MIME (Multimeda) email extensions
317 RFC 2405 - The format of MIME message bodies.
318 RFC 2406 - Common multimedia types.
319 RFC 2017 - URL External-Body Access-Type
320 RFC 3676 - Updates to the text/plain MIME type and extensions for flowed
321 text (format=flowed). (Martin Neitzel)
322 RFC 2407 - Encoding of non-ASCII text in message headers.
323 RFC 2183 - The Content-Disposition Header
324 RFC 2231 - Encoding of character set and language information in MIME
326 SMTP (Simple Mail Transfer Protocol)
327 RFC 5321 - Simple Mail Transfer Protocol.
328 RFC 6409 - Message Submission for Mail
329 RFC 4954 - SMTP Authentication
330 RFC 3207 - SMTP over TLS
331 RFC 6152 - SMTP Service Extension for 8-bit MIME Transport
332 Post Office Protocol (POP)
333 RFC 1939 - Post Office Protocol v3
334 RFC 2449 - POP3 Extensions (including SASL)
335 RFC 2595 - TLS for POP3 (among others)
337 RFC 4422 - Simple Authentication and Security layer (SASL)
338 RFC 5246 - Transport Layer Security (TLS)
339 RFC 977 -> 3977 - Network News Transfer Protocol
340 RFC 1036 - Standard for USENET Messages
341 RFC 2980 - Common NNTP Extensions
346 - Deal with faulty message selection that may occur when selecting threads
347 via & (when at least mixed with other selectors).
349 -- Also (?same problem?) the thread sort doesn't get
358 The current sort fails to recognize that F and the thread starting at
359 B are related, which results in a mess.
361 - Make *password* and *password-USER@HOST* global, introduce
362 *PROTOCOL-auth-password* and *PROTOCOL-auth-password-USER@HOST*.
363 Then, drop smtp_auth_var(), and change lookup_password_for_token() to
364 work like (PROTOCOL, user,host|TOKEN) -- *password* is a global override,
365 only if that is not set lookup protocol specific.
366 Use that single function from everywhere.
368 - Change **use-starttls* to the opposite. I.e., CAPA or whatever, if TLS
369 is supported, use automatically. *UNLESS* explicitly disabled.
371 - NOTE: we do not really support IPv6 sofar in that we are not prepared to
372 deal with IPv6 addresses.
373 Introduce an URI abstraction structure in 14.5, and start using it, i.e.,
374 _pop3_user() and, very important, sopen().
375 Note this shit software use a lot of places which mess around...
377 - The account command involves a lot of code but it's only difference to
378 define is that a "fi" is executed. If we would have the possibility to
379 explicitly jump to VOID boxes, we could use QUIT->FOLDER instead of
380 FOLDER[OK? -> QUIT], and then it'd be up to the use to simply use a "fi"
381 at the end of a define. Or so.
382 See above for more on account/define though.
384 -- If *folder* is set to an IMAP box, and we're about to "mbox" data to
385 there, and we're currently on a POP3 server, and the connection fails,
386 we're completely lost and cannot even interrupt...
388 - mutt(1) dotlock ..., "mbox" command doesn'T work?
390 - ARGH! Should `folders' auto-login if *folder* is an IMAP account that is
391 not active? Why does _expand() use *mailname* to expand `@', not
392 getfold() (care: res may point into cbuf, savestr() or so!).
393 Why does demail() etc. treat *mailname* as a file (more or less), why do
394 we need *mailname* at all; we should have Folder objects, multiple of
395 which concurrently, one the active; a Folder may not become *folder*
396 unless it has write (store) capabilities). Maybe then `mbox' works fine
397 if connected to a POP3 server with a *MBOX* on an IMAP account that yet
398 never was connected and needs to read a password on the terminal before
399 the login works ... note the latter situation yet kills us since i think
400 INT is blocked during all that ;-((
402 - I had a connection collapse during a POP3 download, and neither was
403 there a chance to get access to the 22 yet downloaded mails (after
404 five minutes of waiting followed by CNTRL-C), nor did the layer
405 recognize this very well (got myriads of `POP3 connection already
406 closed.' messages, btw., the thirty-something messages which were not
407 yet downloaded caused (after CNTRL-C) this:
409 POP3 connection already closed.
410 POP3 connection already closed.
411 POP3 connection already closed.
412 POP3 connection already closed.
413 POP3 connection already closed.
414 POP3 connection already closed.
416 POP3 connection already closed.
417 POP3 connection already closed.
418 POP3 connection already closed.
419 POP3 connection already closed.
420 POP3 connection already closed.
421 POP3 connection already closed.
424 i had to switch off and back). At least we didn't crash.
425 Thereafter, still very unstable connection, i tried to login again:
428 Resolving host pop.gmail.com . . . done.
429 Connecting to 173.194.70.109:pop3s . . . connected.
430 Comparing DNS name: "pop.gmail.com"
431 POP3 connection already closed.
432 +OK Gpop ready for requests from XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
436 "/private/var/mail/steffen": 0 messages
438 Resolving host pop.gmail.com . . . done.
439 Connecting to 173.194.70.109:pop3s . . . connected.
440 Comparing DNS name: "pop.gmail.com"
447 - Add a value-duplication command, i.e.,
454 - Add a boolify() function, so that things like `localopts' and yorn()
455 may be less strict on user input
457 - Ensure that `.' and EOF on a line works with all TTY modes (*ignoreeof*
458 relationship, too)! EOF conditions in general!
460 -- NCL / current expand-on-tab: fexpand() should take additional size_t* to
461 store the number of the results OR should "return char** array", so that
462 individual results can be addressed.
463 Then we could simply print "\nALL-RESULTS\n" and NOT expand the current
464 line if the result is ambiguous, i.e., we have more than one possible
466 However, we would then need something to print the results page-wise,
467 in case we have so many of them that they don't fit on the screen.
470 - IMAP: if i `d' a message then this is a local change (in the meanwhile);
471 yet, when i `u' it, that will go through the server, needlessly.
473 - I got an email in base64 that obviously used CRNL line endings, and once
474 i've replied the CR where quoted as *control* characters.
475 Get rid of those (kwcrtest.mbox; may be hard to do everywhere for some
481 Received SIGPIPE during IMAP operation
482 IMAP write error: error:00000000:lib(0):func(0):reason(0)
487 >>> T1027 FETCH 51:52 (FLAGS UID)
488 IMAP write error: Bad file descriptor
489 >>> T1028 FETCH 51:52 (RFC822.HEADER)
490 IMAP write error: Bad file descriptor
491 IMAP connection closed.
492 IMAP connection closed.
493 IMAP connection closed.
494 IMAP connection closed.
495 IMAP connection closed.
496 IMAP connection closed.
497 IMAP connection closed.
498 IMAP connection closed.
499 New mail has arrived.
500 Loaded 2 new messages.
501 >>> T1029 FETCH 51:52 (RFC822.HEADER)
502 IMAP write error: Bad file descriptor
503 IMAP connection closed.
504 IMAP connection closed.
505 IMAP connection closed.
506 IMAP connection closed.
507 IMAP connection closed.
509 IMAP connection closed.
510 IMAP connection closed.
511 IMAP connection closed.
512 IMAP connection closed.
513 IMAP connection closed.
515 - edit.c doesn't do NEED_BODY (yeah, IMAP won't work anyway).
517 - Some (configurable?) verbosity for certificate validation.
518 See, e.g., 'curl -v' output, which is quite nice (not only in respect
521 Rework certificate handling to match RFC 6125.
524 .. s-nail </dev/null should work interactively when STDERR_FILENO is
525 a terminal! (Builtin editor; how do editline and readline work?
526 should this be documented? What does NetBSD Mail do? Should we NOT
527 be interactive?? POSIX says for sh(1) (APPLICATION USAGE): 'sh
528 2>FILE' is not interactive, even though it accepts terminal input.)
529 . Automatically track message attachments when switching off the
531 NOTE: 'alternates' tracking happens BEFORE we enter composing, this
532 means that an account switch during message composing will NOT cause
533 reevaluation of all that very very clumy
534 elide/delete_alternates/gexpand/is_myname etc. handling.
535 We REALLY need an object based rework of all that.
536 . It would be cool if ghosts, shortcuts, alternates could
537 (optionally?) be tracked via localopts.
538 (Additional entry on xy-local xy somewhere above)
539 . The spam* series (spam.c:_spam_action()) should abort if the command
540 execution failed, instead of iterating the entire list. Look into
542 . DESTDIR= should not be taken into account when deciding wether
543 a rebuild is necessary (not wrong to give that to Gaetan Bisson).
544 . Just like the RFC 3676 link above, it would be nice if it would be
545 somehow possible to recognize links in a document; i don't know yet
546 how this could be achieved without loosing formatting information (i
547 mean, we could enable this and inject terminal colour sequences, but
548 one should be able to say 'follow link x', starting an action
549 handler, and the 'x' must come from somwhere - simply injecting
550 '[NUMBER]' references distorts visual). Anyway, it's just a filter
551 that recognized the usual <SCHEME:/> stuff, and of course we can
552 simply have a buffer which records all such occurrences, so that
553 user can say '? xy NUMBER', but without the context it soon gets
555 . TTY layer: the tc*() family may fail with EINTR, which MUST be
556 handled; setting also generates SIGTTOU when we're not in foreground
557 pgrp, so we better deal with all that and ENSURE WE GET THROUGH when
558 resetting terminal attributes!
559 . Remove all occurrences of mbtowc() with mbrtowc(); temporarily add (some)
560 global mbstate_t objects until the send / MIME layer rewrite is done and
561 has the carrier. Use flip states and add aux funs with only update the
562 state+toggle on success -- CURRENTLY MBTOWC FAILURES ARE PRACTICALLY NOT
564 . Ypnose (linuxien AT legtux DOT org) pointed out that for the IMAP
565 cache we have some kind of UID validity check -- couldn't that be
566 used to perform some kind of automatic reconnection when we get that
567 much-too-frequent connection breaks in IMAP mode??
568 Also, and also for POP3, don't let the ALARM based (ugh! I'm
569 starting to dream wet from select(2), almost truly) timer blindly
570 tick, but restart it with a full interval when we did regular
571 conversation with a server. Don't forget the SSL timeouts (300
572 seconds) and their interaction with normal (user) keepalives.
573 Add a global *keepalive*, add *keepalive-USER@HOST*. (Add and use
574 a generic, single function to get the value for either protocol.)
575 . HAVE_HISTORY plus: for WANT_EDITLINE and WANT_READLINE the
576 mk-conf.sh yet always tests anything, i.e., we could fail due to
577 history related stuff even though the user doesn't WANT_HISTORY.
578 .. We should in fact convert our NCL history to a shared history
579 implementation, and only hook editline(3) and readline(3) so that
580 ^R and Cursor-(Up|Down) work as expected everywhere.
581 Like that we would have duplicate elimination for readline(3), too.
582 .. tty_addhist() should take a struct str. Anyway, evaluate() should
583 enter a history entry if the caller allows so, and it should trim
584 also trailing whitespace; also, the expanded command should be
585 stored, not the abbreviation, so that 'sst' and 'sstats' will no
586 longer produce two separate entries.
587 . Commands should take a struct callargs*, not void*. asap.
588 . getprompt() is not multibyte safe in that it should mbrtowc() before
589 calling expand_shell_escape() (i.e., only call that if ASCII,
590 otherwise pass through if fits as such).
591 . Make S/MIME an option separate of SSL/TLS
592 . pop3,mime_cte +++: \r,\n -> \015,\012, to avoid ANY problems..
593 . send.c:_print_part_info(): the filename is truncated to a maximum of
594 25 characters, which of course may mess up multibyte encodings!
595 We need a multibyte safe clamp function, even if this means that
596 an already encoded string is again parsed... We can take advantage
597 of UTF-8 here, however.
598 FURTHERMORE: don't go and separate ISO C90 Amend. 1 and wcwidth(3);
599 only support wide and multibyte stuff if we have them all.
600 Alternatively we could support ONLY UTF-8 locales via ISO C90 and
601 implement our own wcwidth(3) IFF it's only the latter is missing.
602 Though that sounds crappy.
604 v14.7 MUST use only mbrtowc() and have solved all these multibyte
605 problems (that i've introduced, mostly, and mostly for new
606 features). It has to last for well over a year!
607 . which_protocol(), *newmail* mechanism, displayname, mailname: all of
608 this <rude>SHIT</rude> must be rewritten completely and can be
609 overcome by an object-based mailbox implementation that carries all
610 the necessary state (user given path, expanded realpath(3),
611 abbreviated display path, box-protocol, etc.). Once we have this,
612 we may as well also re-introduce automatic detection of compressed
613 file-based folders based upon .gz/.bz2/.xz extension.
615 If not mentioned somehwere else: struct message should be splitted
616 into a tree of objects, with a base class that has as few fields as
617 possible; the global *message should be a deque, only accessible via
618 iterator; it should store pointers to (the actually used subtype of)
619 message structures instead; i.e., for maildir boxes the path is yet
620 allocated separately, then it could be part of the message object,
622 . Drop support for *autoinc* in favour of *newmail* -- mention that
623 i have forgotten to mention that it's legacy in 14.5.2 release
625 . Given how many temporary files we use, it would make sense to
626 support a reusable single temporary file, as in singletmp_take() and
627 singletmp_release(), where singletmp_release() would close and thus
628 drop the file if it excesses a specific (configurable) size, and the
629 mainloop tick would close it (after X (configurable) ticks))
630 otherwise. I guess this would improve performance for searching
632 . Searching code *could* perform a prepass, joining stuff together,
633 dropping useless cases etc.
634 But anyway: if there are multiple search expressions, it shouldn't
635 be an error if at least one of them matches at least one message.
636 . catset(3) is plain shit, and ever was. Remove IDs from all tr()s,
637 use GNU tools for extraction etc., and write a simple helper program
638 which converts these files to a serialized hashmap, just like we did
639 for the okeys (and *exactly* so); add a config check wether the ({})
640 extension is supported and finally use that for some ({static char
641 const *tr_res;}) injection optimization, then. (Think SFSYS)
642 . Searching body/text yet includes headers from attachments and
643 attachment data. This is shit. :)
645 vim:set fenc=utf-8:s-ts-mode