[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: |
Sat, 09 Feb 2013 12:27:53 -0500 |
Harald wrote:
> [Ralph:]
> > I'm not a w3m user but I think that formats the HTML into text? I was
> > interested in a base64 windows-1252 text/plain staying as text/plain but
> > utf-8 and 8-bit. IOW, ideal for grep.
>
> Me too, but probably that would be a different tool?
Right. Any external tools are selected as mhshow does using the
existing profile/mhn.defaults mechanism.
> Personally I care about the message in it's most usable form and not
> about the original, but I can see that keeping the original might be
> a sensible thing to do, so what I believe would be useful is some new
> tool mhfoo, which at the minimum would do:
>
> mhfoo [msgs] +folder
> write msgs (default cur) into folder in "preferred form"
Here's where I'm headed:
mhfixmsg [+folder [msgs] | -file file] [-outfile file]
Stdin/stdout can be specified with -
msfixmsg transforms the msg/file in place and keeps a backup
(your keeporig). For the backup:
Attempt to backup the input file using the directory found by:
1) If input is a message, the folder of the message.
2) If input is a file, the directory of the file.
3) If input is standard input, the user's MH Path directory.
and using one of these for the filename, in order:
1) Message-ID with all / converted to periods, if file does
not already exist.
2) Message-ID with all / and \ converted to periods, if file
does not already exist. (Need this for Windows.)
3) Concatenation of BACKUP_PREFIX (usually ",") and input
filename. For stdin, that is a tmp filename of form
mhfixmsg-XXXXXX.
If unable to backup the message, then it will not be modified
and failure will be reported.
To put a transformed message into a different folder, I'd use
-outfile - | rcvstore +folder.
> inc -mhfoo [-keeporig +folder]
> rebuild any messages into "preferred form" during incorporating and
> only keeping the original around if the -keeporig option is present.
Phase II :-) Phase I is to get mhfixmsg into nmh without
touching existing programs.
> (I probably would have something like 'inc: --mhfoo' in my .mh_profile)
>
> I think "preferred form" obviously is utf-8 and 8bit today, I'm less sure
> what I'd like to happen to multipart messages (with non-text parts).
All transformations are disabled by default in mhfixmsg and
enabled on the command line or in the profile. It decodes to
8bit. I'll personally go to UTF-8, too, but I'd like to keep it
general.
> I guess that pretty much depends how the rest of nmh is going to handle
> those in the future. I'm also undecided on whether "preferred form"
> includes headers to properly mark the message as 8bit as if it was
> actually sent that way.
I hadn't thought about keeping the old C-T-E header when
decoding base64 or Q-P, but I suppose it could. At this point,
I don't see the value in that, as noted in my message earlier
today about Valdis's observation.
David
- Re: [Nmh-workers] message rewrite/fix up, (continued)
- Re: [Nmh-workers] message rewrite/fix up, David Levine, 2013/02/04
- Re: [Nmh-workers] message rewrite/fix up, David Levine, 2013/02/05
- Re: [Nmh-workers] message rewrite/fix up, David Levine, 2013/02/09
- Re: [Nmh-workers] message rewrite/fix up, David Levine, 2013/02/09
- Re: [Nmh-workers] message rewrite/fix up,
David Levine <=
- Re: [Nmh-workers] message rewrite/fix up, David Levine, 2013/02/09
- Re: [Nmh-workers] message rewrite/fix up, David Levine, 2013/02/09
- Re: [Nmh-workers] message rewrite/fix up, David Levine, 2013/02/10
- Re: [Nmh-workers] message rewrite/fix up, David Levine, 2013/02/10
- Re: [Nmh-workers] message rewrite/fix up, David Levine, 2013/02/10