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

[Jon Steinhart]

Ken Hornstein writes:
> >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 reading MIME 
> >messages.
> >
> > o  I'd like to eliminate mhlist, mhstore, and mhshow from the ui.
> 
> I can kind of get behind some of that ... those are obvious warts.  Although
> it's not clear what replaces mhstore, since "storing part of message" isn't
> quite a normal operation.  Okay, "show > file.foo" is common, but that
> isn't quite appropriate for a MIME message.
> 
> > o  I'd like to extend message numbers so that 432.1.2 would be part 1.2 of
> >    message number 432.
> 
> Hard right now ... m_convert() takes care of that, and "struct msgs" doesn't
> know about MIME parts.  We'd have to figure out how to add that in there.
> But, it is doable (parsing the syntax will make m_convert hairier).
> 
> > o  I'd like a -mime option to scan that did a more compact (1 line) summary
> >    of each message part.
> 
> Hm.  Also doable, but would require some additional functionality on
> the part of the format engine, and some additional heavy lifting on the
> part of scan.  Also ... what would it look like?
> 
> > o  I'd like the ability to show a message part.
> 
> You can do that now with mhshow ... I will note that Meillo's mmh just
> replaced show with mhshow; that's probably the appropriate medium-term goal.
> 
> > 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.
> 
> Hm, I'm still on the fence with getting rid of mhstore, because to me that's
> a different function to showing.  But I don't have a strong feeling there.
> 
> > 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.
> 
> Ok, makes sense.  But again, would require some work.
> 
> > o  I'd like to be able to override the default handling of a part when shown
> >    on the command line.
> 
> Sure, that makes sense.
> 
> > o  Blasphemy!  I'd like to eliminate mhbuild from the ui even if it lives in
> >    the background.
> 
> I have no love for mhbuild, and like Lyndon says is in a later message, really
> all of the commands need to become MIME-aware.  But we DO want to get 1.6
> out the door eventually, right? :-)
> 
> > o  I'd like to handle forw -mime and repl -mime using new nmh-private 
> > headers
> >    similar to the attach header.
> 
> Hm.  Think about what you really want to happen with repl -mime; I've found
> that replyfilter serves my needs.  Replyfilter is a hack, certainly, but
> a useful stopgap for now.
> 
> > 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.
> 
> I would like to preserve the ability to have mhbuild directives or
> something like them; I don't use it often, but being able to specify the
> content of a MIME message exactly is actually a very cool feature.  I
> know of no other MUA that can do that.
> 
> --Ken

I wasn't suggesting that any of this be done now.  I was suggesting a path to a
better ui so that folks can bicker about it and eventually agree on something
that we could work towards.

Jon