Paul wrote:
david wrote:
> My thinking at this point is to make the guts of the
> fixer-upper available to repl and forw. I hadn't thought
> about pick but it should be able to use them as well.
are you picturing a one-time "fix this message" command, which leaves
it greppable, replyable, editable, etc, but fundamentally changed, or
more of a library of operations that are applied any time we want to
do one of those things to a message, in order to leave the original
unchanged?
i thought you were planning the former (which i think i'd prefer, if
we trusted it :-), but what you say above makes me no longer sure.
Definitely the former, I should have been clearer. But I'll
put the functions in a +sbr.c file so that repl, forw, etc.,
can use them as desired.
Thinking a bit more about pick: I'd expect a pick that had
to decode and translate via an external program on the fly
would be way too slow. I grep through 10's of 1000's of
messages at a time. I definitely want the permanent message
modification.
Trust is critical. I'm starting from mhtest, which has
always been distributed with MH and nmh (and deprecated as
of the next release). It just reads a message and writes it
back out, re-using these functions from mhn/mhshow/mhlist
and mhstore:
parse_mime(CT)
output_message(CT, char *filename)
CT points to a hierarchical structure of the message
content. The fixer-upper will transform it between the two
steps above. That transformation will use what we already
have for mhstore and mhshow. So there's really nothing new
here but packaging. (Unbusticating C-T-E headers and
boundaries is new but trivial, and just deals with messages
that nmh won't parse now.)
Mark wrote:
However... I see that altering it in-place is probably
easier, and the result is available "everywhere" without
still-more-hooks to filters, etc.
No doubt some people won't want to modify the original
message. It will be easy enough to put the modified version
in another file of the user's choice, or in a new message
using rcvstore, or both.
Hmmm...what about abusing something like the comma-prefix
used by rmm to keep the original , unchanged message? When
the fixupfilter is run, it copies $messageID to
,$messageID.orig (or some such). Of course, this would
imply extending rmmproc, refile, "folder -pack", etc. to
deal with the [semi] hidden "orig" file in parallel with
the fixed message.
That's not where I'm headed, I want to minimize disruption.
I can see moving the original to ,$messageID when modifying
in place. The user can do what they want with it.
Personally, I'd only use it when something went wrong. If I
wanted to save the original, I wouldn't modify in-place, as
noted above.
David
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers