[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] message rewrite/fix up

From: David Levine
Subject: Re: [Nmh-workers] message rewrite/fix up
Date: Mon, 04 Feb 2013 21:05:58 -0500

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

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:

  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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]