So what exactly are the plans for 2.0? Here are some things I'd like to see, in increasing order of complexity:
* I'd like to see all the hacky messing with stdio internals taken out in favour of using the proper APIs. This kind of thing was added as a performance hack decades ago when MH was running on VAXen -- surely we can afford to take it out now? We wind up with #ifdefs for different kinds of stdio library and we still hit portability problems: see for instance https://savannah.nongnu.org/bugs/?func=detailitem&item_id=3945. * I'd also prefer much less reliance on fixed-size buffers. Again, these were a good idea in 1980 but these days they mostly mean arbitrary length limits at best and security holes at worst. * We really need much better support for MIME and non-ASCII character sets. This means fixing simpler things like scan thinking that one byte == one character == one screen column: https://savannah.nongnu.org/bugs/?func=detailitem&item_id=15017 and also more general support for seamlessly translating between the charset of an email and the locale charset when viewing and editing email. My opinion (given in slightly more detail in this PR: https://savannah.nongnu.org/bugs/?func=detailitem&item_id=15214 ) is that we should have some extra thing you can specify in your repl filter file (and which should be in the default one, probably) which says "select the right part of a multipart MIME mail, decode quoted-printable or base-64, and convert charset as specified by MIME header into the charset for the user's locale". Then when you finish editing and before sending it we need to (semi-?)automatically add the right MIME headers and translate charsets again. The aim is that reading and replying to an email in Japanese should require no extra steps beyond what you'd do for an email in English. * Threading support. This is one of the obvious things missing from nmh that just about all modern mailers support. I had a play at adding it ages ago. This is my suggestion for a UI: + all commands that take a range of message numbers take a new option switch -[no]thread which causes them to run the threading algorithm on the set of messages and process them in thread order rather than numerical order + sortm takes -[no]thread which makes it sort primarily by thread order (with siblings subsorted by whatever other sort options are given) + we should have a new format string escape sequence to add an ASCII representation of the thread tree, so you can make scan display something like this: 441 12/18 Joel Uckelman o [Nmh-workers] mhshow: invalid QUO 442 12/18 Josh Bressers +o Re: [Nmh-workers] mhshow: invalid 443 12/18 Paul Fox +o Re: [Nmh-workers] mhshow: invalid 444 12/18 Joel Uckelman |+o Re: [Nmh-workers] mhshow: invalid 448 12/19 To:nmh-worker | +o Re: [Nmh-workers] mhshow: invalid 447 12/19 To:nmh-worker +o Re: [Nmh-workers] mhshow: invalid (better ASCII-art thread tree suggestions welcome) The only difficulty is that the bulk of the time required to thread is taken by opening and reading the files to get References/In-Reply-To, and of course this has to be done up-front, so in a command like "scan last:500|less" the threaded version has to read all 500 files before it can start printing anything, whereas the unthreaded version can start printing lines as it goes along and so it feels more responsive. [This is why only the messages in the specified range are threaded, rather than threading the whole folder and then looking at the specified range; the results will be different sometimes.] I don't think this can be avoided unless we want to add some kind of overview file to sit alongside the per-email files. (GNUS has an option to do this already, incidentally.) Opinions? Anybody else got pet projects they want to share? -- PMM _______________________________________________ Nmh-workers mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/nmh-workers
