[Top][All Lists]

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

Re: [Nmh-workers] Future directions for nmh

From: Paul Vixie
Subject: Re: [Nmh-workers] Future directions for nmh
Date: Sat, 12 Mar 2016 14:10:23 -0800
User-agent: Postbox 4.0.8 (Windows/20151105)

Ken Hornstein wrote:
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.

well, yes, but i don't think you realize how deep the reaction went. i despised mhshow, that's true. but i was horrified by mhn and absolutely disgusted by mhl. these apps had byzantine syntaxes and filled my screen with what looked like line printer noise. so when you talk about The MH Way and speak of whatnow having departed from that Way, please realize that whatnow was a choir boy compared to mhn, mhl, and mhshow.

i use show, next, and prev. sometimes scan and pick. and of course rmm. the template .cshrc file i built for my colleagues and myself back at DECWRL, which many of us still use, contains these elements:

alias   mhf     'pick -seq foo -zero'
alias   n       'next +inbox'
alias   p       'prev +inbox'
alias   s       'show +inbox'
alias   rmn     'rmm +inbox;next +inbox'
alias   rmp     'rmm +inbox;prev +inbox'
alias   rpl     'repl -nocc me  -anno -inplace -filter rplfilter +inbox'
alias mhc 'find ~/Mail/. \( -name "address@hidden,]*" -o -name "*~" -o -name ".#*" \) -print | xargs -t /bin/rm'

i think i had some "-nochangecur" options in there at some point. but if any of you guys wondered why i worked so hard to fix the flock bug, it's because i got tired of corrupt "sequences" files whenever i used MH from the shell, from EMH, from uw-imapd, and in my .forward file, all at the same time.

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

that's EDONTCARE for me, for the most part. work flow wise, i'd love to be dropped into a subshell at about the complexity level of sftp or ftp when the message i'm trying to read is full of MIME gravel. that way my primary shell level command would just be "rmn". but if you want to parse the message into some temporary area and then update something like a "context" file in that area as i step through the message using separate shell-level commands, i can adapt.

remember, if i'm being too much of a pain in the ass, ignoring me is OK.

P Vixie

reply via email to

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