Jerrad Pierce writes:
My *intent* when adding the hook code was to allow external, non-nmh programs
to access the message store keeping track of changes. I added this code for
a specific purpose, and never thought about anyone executing nmh commands
inside of hook code. So I support Ken's conclusion that doing so is madness.
I understand, and yet it's such a powerful way to extend the features of nmh
without requiring core changes e.g; the supplemental MIME storage I'm using.
Maddening as the sequence clash is, there's a workaround (though who knows
when it might break, since it's not clear why I should work... my guess is
it's
akin to funky scoping like local $foo = $foo in perl). The thing that makes
the least sense to me is that mark gives different results than cat, despite
being run from the same environment/situation.
P.S. It would still be useful to have environment variables exposed,
and del-hook ought to let the child know if -unlink was used e.g;
by setting the CMD to rmm-unlink instead of rmm
Sigh. This is deja vu all over again :) As with the attachment code,
there are improvements that can be made now that it's been "discovered".
I'm perfectly happy if people want to add features and more clearly define
the hook mechanism provided that existing stuff isn't broken.
I added this code for a specific purpose. Seemed like a pretty good way
for people to experiment with directory-per-message stuff without having
to change the nmh code. But, if people want to do really clever stuff
with it then we also need to be more clever about the implementation.
Jon
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers