[Top][All Lists]

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

Re: [Nmh-workers] Future directions for nmh

From: Ken Hornstein
Subject: Re: [Nmh-workers] Future directions for nmh
Date: Sat, 12 Mar 2016 10:43:30 -0500

>i don't know exactly how to match mime to the simplicity of show(1), and 
>i've been violently repulsed any time i tried to use mhshow(1), but i 

I can't really blame you on that one.  But really, mhshow(1) is really just
the old mhn, slightly rewritten.  And mhn was a horrible hack, we all agree.
We've made it suck less.  But my thinking has always been that mhshow goes
away, and mhl be the "display message" command ... you know, like it used
to be.

>the command set i'd suggest for whatnowmime(1) would include things like:

Alright, I see where you're going with this.  Fair enough; that's not
how I personally work with MIME messages, but enough people have said
that they want this (and Paul even wrote something that does it!) that
clearly this UI fills a need.

But ... let's take a step back.  I've heard that "whatnow" is a Horrible
Corruption of the MH way, in that everything should be a distinct
command rather than create a shell that does a bunch of commands.  I
find that argument compelling; any shell we create will lack the full
power of a command shell, and I'm assuming we don't want to cram all of
/bin/sh into nmh.  So do you (and others) really want a "MIME shell",
or do you just want a bunch of commands to operate on MIME parts?  I
do recognize that there is the issue of command collision, so that's
one concern.  Technically, I see no obvious challenge in doing it as
individual commands; there would be some file in $(mhdir) that would
hold current part you're working on, like context today.

If the message parser is done right, mhl would just be a special case of
your "view" command.  Or view would be mhl; details are still a bit


reply via email to

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