[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] mhfixmsg invocation
From: |
David Levine |
Subject: |
Re: [Nmh-workers] mhfixmsg invocation |
Date: |
Wed, 19 Nov 2014 10:17:16 -0500 |
Paul F. wrote:
> i'm having a bit of trouble understanding how to integrate mhfixmsg
> into my workflow.
>
> i'd like to automatically run mhfixmsg on all mail, and, therefore,
> keep a backup of messages that it processes. since i kind of abhor
> the ,nnn style of mh backups, i'd like to keep the mhfixmsg backups in
> a separate folder. i think i can do this by setting mhfixmsg's
> rmmproc to a command that does something like:
> cp $* $(mhpath +mhfixbackup new)
> is there a better way?
Not that I can think of, though I use the procmail approach so
haven't thought too much about it.
> to invoke mhfixmsg, using add-hook would normally seem like the best
> bet, except that it makes "refile -link" useless (for messages that
> mhfixmsg wants to process), as far as i can tell. there's no way to
> disable add-hook for individual commands, right?
I don't think so, that's why there's the caveat in the mhfixmsg
man page.
> are hooks a useful
> enough feature that making them settable for individual commands
> (i.e. "inc: -add-hook my-inc-add-hook") be desireable?
>
> the man page also suggests using something like:
> alias inc='inc && mhfixmsg'
> but i don't see how this will work -- what if inc incorporates several
> messages?
Right, that should be fixed.
> mhfixmg by default will only act on 'cur', leaving the
> others unprocessed. (i suppose "inc && mhfixmsg unseen" would work, at
> the cost of re-checking messages that i've manually added back into
> the unseen sequence.)
The cost of re-checking is so low that I would go that route.
Alternatively, something like this (completely untested)?
msgs=`inc -format '%(msg)'` && [ -n "$msgs" ] && mhfixmsg $msgs
Let me know what you settle on and I'll update the man page.
> finally -- it feels like mhfixmsg should always add a new
> "X-mhfixmsg-was-here" header when it modifies a message, which would
> let me know that there is (or was) another version of the message file
> floating around somewhere. was this considered?
No. Off hand, I'm not fond of it. You can do that with anno if
you want.
David