Re: [Nmh-workers] Conflict between "mime" command and attach

[Jon Steinhart]

address@hidden writes:
> Jon Steinhart <address@hidden> writes:
> >Ken Hornstein writes:
> >> >> I will note one thing: I discovered recently that mutt supports an
> >> >> "Attach" header, which does exactly what you'd expect it to do.  So 
> >> >> there
> >> >> is prior art here.
> >> >>
> >> >> --Ken
> >> >
> >> >Humph!  Have to check the logs, I thought that I was the prior art.  
> >> >Humbug.
> >>
> >> My mistake; I believe you were first.  My key point was that we aren't the
> >> only ones doing that.
> >>
> >> --Ken
> >
> >Whew!  Now that that's out of the way, I'll stick my neck out on what I'd 
> >like
> >to see...
> >
> >The worst part to me (since attach was added) in nmh is readingMIME messages.
> >
> >o  I'd like to eliminate mhlist, mhstore, and mhshow from the ui.
> >
> >o  I'd like to extend message numbers so that 432.1.2 would be part 1.2 of
> >message number 432.
> >
> >o  I'd like a -mime option to scan that did a more compact (1 line) summary
> >of each message part.
> >
> >o  I'd like the ability to show a message part.
> >
> >o  If it's not enough to show a message part and redirect the output to a
> >file then there should be a -store option on show.
> >
> >o  There should be a -part option to show, and the ability to do next -part
> >and prev -part, and alias support for nextp and prevp commands.
> >
> >o  I'd like to be able to override the default handling of a part when shown
> >on the command line.
> >
> >On the composition and sending side.
> >
> >o  Blasphemy!  I'd like to eliminate mhbuild from the ui even if it lives in
> >the background.
> >
> >o  I'd like to handle forw -mime and repl -mime using new nmh-private headers
> >similar to the attach header.
> >
> >o  While it would be nice to be able to have mhbuild-like options on the 
> >attach
> >command, I don't think that they're really needed.  In the worst case, if a
> >message is received that has the wrong mime-type, one can override that on
> >the show command line (above).  Beats having to do it in an editor which is
> >what happens today.
> >
> >There!  Do your worst!
> 
> Almost certainly, had MH been invented today, Mime parts would have been
> stored in separate files, and messages would have been stored as directories.
> One of the very early on considerations, (before Bruce Borden came on), was
> efficiency, given that we were time sharing a PDP 1145. Further, MIME was
> decades in the future.
> 
> I don't how mime parts would have been named. Naming messages as digit strings
> was a decision that came later.
> 
> BUT all that says very little about how to morph nmh from what we have now, to
> something that will do Mime well.
> 
> Your proposal, above, strikes me as too radical a change.
> 
>     Norman Shapiro

You're just an old reactionary :)

I like having mime messages in a single file.  I can move 'em around and not 
worry
about gathering all of the parts.

As with my attach addition which is way more contentious now than it was when I
implemented it, my proposal on side is compatible with the existing ui.  It 
would
look the same if you didn't turn on any of the "new" options.  Could even leave
mhlist et. al. in place for any who love 'em.  It's true to the "don't break
things" philosophy.

The attach thing is interesting to me socially because even you mhbuild-lovers 
are
using attach; the beef seems to be that attach and mhbuild are not as compatible
as you'd like.  So you've already allowed yourselves to be seduced by the dark 
side.

Jon