Hi. On Thu 2002-06-20 at 16:56:24 +1000, Scott Howard wrote: > > I'm fairly certain this isn't possible, but... > > Our helpdesk system sends out emails every time a task/case/request is > created/updated/closed/etc. > > These take the form of something like : > > 17 + Jun 17 Helpdesk ( 0) New Task - Task#: 12345678 > 18 + Jun 17 Helpdesk ( 0) Task Updated - Task#: 12345678 > 19 + Jun 17 Helpdesk ( 0) Task Closed - Task#: 12345678 > > I'd like to be able to get mutt to thread these messages together as a > single thread, but I can't see an easy way to do it.
It has some side-effects which may be unwanted, but the following
regexp should make mutt view those subject as belonging to one thread,
by telling it to consider the beginning up to "Task#: " reply mark
(i.e. like "Re: "):
set reply_regexp=".* - Task#: "
unset strict_threads # that's the default
set sort_re # that's the default
Of course, you probably want to set it for the folder in question,
let's say "support":
folder-hook . 'set reply_regexp="^(re|aw|sv):[ \t]*"; '
folder-hook =support 'set reply_regexp="^.* - Task#: "'
(the latter is the default, change it to whatever you want).
> The mail all runs through procmail, so I can get procmail to put in a
> header such as :
> X-Task-Num: 12345678
> but short of hacking the code I can't see a way to use that as the key for
> threading.
Probably it would be more useful, if the subject would start with the
task number, as reply_regexp wouldn't have to include the "real"
subject part.
Additionally a short test showed that it (changing reply_regexp) will
only work, if no valid References and In-Reply-To headers are given,
else it will use them - being more precise information. But from what
you wrote, these shouldn't be given (else you wouldn't have that
threading problem, would you?).
Bye,
Benjamin.
--
[EMAIL PROTECTED]
msg29109/pgp00000.pgp
Description: PGP signature
