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
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers