Re: [Nmh-workers] Future directions for nmh

[Conrad Hughes]

Ken> You run command (a) which changes the context.  How is command (b)
Ken> supposed to know that the context has been changed?

Given your mentioning of MHCONTEXT, I could envisage a wrapper for MH
commands much like Paul Fox's example — perhaps a context directory
containing per-shell-PID context files, and the crucial test would be
whether another context file was more recent than and different to this
shell's one when you take an action.

There's a problem there though, in that context only records your
current folder, with sequences being folder-local — so a sortm in one
shell could render a previous scan in another shell obsolete.  Trying to
solve that by merging all sequences up into context would introduce
other difficulties: for example sortm would have to rewrite *all*
context+sequence records containing sequences affected by the sort.  The
difficulty of tracking that probably renders Paul's approach ("Something
happened somewhere else — you're about to affect message(s) X — are you
sure?") safer.

I don't use other message stores, but it seems to me that maintaining a
map of MH unique IDs to another store could be quite closely related,
and perhaps Paul's approach would still apply: it's simple and safe,
although it could be inconvenient if "third party" changes couldn't be
tracked at a sufficiently fine granularity.

Conrad