My preference would be for actions (rmm, refile, repl) to note there's
been a context change and ask for confirmation, I think. The machine is
better than I am at tracking consistency. If context-in-this-window and
most-recent-context are different (or more particularly, the action
target (cur, most likely) differs between the two contexts), then there
is a significant chance I'm trying to do something other than what I
appear to be doing.
Okay, dumb question time. You run command (a) which changes the context.
How is command (b) supposed to know that the context has been changed?
Think carefully about your answer.
Taken to its ultimate conclusion, that means that context actually
should record both the full sequence of message-IDs (say) in all folders
*and* all mh_sequences. As has been mentioned, that could impact
performance.
The problem is that information is, in the MH model, redundant; the "unique
identifier" is the message number, full stop. If you're changing the
message store behind nmh, you're really supposed to Know What You're Doing.
But the unique identifer can easily be changed with things like
folder -pack and sortm. My point being is that if there are changes to
the store but they all conform to unique message numbers, all of the nmh
utilities should work fine.
Wouldn't a similar consistency check catch IMAP changes too (contingent
on the suggested UUID <-> local number mapping)?
I don't see the same issues applying.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers