From 835688e42e34f8b362c95c6df2654c319bc9c6b3 Mon Sep 17 00:00:00 2001 From: "Steffen \"Daode\" Nurpmeso" Date: Sat, 20 Oct 2012 12:49:46 +0200 Subject: [PATCH] Even more TODO; and prettier presented, too ;) --- TODO | 98 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 81 insertions(+), 17 deletions(-) diff --git a/TODO b/TODO index 0915686b..73a91883 100644 --- a/TODO +++ b/TODO @@ -9,34 +9,44 @@ Backward-compatibility breakers - Recipients specified on the command line should be added to those specified in the message when the -t option is set. + - The -q option makes me sad as it doesn't use *indentprefix* for the quoted file. So either there should be -Q which does so, or -q should be changed. Also see ~R below. [Note: i think i go for the latter. Please complain.] + - NetBSD mailx(1) removes all recipients in up Cc: and To: that are also specified in Bcc. I think some kind of "yet-exists stack" as in Cc:->To:->Bcc would be a win. + - At least optionally disallow silent discarding of invalid addresses, i.e., cause sending to be aborted if not all recipient addresses pass the validity test. + - IIRC some error messages go to STDOUT, some to STDERR. Only latter. + - IIRC i saw invocations that returned with a 0 exit status and that surprised me, then. Errors should truly be reported. + - POSIX says that, when written to DEAD: "If the file exists, the message shall be written to replace the contents of the file". This is mentioned for ASYNCHRONOUS EVENTS, but it's the only description of what should be done in which way to DEAD. savedeadletter() yet appends. + - Furthermore, *all* file operations yet append, even recipient target files are appended. I don't know if this is really desirable behaviour, but i have not thought about that for real. Maybe this should be at least configurable. + - The current maintainer really would like to make the new *rfc822-no-body-from_* option the default, or, even better, get rid of these "pseudo From_"s that were introduced in 50fef89 (* A mbox-style "From " line is now generated.., 2004-11-06). + - Implement true RFC 4155 MBOX parsing; since that may not work with incompatible mailboxes (any?), add an option to turn this behaviour off. (The code practically exists already for many years, almost complete..) + - The current maintainer hates the way the command line arguments are processed. Because, many things that come in from the command line may depend on what the configuration files say. @@ -53,45 +63,59 @@ Non-breakers - [v13:started] Reformat the manual. roff style is fine, but lines should be ~70 characters, not only ~25. + - IDNA decoding. It may be that this will never be supported. But wouldn't it be nice for at least viewing messages? + - Mail-Followup-To:. + - Make it possible to reply to/save/write/xy part X.Y[.Z] by allowing its specification directly, as in, e.g., ':w 1.2'. If doing so on an embedded message/rfc822, e.g., a message embedded in a digest, it should be possible to reply to the very message in respect to its header fields, but (optionally?) keep the original Cc:'d. (Parts by Martin Neitzel) + - Yet the first part is used for forwarding and replying etc.. In MIME multipart messages it is however possible to make the HTML version the first, etc., so in case the normal "pick first part" algorithm is used that should maybe do "pick first plain text part if present, else first" insteadl. + - I want to have a ~R tilde command that works like ~r except it performs quoting of the input just as ~m does. Also see -q above. + - Offer the possibility to work with certificate fingerprints instead of full certificates, in equal spirit to the current maintainers S-Postman and Mercurial. S-nail(1) could simply offer something in equal spirit to the formers --fingerprint, so that no other tool is necessary for certificate management (for secure transport at least). + - It would be nice if it would be possible to define a format string for *quote*, like 'set quote="format=some formats"'. + - Deal with faulty message selection that may occur when selecting threads via & (when at least mixed with other selectors). + - On the long run -- try to add command line editing. + - For those who use S-nail(1) only with a MTA it may be desirable to have some "smopts" expansion mechanism in equal spirit to NetBSD mailx(1). + - While talking about NetBSD mailx(1), the author can imagine that being able to use the optional -H:xy stuff is sometimes nice. + - Add the possibility to simply place whatever header in the editor (and in the mail read in due to the -t command line option, and...). + - Check against RFC 5322. Rework all the header parsing code. Actually understand the content, classify the stuff so that it matches what is defined in RFC dependent on header field. Place the result in objects that know what they represent. -- Check against newest POSIX. -- Maybe add a bash(1)ish POSIXLY_CORRECT (or so) switch that can be used to - disallow extensions (e.g. specification of "full" addresses on command - line). + See the name extraction topic below. + +- Also check against newest POSIX. + Maybe add a bash(1)ish POSIXLY_CORRECT (or so) variable? Though.. + - Maybe there should be an additional ZOMBIE directive that is served in equal spirit to DEAD, but that could be a valid MBOX... ? What i want is a *real* resend, best if possible from command line. @@ -103,14 +127,9 @@ Low-Level - Revise the code: + Add C99-likeish typedefs for integers and use them everywhere. + Don't use magic constants/values. - + Try to thin out the onion and reduce work that is done over and over - again. Maybe introduce objects to represent header[field/body] and - content and find a way to pass those all through that vegetable. - + The current codebase assumes that in multibyte encodings plains ASCII - characters can be tested "as-is". This assumption is wrong for some - encodings that use U+001B (escape) or another ASCII thing to introduce - shift states. The only real solution to this problem would be to - rewrite the entire codebase and use wide characters (IMO) everywhere. + + [v13:started] Use const arguments whenever possible. Yet started, but + with ugly casts at some places because this is a can of worms. + + Inline functions? [Restrict pointers?] + Document the functions in the interface declarators. + [v13:started] Resort the functions and where they are implemented. It's really terrible. Just think about outof(), savedeadletter(), @@ -119,17 +138,48 @@ Low-Level + Make more use of value carriers in the call stack. There are functions with an incredible amount of arguments, needlessly. + makeconfig: link_check/compile_check. More of the latter suffice. -- Check all Popen() calls, i've had the impressions that Popen() doesn't - close all resources on failure. Also, Popen() callers often do a lot of - work in respect to signals. Try to find a solution that all problems are - encapsulaten in Popen(), at least better than today. + +- [v13:started] Improve name extraction rules. And field parsing. There + are structured and unstructured fields. There are quoted pairs and + comments etc. Rewrite the entire parsing mechanism to comply to RFC + 5322, and try to merge all those many subparsers around in the codebase, + and accordingly. So much duplicated work ... + Name parsing has been improved a bit for v13, but it's still broken. + yankword(), *extract(), etc.: RFC 5322 says that comments in address + fields SHOULD NOT be used (mutt(1) maps them to full name-addr forms if + approbiate, even if that actually changes content!!?), and that full + name-addr SHOULD be used. Our functions are yet quite silly (i.e., + leading comments remain, as in "(bier2) ", unless the address + doesn't come in angle brackets, trailing go away, as in " + (bier6)", that becomes ""). + Something silly like + (co$mm1) abc@däf.de (cö,mm,2) ('c'o"m"m.3) + Should eventually become + co$mm1 cö,mm,2 'c'o"m"m.3 + on the display, or, with IDNA decoding (and thus rather unlikely) + co$mm1 cö,mm,2 'c'o"m"m.3 + It should NOT become this mutt(1)ism: + "co$mm1 cö,mm,2 'c'omm.3" + Or? + - Think about a name bypass hashmap cache, and whenever we have to skin or nalloc() or whatever, look in there. Maybe even an additional link for non GFULL(/GSKIN) and fully skinned struct name objects. - The amount of duplicated work in this codebase if frustrating, but the + The amount of duplicated work in this codebase is frustrating, but the real healing would make necessary a complete rewrite of the name handling! Such a cache would work without touching the current code flow ... or allow a smooth transition to a new one anyway. + +- Check all Popen() calls, i've had the impressions that Popen() doesn't + close all resources on failure. Also, Popen() callers often do a lot of + work in respect to signals. Try to find a solution that all problems are + encapsulaten in Popen(), at least better than today. + +- is_myname() shows it, others too - there are variables which are + interpreted, and those should be interpreted once they are assigned, not + over and over again. Even better: lazy evalution -- use a special lookup + method for those. The mentioned method should indeed even go away? + - mime.c:prefixwrite() tracks state internally instead of having a cookie argument. That doesn't really make sense. Either it is capable to work with multiple files concurrently and prefix-quotes them correctly in the @@ -139,13 +189,27 @@ Low-Level was a newline last, and you switch files, then the last newline state is lost, and you do write the prefix even if in the other file there was no newline last. I'm confused now. Change this, please. + +- The current codebase assumes that in multibyte encodings plain ASCII + characters can be tested "as-is". This assumption is wrong for some + encodings that use U+001B (escape) or another ASCII thing to introduce + shift states. The only real solution to this problem would be to rewrite + the entire codebase and use wide characters (IMO) everywhere. + (Really. For at least header content.) + - The current maintainer doesn't like longjmp()s. + - The current maintainer doesn't like signals. + - The current maintainer would like to see that compilation with a C++ compiler is possible, though that would be a long way and be especially problematic due to the (C ish) way enums are used. He never understood why there is not "bitenum", btw. + - The current maintainer worked with all-tabs for almost one and a half decade and turned over to all-spaces afterwards. +Release S-nail v20 on 2018-03-25, the 40th anniversary of Mail. +With a clean, conforming and efficient codebase, then. + vim:set fenc=utf-8 syntax=txt ts=8 sts=2 sw=2 et tw=75: -- 2.11.4.GIT