[Top][All Lists]

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

Re: [Nmh-workers] Items for nmh 1.7

From: norm
Subject: Re: [Nmh-workers] Items for nmh 1.7
Date: Wed, 20 Aug 2014 09:18:14 -0700

Ken Hornstein <address@hidden> writes:

>>The same goes for, show, mhshow, next and prev. They should go into nmh-1.7
>>pretty much as is, but deprecated, and be absent from nmh-1.8.
>Hm, that's not what I was thinking. I was thinking show, next, and prev
>would still stick around (they wouldn't even change that much). They'd get
>some new switches that mhshow had (and presumably pass them down to mhl).'

I believe that what I say below is consistent with your original message,
which is where I got the idea. I hope and believe that not much more coding
than you envisioned is entailed, though perhaps some refactoring might be

In my humble opinion, mhshow already has too many switches and does too many
things. In my fantasy, the new version of mhshow (call it 'see' ?) would
normally take as its stdin the stdout of the new version of mhl (call it
'mhmime' ?). That is, mhmime would be responsible for understanding a message,
and see would be responsible for displaying the message to a user. So the
switches to mhmime would control how the message was interpreted and the
switches to see would control how the message was displayed.

In the era when MH began, interpretation was trivial, so it was not perceived
as a special function. Though, perhaps even then, it should have been. In
retrospect it is clear (at least to guy like me who doesn't have to write the
code :-) ) that interpretation and display are separate functions and should
be furnished by separate commands. "Do one thing and do it well".

    Norman Shapiro

reply via email to

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