So what exactly are the plans for 2.0?
I think the more important question is: Which of the various plans that
people have, need a major effort before the can be released and which
things can drip in as they get done? For the later i think Jon's
approach of "Do whatever you like to see!" is just the right thing.
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 think this could be done step by step by whoever volunteers without
affecting release plans much.
* 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.
Same here.
* 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.
Yes, this is a major issue lurking for a long time. This is not restricted
to repl though. It affects pretty much everthing in nmh. Does anybody have
a good design for this in their drawer?
One MIME thing that I thought about is message signing and verification.
I wonder if this should be implemented as a new program which interacts
with the rest through sequences, annotations or whatever. But of course
this is strongly related to multipart handling, which we probably should
resolve first.
* Threading support. This is one of the obvious things missing from
nmh that just about all modern mailers support.
I'm not that sure about this. After all it's about e-mail not usenet.
I have something like
thread () {
pick -subject $1 -seq thread
scan thread
}
which does all I need.
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
Hmm, that would drop the traditional UNIX tradition of "one feature one
tool". I think sorting Messages is the job of sortm. Also this would
make the commands much slower.
+ sortm takes -[no]thread which makes it sort primarily by thread order
(with siblings subsorted by whatever other sort options are given)
Yes, I think adding new algorithms to sortm (and pick) would be a good
idea. This can be done independently from everything else.
+ 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
Would this really be useful? I think to pick one thread but sort it
by Date rather than as tree is much more natural for ML discussions.
(better ASCII-art thread tree suggestions welcome)
How about:
441 12/18 Joel Uckelman (0) [Nmh-workers] mhshow: invalid QUO
442 12/18 Josh Bressers (1) Re: [Nmh-workers] mhshow: invalid
443 12/18 Paul Fox (1) Re: [Nmh-workers] mhshow: invalid
444 12/18 Joel Uckelman (2) Re: [Nmh-workers] mhshow: invalid
448 12/19 To:nmh-worker (3) Re: [Nmh-workers] mhshow: invalid
447 12/19 To:nmh-worker (1) Re: [Nmh-workers] mhshow: invalid
This would provide - depending on sorting - the same information as
above, could be calculated statically/on a per message basis, would be
easier to represent on a terminal and easier to parse for humans if the
thread is longer than the screen.
Harald
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers