>In my humble opinion, mhshow already has too many switches and does too many
>things. In my fantasy, the new version of mhshow (call it 'see' ?) would
>normally take as its stdin the stdout of the new version of mhl (call it
>'mhmime' ?). That is, mhmime would be responsible for understanding a me
Ken Hornstein writes:
>>The same goes for, show, mhshow, next and prev. They should go into nmh-1.7
>>pretty much as is, but deprecated, and be absent from nmh-1.8.
>
>Hm, that's not what I was thinking. I was thinking show, next, and prev
>would still stick around (they wouldn't even change that
>It seems to me it would make the most sense to reuse what code you can
>from the existing tools to create "mhmime" as a library. Then convert
>show, mhl* mhmime etc. to be shims that call it, thusly preserving all
>of the existing user interface of these applications.
We do already have a MH libr
>mhl has baggage that I don't believe that -- nor do I believe that you believe
...
>I think you should be able to design and write the new program unencumbered by
>the encrustations of the past. Of course, if in in writing the new code, you
>want to copy some of the mhl code, the ghost of Dijkstra
>> But it would be good to hear from users; if mhl changed and started
>> (for example) parsing MIME messages and only displaying text parts,
>> would that break things for you?
>
>+1 for that behavior. Instantly mime support in our exmh Environment
>would be there.
Unless you're doing something w
>
> But it would be good to hear from users; if mhl changed and started (for
> example) parsing MIME messages and only displaying text parts, would that
> break things for you?
+1 for that behavior. Instantly mime support in our exmh Environment would be
there.
regards
Andreas
___
n...@dad.org writes:
> Jon Steinhart writes:
>
> >So in general I prefer packages that fix bugs and add features without
> >breaking
> >things because I'm trying to get other work done.
>
> That's a desirable goal, but just one of multiple and conflicting goals.
> Pushing your criterion to the
Ralph Corderoy writes:
> Hi Jon,
>
> > I think that people should have to flip a switch to get the new
> > behavior. Avoids the "breaking things" surprises.
>
> How about the opposite of Python's `from future import ...'? Have a
> ~/.mh_profile entry like `old-fogey' or `stuck-in-1989' as a glo
>>I believe the mhl configuration file is sufficiently expandable enough so
>>that we can continue to use it as-is. Although 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?
>
>mhl has baggage that I d
Jon Steinhart writes:
>So in general I prefer packages that fix bugs and add features without breaking
>things because I'm trying to get other work done.
That's a desirable goal, but just one of multiple and conflicting goals.
Pushing your criterion to the limit, and applying the principle of
ma
Ken Hornstein writes:
>>I like the basic idea. I like it a lot. But the new mhl would be
>>sufficiently different that it should have a new name, to avoid backward
>>compatibility constraints.
>
>I believe the mhl configuration file is sufficiently expandable enough so
>that we can continue to us
Hi Jon,
> I think that people should have to flip a switch to get the new
> behavior. Avoids the "breaking things" surprises.
How about the opposite of Python's `from future import ...'? Have a
~/.mh_profile entry like `old-fogey' or `stuck-in-1989' as a global
decision maker when code changes
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
>> 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
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
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
Ken Hornstein writes:
>>I'm guessing this was done so that MH-E could find the draft that forw
>>created. I can't think of a clean way for MH-E to find the draft if
>>DraftFolder were in use.
>
> Um, yeah ... we added it because you guys asked for it! Well, actually,
> you guys asked for it in c
>I'm guessing this was done so that MH-E could find the draft that forw
>created. I can't think of a clean way for MH-E to find the draft if
>DraftFolder were in use.
Um, yeah ... we added it because you guys asked for it! Well, actually,
you guys asked for it in comp:
http://lists.nongnu.or
Michael Richardson writes:
> I encountered a problem with forw -mime, which is used
> by MH-E.
If mh-compose-forward-as-mime-flag is t.
> It seems that it ignores Draft-Folder. I got caught
> because I happened to have a (empty) ~/Mail/draft as a directory for
> reasons I never figure
>You could use profile entries like mhshow-charset-iso-8859-1 to run a
>script that would run iconv. The script would sometimes get a filename
>and sometimes a command from, e.g, the mhshow-show-text/html profile
>entry so it wasn't simple. It is much much simpler now so thanks for the
>changes. It
Thus spake Ken Hornstein:
>
> Your problem is probably the same one I ran into; isspace() would interpret
> 0xA0 as a non-breaking space and replace it with a "real" space, messing
> up UTF-8 sequences.
>
> This isn't perfect; in a perfect world you'd pull in the bytes and call
> wcwidth() on eac
Ken Hornstein wrote:
> I don't quite understand how you made it work BEFORE 1.6; mhshow wouldn't
> do any character conversion, for one. Also, it still won't reflow text
> that's too wide.
You could use profile entries like mhshow-charset-iso-8859-1 to run a
script that would run iconv. The scrip
Ken wrote:
> Was the replyfilter problem just due to perl package dependencies, or
> something else?
Package dependencies. I ended up with a big mess when
trying to use CPAN. We upgraded the OS version (CentOS) so
I no longer have to deal with that. I resolved the
dependencies by installing th
>replyfilter works fine, having the functionality in C code would
>be nicer. Most of us do many things with nmh with separate scripts,
>including things like signing/encrypting messages. The only thing that
>marks replyfilter out from the rest of these is that you added a special
>hook for it and i
>> Par was a problem for a while, until I finally figured out that the
>> current round of 8-bit patches was the whole problem.
>
>I don't understand. Are you saying that unpatched par works for you on
>anything but ASCII? Unpatched par fails utterly for me on UTF-8.
Not exactly. I am saying that
Ken Hornstein wrote:
> Was the replyfilter problem just due to perl package dependencies, or
> something else?
replyfilter works fine, having the functionality in C code would
be nicer. Most of us do many things with nmh with separate scripts,
including things like signing/encrypting messages. The
Thus spake Ken Hornstein:
>
> Par was a problem for a while, until I finally figured out that the
> current round of 8-bit patches was the whole problem.
I don't understand. Are you saying that unpatched par works for you on
anything but ASCII? Unpatched par fails utterly for me on UTF-8.
--
J.
Ken Hornstein wrote:
>> I encountered a problem with forw -mime, which is used
>> by MH-E. It seems that it ignores Draft-Folder. I got caught
>> because I happened to have a (empty) ~/Mail/draft as a directory for
>> reasons I never figured out.
>>
>> mh-e probably coul
>- I'll echo Norm's request for better repl to MIME messages.
> Maybe replyfilter would do the job. But I tried once and
> couldn't use it due to Perl madness, and haven't gone in to
> figure it out. Also, I'm little wary of depending on par in
> a UTF-8 world: the patch to par to deal with
>I encountered a problem with forw -mime, which is used
>by MH-E. It seems that it ignores Draft-Folder. I got caught
>because I happened to have a (empty) ~/Mail/draft as a directory for
>reasons I never figured out.
>
>mh-e probably could give the explicit -draftfolder option, but it
>was a sur
I encountered a problem with forw -mime, which is used
by MH-E. It seems that it ignores Draft-Folder. I got caught
because I happened to have a (empty) ~/Mail/draft as a directory for
reasons I never figured out.
mh-e probably could give the explicit -draftfolder option, but it
was a surprise.
Hi David,
> - I'll echo Norm's request for better repl to MIME messages. Maybe
> replyfilter would do the job. But I tried once and couldn't use it
> due to Perl madness, and haven't gone in to figure it out. Also, I'm
> little wary of depending on par in a UTF-8 world: the patch to par to
> d
Thus spake Jerrad Pierce:
> >I'll echo Norm's request for better repl to MIME messages.
> >Maybe replyfilter would do the job. But I tried once and
> >couldn't use it due to Perl madness, and haven't gone in to
> >figure it out. Also, I'm little wary of depending on par in
> >a UTF-8 world: the
>I'll echo Norm's request for better repl to MIME messages.
>Maybe replyfilter would do the job. But I tried once and
>couldn't use it due to Perl madness, and haven't gone in to
>figure it out. Also, I'm little wary of depending on par in
>a UTF-8 world: the patch to par to deal with multibyte
- Read messages with binary content. Not a big deal, at least
conceptually. I don't think we need to produce binary
content.
- Lyndon had mentioned static analysis. We've all been chipping
away at things as we trip over them, but a dedicated effort
would be welcome.
- I'll echo Norm's
>Ken Hornstein writes:
>>Since we're HOPEFULLY in the final days/weeks of the 1.6 release cycle,
>>I'm wondering if we should start putting together a wishlist for 1.7.
>>
>>Other thoughts?
>
>Better repl to mime messages?
I think we have something pretty good now with replyfilter (replyfilter
wa
Ken Hornstein writes:
>Since we're HOPEFULLY in the final days/weeks of the 1.6 release cycle,
>I'm wondering if we should start putting together a wishlist for 1.7.
>
>Other thoughts?
Better repl to mime messages?
Norman Shapiro
___
Nmh-workers m
43 matches
Mail list logo
