nmh-workers
[Top] [All Lists]

Re: [Nmh-workers] Items for nmh 1.7

2014-06-10 19:16:15
replyfilter works fine, having the functionality in C code would
be nicer. Most of us do many things with nmh with separate scripts,
including things like signing/encrypting messages. The only thing that
marks replyfilter out from the rest of these is that you added a special
hook for it and it is distributed in the contrib directory.

Well, yeah ... but the other solutions all seemed to have some kind of
defect, or they weren't public.  I figured we needed to do distribute
_something_ that was better than nothing.  Like I said at the time, it
was a stop-gap solution.  But it was something that came with nmh and
wasn't too hard to get going (at least, I didn't THINK it was).

Using mhshow piped to sed to add the '> ' prefix does just as good a
job as replyfilter: I've used it that way since before replyfilter
existed and it works even better now with 1.6 (thanks!). Most of the
functionality is sort-of already there in nmh without resorting to perl:
it'd be great of repl (or an mhrepl) could use it.

I don't quite understand how you made it work BEFORE 1.6; mhshow wouldn't
do any character conversion, for one.  Also, it still won't reflow text
that's too wide.

So, here's my thinking.  Traditionally, the job of actually DISPLAYING
messages has been done by mhl.  It seems to make sense that instead of
having two utilities (show and mhshow), there be only one utility: show,
which really uses mhl for it's heavy lifting.

Mhl already has a facility where you can give it information on what
exactly you want to display.  It would make sense to expand this to
encompass various MIME parts.  Here are some sample mhl format file
lines, which I've just shot from the hip and haven't thought about them
too much:

body:match,ct=text/plain,inline,ctparam{format}="flowed":display,flowed
body:match,ct=text/plain,inline:display
body:match,attachment:marker="Part %{part} %{content-type}"

This would let you specify seperate mhl file for replies, and could make
use of existing infrastructure in repl.

Like I said, I haven't thought about this TOO much.  But that's the
general idea.

--Ken

_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

<Prev in Thread] Current Thread [Next in Thread>