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
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers