Hi Ken,
By implication, the comparison program is buggy if that doesn't
hold? sortm(1) punts to qsort(3) for the hard graft and that
demands consistency; I think I'd like sortm to protect me from a
buggy comparison program. [...]
You know what? Forget I said anything :-)
Sorry, don't mean to stop possible small improvements by drowning out
the conversation. :-) We didn't even get onto threading; `subject' is
often a crude substitute.
I think the email's number is currently used as an implicit last-resort
tie-breaker in all cases so qsort(3) becomes stable? Should sortm(3)
state it's a stable sort?
These ideas all sound fine; I'm kind of torn about the key-vs-cmp
program, but I think either one would be fine.
`key' has the advantage that the user's program cannot be inconsistent
over time; it's only asked once for any email.
I've thought a little more about it. I'd change -kprogram to -progkey
so -k is sufficient for the common case. The stripping of
/^(re|fw):\s*/i from the front of a field could be triggered by a key
flag. The sequence of keys would be processed one at a time, e.g. `-k
subject -progk foo' would sort all emails on subject first and then
invoke foo as few times as necessary to only get a secondary key for the
emails that tied on subject.
Cheers, Ralph.
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers