[Top][All Lists]

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

Re: [Nmh-workers] Items for nmh 1.7

From: Ken Hornstein
Subject: Re: [Nmh-workers] Items for nmh 1.7
Date: Tue, 10 Jun 2014 19:57:18 -0400

>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,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.


reply via email to

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