Re: [Nmh-workers] mhlist output format

[Ken Hornstein]

>first question:  am i correct that mhlist is the only way to
>dump the property tree of a MIME message?

As a standalone utility ... yes, I believe that's correct.  You can get
most of the stuff with varions escapes we have inside of mhshow display
strings.

>so:  any thoughts on whether this sort of "script readable" output
>capability should be added to mhlist?  and, if so, what form should the
>output take?  (xml crossed my mind, but that would make it a lot harder
>for "simple" scripts to parse.)

First thoughts ... yes, we should absolutely do something!  Second
though: I don't love this.  Okay, that's not very helpful, is it?

It just seems .... hm, like it outputs a ton of crap, where you don't
normally need a ton of crap, you need a few small things.  Also, I see
some possible issues in that MIME parameters that contain a " in them
may be problematic.  Rather than just outputting EVERYTHING, we should
be smarter.  I mean, do you care about all MIME parameters?  Or only
specific ones, dependending on the content-type?

I am wondering if maybe it would be more useful to make the output
controllable via mh-format; you could make parameters be components
like they are for non-displayed content markers in mhshow.  Just thinking
out loud here ... I'm not really sure yet what is the "right" thing to do.
Also, I don't know if mhlist is the right place to put this code; maybe
it should go somewhere else, in some new utility.

Robert Elz has made the case before that it's wrong to embed a lot of
functionality into nmh, but it should be done via external scripts.
I don't agree with this sentinment for everything, but it does make sense
for a number of things.  I think we just need to figure out the right
primitives to make this happen.

--Ken