Re: [Nmh-workers] Items for nmh 1.7
Ken Hornstein k...@pobox.com 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 much). They'd get some new switches that mhshow had (and presumably pass them down to mhl).' I believe that what I say below is consistent with your original message, which is where I got the idea. I hope and believe that not much more coding than you envisioned is entailed, though perhaps some refactoring might be involved. 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 message, and see would be responsible for displaying the message to a user. So the switches to mhmime would control how the message was interpreted and the switches to see would control how the message was displayed. In the era when MH began, interpretation was trivial, so it was not perceived as a special function. Though, perhaps even then, it should have been. In retrospect it is clear (at least to guy like me who doesn't have to write the code :-) ) that interpretation and display are separate functions and should be furnished by separate commands. Do one thing and do it well. Norman Shapiro ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
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 message, and see would be responsible for displaying the message to a user. So the switches to mhmime would control how the message was interpreted and the switches to see would control how the message was displayed. Well, my view was that the relationship between show and mhl is kind of like send and post; send has a lot of switches, but most of them are passed down to post. send takes care of picking the message, doing some MIME processing if necessary, but the actual message submission gets done by post. Also, some practical concerns arise: - As we've seen in repeated examples, people don't read the documentation about new commands or features. So if new commands are required to handle MIME messages (and nowadays, that's pretty much all of them) then they will get little use and people will continue to think our MIME support is lousy. I think our experience with show in 1.6 has shown we can do better with the existing interface. - I'm unclear about what exactly these new mhmime and see commands are going to do, exactly. Right now 'show' handles things at the folder level; you give it a folder, message numbers, sequence names, and it handles folder level tasks like interpreting sequence names, removing messages from the unseen sequence, etc etc. mhl takes filenames from show and interpets them and displays them. My proposal is really about making mhl smarter. But I don't know what 'mhmime' is supposed to output; the interpreted MIME contents of the message? Would that be some more structured content of the message? Just the text parts, like mhshow does now by default? What would this 'see' command exactly be doing? --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
Jon Steinhart j...@fourwinds.com 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 mathematical induction, it would mean that a Makefile that worked in 1970 should work today. It would make progress virtually impossible, particularly for a system maintained entirely by volunteers. Norman Shapiro ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
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 don't believe that -- nor do I believe that you believe -- the new program (call it mhmime) should have. Examples are the output and terminal related stuff, -bell, -clear, -length, -width, -moreproc, which have nothing to do with parsing mime stuff. I can't argue that (-bell is clearly the biggest offender), but consider the flip side ... someone has to write that new program from scratch. It might be easier to simply rototill mhl to add the new features. Also, I believe -length and -width might be useful if you wanted to override the default terminal size (although if you're deprecating -clear and -bell, you don't need -length, I believe). Our hypothetical new mhl program would still use a pager, so you'd still need -moreproc. 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 much). They'd get some new switches that mhshow had (and presumably pass them down to mhl). mhshow would just become show. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
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 global decision maker when code changes to support both old and new ways. Wouldn't help when the code to support `old' is being discarded because keeping both isn't practical, but for the smaller choices of defaults, etc., you could set the flag once and then forget about it? Cheers, Ralph. That would be fine. In this case, the change won't affect me. But, if someone has a pile of mhn that they depend on it would be nice to give them some time to convert instead of just creating an emergency for them. Jon ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
n...@dad.org writes: Jon Steinhart j...@fourwinds.com 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 mathematical induction, it would mean that a Makefile that worked in 1970 should work today. It would make progress virtually impossible, particularly for a system maintained entirely by volunteers. Norman Shapiro As you can see from my other emails, I'm not trying to push it to the limit. And I still have Makefiles from way back and they do work. Shell scripts too. C programs. All of which have had features larded on them since. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
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 ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
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 wrong, you should already have MIME support in exmh; it's been mostly MIME capable for a number of years now. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
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 will forgive you. 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. 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. * This would probably not expose all of he library's functionality, and that's okay. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
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 library (libmh.a) that's built (but not installed) and has the common functions in it. It was my plan to put the new MIME parsing routines in there. But the applications in general can't be shims; show and mhl, for example, do very different things. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
Ken Hornstein k...@pobox.com 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 lifting.
Mhl already has a facility where you can give it information on what
exactly you want to display. It would make sense to expand this to
encompass various MIME parts. Here are some sample mhl format file
lines, which I've just shot from the hip and haven't thought about them
too much:
body:match,ct=text/plain,inline,ctparam{format}=flowed:display,flowed
body:match,ct=text/plain,inline:display
body:match,attachment:marker=Part %{part} %{content-type}
This would let you specify seperate mhl file for replies, and could make
use of existing infrastructure in repl.
Like I said, I haven't thought about this TOO much. But that's the
general idea.
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?
You didn't say so, but I take it that the results of the new program, would
also be available for other, user created, purposes.
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.
Write programs that do one thing and do it well.
http://en.wikipedia.org/wiki/Unix_philosophy. I urge the community to
explicate Ken's general idea.
Norman Shapiro
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
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 was to pick out a message for you to display, but mhl did the actual work of displaying that message. MH's original MIME support kind of busted that model; you had a new program that handled these weird (and at the time, rare) messages. mhl wouldn't handle these messages, this other utility took care of it. But now that MIME messages are the norm, mhl isn't used so much and that causes us problems ... the fact that mhl isn't MIME-aware makes things hard for when we deal with MIME replies, leading to things that aren't so wonderful, like replyfilter. You didn't say so, but I take it that the results of the new program, would also be available for other, user created, purposes. Sure, just the same way that mhl is available now. 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 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? --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
Ken Hornstein k...@pobox.com 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-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
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, I'm trying to understand what would break. Well, okay, I'm sure something somewhere will break for someone. But I think if we have an old-style mhl configuration file around we can revert to the previous behavior. 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? --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
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 change something in a new nmh release, I'm trying to understand what would break. Well, okay, I'm sure something somewhere will break for someone. But I think if we have an old-style mhl configuration file around we can revert to the previous behavior. 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? --Ken OK, I may be too busy to contribute at the moment but I can't ignore provocative messages like this one :) I don't use any custom mhl so I'm fine if it changes. *BUT*, I think that the default behavior after the change should be the same as the default behavior today unless there's a good reason to change it. It would probably be nice for heavy mhl users to have a converter from old to new. BTW, this may just be laziness on my part, but one thing that really annoys me these days is receiving an email sent from a phone. 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 the trouble to do? If so, please clue me in. If not, it's something that I think needs to be addressed. Jon ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
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 that the default behavior after the change should be the same as the default behavior today unless there's a good reason to change it. It would probably be nice for heavy mhl users to have a converter from old to new. 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? BTW, this may just be laziness on my part, but one thing that really annoys me these days is receiving an email sent from a phone. 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 the trouble to do? If so, please clue me in. If not, it's something that I think needs to be addressed. If I was a smart-ass, I'd say, Boy, you really DON'T read the release notes, do you? :-) But yes, there's been a solution since 1.5 came out. It's called replyfilter, and it's in the nmh contrib directory; it should be part of your install. If you look at it, it will contain directions on how to set it up. There was even a recent email thread about people trying to use it (but ultimately Norm decided he didn't want to use it). I won't claim it's perfect, but I use it every day and it's a whole lot better than it used to be. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
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 the trouble to do? mhfixmsg, new with nmh 1.6, can decode those parts. I decode incoming messages using procmail recipes similar to the man page example. It should work with slocal, too. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
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 use any custom mhl so I'm fine if it changes. *BUT*, I think that the default behavior after the change should be the same as the default behavior today unless there's a good reason to change it. It would probably be nice for heavy mhl users to have a converter from old to new. 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 a switch to get the new behavior. Avoids the breaking things surprises. BTW, this may just be laziness on my part, but one thing that really annoys me these days is receiving an email sent from a phone. 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 the trouble to do? If so, please clue me in. If not, it's something that I think needs to be addressed. If I was a smart-ass, I'd say, Boy, you really DON'T read the release notes, do you? :-) But yes, there's been a solution since 1.5 came out. It's called replyfilter, and it's in the nmh contrib directory; it should be part of your install. If you look at it, it will contain directions on how to set it up. There was even a recent email thread about people trying to use it (but ultimately Norm decided he didn't want to use it). I won't claim it's perfect, but I use it every day and it's a whole lot better than it used to be. --Ken Well you're right, I don't. And you are a smart-ass :-) I have thousands of packages installed on my system that get auto-updated daily. It would be a full time job to look at the release notes for every update. Not gonna happen. So in general I prefer packages that fix bugs and add features without breaking things because I'm trying to get other work done. Jon ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
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 a switch to get the new behavior. Avoids the breaking things surprises. The problem I have with that is ... it just sucks. I can't imagine that anyone thinks the current behavior of mhn on MIME messages is reasonable. Based on previous experience, I am sure someone relies on mhl _not_ doing any MIME parsing, but I can't accept that as a reasonable default. Can you really imagine a new nmh user (okay, we don't get many of those, but pretend that we do!) sitting down and coming to the realization that to handle pretty much any modern email messages, they have to configure something? That just sounds terrible, and I can't really defend that behavior. That's why now mhshow will now do character set conversion by default, as opposed to having to configure every single character set you wanted to convert manually. Yeah, it may break something; I've written about the balancing act we have between trying to maintain backwards compatibility and moving nmh forward. I just don't think having out-of-the-box behavior that is simply wrong when it comes to MIME messages is reasonable in this day and age. But I'm willing to hear from opposing viewpoints; where we draw the line between backwards compatibility and moving things forward (but possibly breaking things for people) is something that needs to be decided on a case-by-case basis. So I am interested in hearing what people think about changes, and I believe that for every change that I knew would break something for someone I did solicit feedback here. Unfortunately, the situation we're left with is that nmh really has it's roots in MH, but unfortunately development stalled on MH at a crucial time when MIME email was starting to take off. The code was reorganized and mhn was split off into a bunch of utilities, but hard decisions about what to do with MIME email never got made, and in the intervening decades people developed their own workarounds to deal with the lousy MIME support. This is what we're grappling with now. Well you're right, I don't. And you are a smart-ass :-) I have thousands of packages installed on my system that get auto-updated daily. It would be a full time job to look at the release notes for every update. Not gonna happen. So in general I prefer packages that fix bugs and add features without breaking things because I'm trying to get other work done. But see, this kind of proves my point. Wouldn't it have been nice if repl just started dealing with MIME email out of the box, rather than you having to configure it? But a huge change like that would have broken something for someone. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
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 think that people should have to flip a switch to get the new behavior. Avoids the breaking things surprises. The problem I have with that is ... it just sucks. I can't imagine that anyone thinks the current behavior of mhn on MIME messages is reasonable. Based on previous experience, I am sure someone relies on mhl _not_ doing any MIME parsing, but I can't accept that as a reasonable default. Can you really imagine a new nmh user (okay, we don't get many of those, but pretend that we do!) sitting down and coming to the realization that to handle pretty much any modern email messages, they have to configure something? That just sounds terrible, and I can't really defend that behavior. That's why now mhshow will now do character set conversion by default, as opposed to having to configure every single character set you wanted to convert manually. Yeah, it may break something; I've written about the balancing act we have between trying to maintain backwards compatibility and moving nmh forward. I just don't think having out-of-the-box behavior that is simply wrong when it comes to MIME messages is reasonable in this day and age. But I'm willing to hear from opposing viewpoints; where we draw the line between backwards compatibility and moving things forward (but possibly breaking things for people) is something that needs to be decided on a case-by-case basis. So I am interested in hearing what people think about changes, and I believe that for every change that I knew would break something for someone I did solicit feedback here. Unfortunately, the situation we're left with is that nmh really has it's roots in MH, but unfortunately development stalled on MH at a crucial time when MIME email was starting to take off. The code was reorganized and mhn was split off into a bunch of utilities, but hard decisions about what to do with MIME email never got made, and in the intervening decades people developed their own workarounds to deal with the lousy MIME support. This is what we're grappling with now. Well you're right, I don't. And you are a smart-ass :-) I have thousands of packages installed on my system that get auto-updated daily. It would be a full time job to look at the release notes for every update. Not gonna happen. So in general I prefer packages that fix bugs and add features without breaking things because I'm trying to get other work done. But see, this kind of proves my point. Wouldn't it have been nice if repl just started dealing with MIME email out of the box, rather than you having to configure it? But a huge change like that would have broken something for someone. --Ken Well, in this specific case I guess that I could consider it a bug fix so it would be OK. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
Michael Richardson m...@sandelman.ca 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 figured out. mh-e probably could give the explicit -draftfolder option, but it was a surprise. (Maybe I'm mis-diagnosing the problem, twoo) Nope, you are spot-on. And it's not because of the -mime option. And it's not MH-E that is putting the draft in draft, it is forw's handling of the -build option, which is used by MH-E. From forw(1): The -build switch is intended to be used by the Emacs mh-e interface to nmh. It implies -nowhatnowproc. It causes a file mh-dir/draft to be created, contain‐ ing the draft message that would normally be presented to the user for editing. No mail is actually sent. 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. p.s. Calling in sick again today. Only a month behind and 227 more messages to go. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
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.org/archive/html/nmh-workers/2013-10/msg00013.html It was already there in forw and repl; shouldn't this be a non-problem? If it's busticated, we should fix it (just tested it and it seems to work fine for me). --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
Ken Hornstein k...@pobox.com 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 comp: http://lists.nongnu.org/archive/html/nmh-workers/2013-10/msg00013.html It was already there in forw and repl; shouldn't this be a non-problem? If it's busticated, we should fix it (just tested it and it seems to work fine for me). No, it's working perfectly. By now, Michael has run rmdir draft and has completely forgotten about the issue :-). -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
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 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 doesn't reflow text but that's easy from vim with formatprg
set to par.
Mhl already has a facility where you can give it information on what
exactly you want to display. It would make sense to expand this to
encompass various MIME parts. Here are some sample mhl format file
lines, which I've just shot from the hip and haven't thought about them
too much:
body:match,ct=text/plain,inline,ctparam{format}=flowed:display,flowed
This is more flexible than what we have for mhshow (being able to match
content-type and disposition flags). So this could also benefit mhshow.
The trailing ,flowed could perhaps be handled instead as something
like filter=par. But, it then starts looking inconsistent with the use of
things like mhshow-show-text/html which is specifying a sort-of external
filter in a different way.
body:match,ct=text/plain,inline:display
body:match,attachment:marker=Part %{part} %{content-type}
One thought with the marker is that it could be inserted in the form of
a #forw mhbuild directive. You could then choose to include individual
attachments in a reply (or forward). The only problem is that #forw
doesn't support selecting individual message parts: only a whole
message. Currently forwarding messages with attachments is something
that could be better which this might achieve.
Oliver
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
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 each Unicode character, but it works good enough for me in practice. Thanks for the explanation. I intend to have a look at par again soonish and try to get it right with multibyte characters once and for all. -- J. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
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 doesn't reflow text but that's easy from vim with formatprg
set to par.
I was aware of that, but in practice I found it terrible since you had
to explicitly list every character set.
This is more flexible than what we have for mhshow (being able to match
content-type and disposition flags). So this could also benefit mhshow.
The trailing ,flowed could perhaps be handled instead as something
like filter=par. But, it then starts looking inconsistent with the use of
things like mhshow-show-text/html which is specifying a sort-of external
filter in a different way.
Well, this is still a work in progress. I was idly thinking this
morning about a concept called modules. You could have modules for
different content types, modules for different transfer encodings,
modules for charset conversions, etc etc. They'd be strung together to
generate the content however you would like. Well, the underlying
MIME structure really means that you'd have to deal with them in a certain
order. You need to decode the transfer encoding first, do any character
set conversion next, then feed it into your content handler. My thinking
was that you could substitute any of your own modules for the nmh internal
ones at some point. Again, this is all sort of vague.
body:match,ct=text/plain,inline:display
body:match,attachment:marker=Part %{part} %{content-type}
One thought with the marker is that it could be inserted in the form of
a #forw mhbuild directive. You could then choose to include individual
attachments in a reply (or forward). The only problem is that #forw
doesn't support selecting individual message parts: only a whole
message. Currently forwarding messages with attachments is something
that could be better which this might achieve.
The big problem I see with this is you can't forward a specific
attachment from a #forw directive ... also, I think that putting an
mhbuild directive in the draft is kind of lousy. Fine if people
want to do it, but not something I'd want to do regularly. But the
functionality would undoubtedly be useful; we'd just need to think about
how to make it work.
--Ken
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
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 patch to par to deal with multibyte characters has a known problem. PAR would help in this case, it bundles a perl script and its dependencies into a single executable for easy distribution. par isn't very much code, and it produces pleasing results. I've already hacked on it a bit to fix a problem with the UTF-8 patch. There's still one probelm I know of which I haven't had time to investigate, but with the modified patch it mostly works. I likely will come back to that sometime this summer. I'd prefer that we fix the problem with par rather than dumping it. -- J. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
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 deal with multibyte characters has a known problem. Makes me wonder if Ken's new `view MIME email as one stream' code can be put to use with an alternative set of helpers that produce the parts formatted for reply instead of viewing. Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
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. (Maybe I'm mis-diagnosing the problem, twoo) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
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. MH-E ignores Draft-Folder, or forw -mime ignores it? I use forw -mime with a draft folder and it works just fine. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
- 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 characters has a known problem. Was the replyfilter problem just due to perl package dependencies, or something else? Par was a problem for a while, until I finally figured out that the current round of 8-bit patches was the whole problem. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
Ken Hornstein k...@pobox.com 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 could give the explicit -draftfolder option, but it was a surprise. MH-E ignores Draft-Folder, or forw -mime ignores it? I use forw -mime with a draft folder and it works just fine. mh-e doesn't specify a draft-folder, and it seems that forw -mime otherwise ignores it. I will try again with the tip-of-git-tree. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
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 the various i18n patches were an utter failure for me. I use the par out of MacPorts, and the key patch is this: --- ./par.c.orig2001-04-01 23:25:57.0 -0500 +++ ./par.c 2012-04-15 13:56:42.0 -0500 @@ -403,7 +403,8 @@ } continue; } - if (isspace(c)) ch = ' '; + // Exclude non-breaking space from the class of space chars + if (isspace(c) isascii(c)) ch = ' '; else blank = 0; additem(cbuf, ch, errmsg); if (*errmsg) goto rlcleanup; 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 each Unicode character, but it works good enough for me in practice. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
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 it is distributed in the contrib directory.
Well, yeah ... but the other solutions all seemed to have some kind of
defect, or they weren't public. I figured we needed to do distribute
_something_ that was better than nothing. Like I said at the time, it
was a stop-gap solution. But it was something that came with nmh and
wasn't too hard to get going (at least, I didn't THINK it was).
Using mhshow piped to sed to add the ' ' prefix does just as good a
job as replyfilter: I've used it that way since before replyfilter
existed and it works even better now with 1.6 (thanks!). Most of the
functionality is sort-of already there in nmh without resorting to perl:
it'd be great of repl (or an mhrepl) could use it.
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.
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 lifting.
Mhl already has a facility where you can give it information on what
exactly you want to display. It would make sense to expand this to
encompass various MIME parts. Here are some sample mhl format file
lines, which I've just shot from the hip and haven't thought about them
too much:
body:match,ct=text/plain,inline,ctparam{format}=flowed:display,flowed
body:match,ct=text/plain,inline:display
body:match,attachment:marker=Part %{part} %{content-type}
This would let you specify seperate mhl file for replies, and could make
use of existing infrastructure in repl.
Like I said, I haven't thought about this TOO much. But that's the
general idea.
--Ken
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
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 these RPMs: perl-MailTools perl-MIME-tools So now I can play with it, but that'll be another day. I do agree with Oliver that it would be nicer to have it integrated into nmh. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
Ken Hornstein k...@pobox.com 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 mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
Ken Hornstein k...@pobox.com 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 was introduced as part of 1.5; see the NEWS file for more information). If we had a better MIME data model, it would be easier for things like mhl to say, include all text parts in the reply. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
- 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 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 characters has a known problem. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
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 characters has a known problem. PAR would help in this case, it bundles a perl script and its dependencies into a single executable for easy distribution. Text::Wrap might also provide aufficient features to replace par. I'll try to look into this. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
