[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Threads

From: Ralph Corderoy
Subject: Re: [Nmh-workers] Threads
Date: Sun, 07 Apr 2013 16:32:13 +0100

Hi Lyndon,

> Wouldn't threading be handled by external scripts?  This sounds like
> something I would do by generating a list of message-id and references
> headers, then doing a tsort and feeding the whole mess back into
> scan/show.

That simplistic approach is similar to what I do now, but it's
insufficient, e.g. http://www.jwz.org/doc/threading.html is often
referenced as the "right" way to do it and I see it made it into
http://www.jwz.org/doc/draft-ietf-imapext-thread-12.txt for
implementation in an IMAP server rather than the client.

> In fact, the whole concept of 'threads' is something I would like to
> keep outside of the base toolset.

It's too complex to leave outside of nmh's knowledge.  I'd like to pick
the parents of these messages, all ancestors, the immediate descendants,
or all descendants, or all messages in the same thread, ideally combined
with pick's, or its replacement's, other options.

> I have never found an MUA that can come even close to expressing the
> sort of detail I want when dealing with threads.

An example would be good though I accept it can be hard to think one up
on the spot.  Larry Wall's trn(1) Usenet reader used to have some nice
thread selectors.

I wonder if the thread functionality should come first based on the dumb
approach of scanning all headers each time, accepting performance will
suffer on larger folders, and then look at improving performance?  The
user often knows something to avoid a folder scan, e.g. those of
interest are in last:500.

(Talking of which, it would be nice to be able to `pick -sub foo -within
last:500' and have pick avoid a folder scan.  I should be able to
specify a subset of the folder to search within.)

A simple improvement might be a cache that's only built on request, the
old behaviour being achieved with `pick: -rebuild-cache' in
~/.mh_profile.  But I'm often happy with something that works albeit
slowly on the odd occasion I need it.  Below's my ~/bin/-thr that is
crude and slow but better than nothing.  `p' is pick(1) with `-seq lp',
`g' is egrep(1).

Cheers, Ralph.

#! /bin/bash

# Starting with the initial messages picked by the command's arguments
# it expands outwards looking for all emails in the folder that are
# connected in some way by the message IDs mentioned.  It's not fast.
# usage: -thr 42 43
# usage: -thr -from egg.com

set -eEu -o pipefail
shopt -s failglob
trap 'echo ${0##*/}: line $LINENO: unexpected exit: $? >&2' ERR

p "$@"
old=$(p -list lp)

while true; do
    p $(
        for h in message-id references in-reply-to; do
            anno -list -component $h -text ignored lp |
            { g -o '<[^<>address@hidden<>]+>' || true; } |
            sed 's/[.$]/\\&/g'
        done |
        sort -u |
        sed 's/.*/-sea & -o/; $s/ -o$//'
    new=$(p -list lp)
    [[ $new = $old ]] && break

reply via email to

[Prev in Thread] Current Thread [Next in Thread]