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