Re: [Nmh-workers] Future directions for nmh

[Ken Hornstein]

>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