Re: [Nmh-workers] exciting new stuff for 2.0

[Harald Geyer]

> 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