> 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 [email protected] http://lists.nongnu.org/mailman/listinfo/nmh-workers
