Ken wrote:
> I guess my points are:
>
> - Looking back at the actual implementation, it is clear (to me at least)
> that the parts were reversed to make it simpler on the code that displayed
> multipart/alternatives; it was easy enough to bail out when it found
> the first one that was the
>> It's obvious that was done because otherwise, you could never give a
>> consistent -part switch (it wouldn't make any sense if mhlist showed
>> a part number of 1, but in mhshow it was really 2).
>
>I don't follow, but that doesn't matter. It makes
>sense to me the way it is now, so I don't wan
I wrote:
> Also, replyfilter gets installed without execute permission,
> because INSTALL_DATA has -m 644.
I changed dist_contrib_DATA to dist_contrib_SCRIPTS in Makefile.am
and that fixed the permissions. All of the current contribs are
scripts.
David
_
Ken wrote:
> >> Meh. Everywhere else nmh presents MIME parts in the order in
> >> which they occur in the message; from what I can tell,
> >> multipart/alternative was reversed just so the display code
> >> would be easier to write. This seems like a lousy exception.
> >
> >mhlist is a counterex
Ken Hornstein writes:
> >> So you want the default behavior of mhl to simply dump out the complete
> >> body of a message, without doing any MIME decoding at all? That just
> >> seems lousy to me, and also incredibly non-useful. Are people depending
> >> on that behavior?
> >
> >Well yeah, I thin
>> Sigh; that would give us a perl dependency; I wasn't really ready
>> for that just yet.
>
>Just to note that rpm and yum are ready. rpm digs into perl
>code, figures out dependencies, and embeds the info in the rpm:
>[...]
I guess I was really hoping that the next version of nmh will have most
>> So you want the default behavior of mhl to simply dump out the complete
>> body of a message, without doing any MIME decoding at all? That just
>> seems lousy to me, and also incredibly non-useful. Are people depending
>> on that behavior?
>
>Well yeah, I think that people should have to flip
>> Meh. Everywhere else nmh presents MIME parts in the order in
>> which they occur in the message; from what I can tell,
>> multipart/alternative was reversed just so the display code
>> would be easier to write. This seems like a lousy exception.
>
>mhlist is a counterexample. And a good one.
Ken Hornstein writes:
> >OK, I may be too busy to contribute at the moment but I can't ignore
> >provocative messages like this one :)
>
> I hope you realize that was all in good fun; I really wish we never broke
> anything, but I don't think it's avoidable.
Yes, I do. No problem.
> >I don't u
Ken wrote:
> >Also, I had to use yum to install several non-standard perl modules.
>
> Well, there's no standard as to what's standard ... those modules
> all ship with the system-supplied perl here. The other comments
> about the problems gettng it running are well taken; clearly there
> are so
Ken wrote:
> [David:]
> >
> >Best-first has some appeal to me: I start at the top, see
> >text/html or something else I can handle, and go with that
> >without bothering to look at the other alternatives.
>
> Meh. Everywhere else nmh presents MIME parts in the order in
> which they occur in the
Jon wrote:
> The message displays just fine, but when I reply to it the original
> message doesn't get decoded; it's included as base-64. I also
> notice this with some other messages that are quoted/printable with
> the = stuff. Is there some way to make this work that I just
> haven't taken th
>OK, I may be too busy to contribute at the moment but I can't ignore
>provocative messages like this one :)
I hope you realize that was all in good fun; I really wish we never broke
anything, but I don't think it's avoidable.
>I don't use any custom mhl so I'm fine if it changes. *BUT*, I think
Ken Hornstein writes:
> >>>I guess my question
> >>to you would be, if we had a new mhl-like program that was MIME-aware,
> >>why would you want to keep the old mhl around?
> >
> >Only to not break any scripts out there, that use it.
>
> As much as I love tormenting Jon Steinhart every time we cha
>>>I guess my question
>>to you would be, if we had a new mhl-like program that was MIME-aware,
>>why would you want to keep the old mhl around?
>
>Only to not break any scripts out there, that use it.
As much as I love tormenting Jon Steinhart every time we change something
in a new nmh release,
Ken Hornstein writes:
>>I guess my question
>to you would be, if we had a new mhl-like program that was MIME-aware,
>why would you want to keep the old mhl around?
Only to not break any scripts out there, that use it.
Norman Shapiro
___
Nmh-worker
>So, ALL nmh responsibility for parsing and extracting mime parts would be in
>[what mhl would become]. None would be in show, mhshow, repl, or anywhere else
>Correct?
Yeah, exactly. Really, I view it as getting back to the core MH architecture.
When you look at the complete toolset, show's job w
Ken Hornstein writes:
(10 weeks ago)
>So, here's my thinking. Traditionally, the job of actually DISPLAYING
>messages has been done by mhl. It seems to make sense that instead of
>having two utilities (show and mhshow), there be only one utility: show,
>which really uses mhl for it's heavy lift
Hi Ken,
> > I know there are few nmh programmers that haven't coded assember,
> > but -outsize is something only a programmer could like. :-)
>
> Sigh. fmttest(1) really is designed to be able to exercise the
> details of the format engine.
Oh, I think it's fine for that, just not suitable to
19 matches
Mail list logo
