Re: [Nmh-workers] Conflict between mime command and attach
Ken wrote: Jon wrote: My opinion is that having special characters in the body is bad, like crossing the beams. It was a good hack at the time but should be put out of our misery. I think that all MIME composition should be done via headers. ... It's fine for 90% of what people normally want to do. It's just the rest of the stuff ... like creating multiparts like multipart/alternative, or external-body references, or if you want to create HTML and specify the Content-ID of attachments exactly. Not many people want to do that, it's true. I'm not sure how we do that in headers easily. It clearly can't be done at the moment and, yes, it isn't obvious how it could be done without adding some kind of positional information to the headers, e.g. location strings and then putting those same magic markers in the body. That's more tedious than today's /^#/ method. For us 10%-ers, leave our # alone, or at least the method. Allow the # to be configurable if you want, especially if it allows UTF-8 runes, `␛applcation/pdf; name=...' any one? :-) Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
resurrecting an old thread, but a continuing issue... ken wrote: - I use to run with automimeproc set. But that's lousy; if you include C code in your text, it fails. Totally non-obvious and I always forget it. It got to be such a problem that I turned it off. i don't recall us ever discussing the possibility of making the '#' character that introduces mhbuild directives configurable by the user. for instance, if the leading character were '}', i don't think i would ever have a conflict with real text. interpretation of those directives is strictly within mhbuild, correct? no leakage into other mh commands? paul -- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 72.3 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
i don't recall us ever discussing the possibility of making the '#' character that introduces mhbuild directives configurable by the user. for instance, if the leading character were '}', i don't think i would ever have a conflict with real text. interpretation of those directives is strictly within mhbuild, correct? no leakage into other mh commands? There used to be some leakage; for example, the old attach implementation would parse the Nmh-Attachment headers and then create mhbuild directives. I am not sure there is any leakage now. But I am not in love with the idea of changing the leading character, because that opens the box for how should we do MIME composition, anyway? Which is not going to be easy. As a comparison, MH-E has it's own syntax which seems to be XML-based. I have no idea if it's better or worse than mhbuild. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
ken wrote: part text/plain1020 i don't recall us ever discussing the possibility of making the '#' character that introduces mhbuild directives configurable by the user. for instance, if the leading character were '}', i don't think i would ever have a conflict with real text. interpretation of those directives is strictly within mhbuild, correct? no leakage into other mh commands? There used to be some leakage; for example, the old attach implementation would parse the Nmh-Attachment headers and then create mhbuild directives. I am not sure there is any leakage now. But I am not in love with the idea of changing the leading character, because that opens the box for how should we do MIME composition, anyway? Which is not going to be easy. As a i guess i'm not sure how letting a user change the prefix character on the existing mechanism would make that worse. (and i'm not talking about 1.6.) paul comparison, MH-E has it's own syntax which seems to be XML-based. I have no idea if it's better or worse than mhbuild. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers -- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 71.2 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Paul Fox writes: ken wrote: part text/plain1020 i don't recall us ever discussing the possibility of making the '#' character that introduces mhbuild directives configurable by the user. for instance, if the leading character were '}', i don't think i would ever have a conflict with real text. interpretation of those directives is strictly within mhbuild, correct? no leakage into other mh commands? There used to be some leakage; for example, the old attach implementation would parse the Nmh-Attachment headers and then create mhbuild directives. I am not sure there is any leakage now. But I am not in love with the idea of changing the leading character, because that opens the box for how should we do MIME composition, anyway? Which is not going to be easy. As a i guess i'm not sure how letting a user change the prefix character on the existing mechanism would make that worse. (and i'm not talking about 1.6.) paul We wouldn't be talking about this if we had a good solution! My opinion is that having special characters in the body is bad, like crossing the beams. It was a good hack at the time but should be put out of our misery. I think that all MIME composition should be done via headers. Y'all have done a bunch of work on my original attachment stuff. In what way is it not good enough yet? Jon ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
There used to be some leakage; for example, the old attach implementation would parse the Nmh-Attachment headers and then create mhbuild directives. I am not sure there is any leakage now. But I am not in love with the idea of changing the leading character, because that opens the box for how should we do MIME composition, anyway? Which is not going to be easy. As a i guess i'm not sure how letting a user change the prefix character on the existing mechanism would make that worse. I understand your point ... it's just that it seems like a Band-Aid™ on a much larger problem, and I'd rather solve the much larger problem. But then again, I wrote replyfilter which is also a Band-Aid™ on a much larger problem. I don't have a good answer, unfortunately; the idea of changing that leaves me unsettled, but I recognize that's not really a rational argument. What do others think? --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
My opinion is that having special characters in the body is bad, like crossing the beams. It was a good hack at the time but should be put out of our misery. I think that all MIME composition should be done via headers. Y'all have done a bunch of work on my original attachment stuff. In what way is it not good enough yet? It's fine for 90% of what people normally want to do. It's just the rest of the stuff ... like creating multiparts like multipart/alternative, or external-body references, or if you want to create HTML and specify the Content-ID of attachments exactly. Not many people want to do that, it's true. I'm not sure how we do that in headers easily. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
jon wrote: part text/plain1607 Paul Fox writes: ken wrote: part text/plain1020 i don't recall us ever discussing the possibility of making the '#' character that introduces mhbuild directives configurable by the user. for instance, if the leading character were '}', i don't think i would ever have a conflict with real text. interpretation of those directives is strictly within mhbuild, correct? no leakage into other mh commands? There used to be some leakage; for example, the old attach implementation would parse the Nmh-Attachment headers and then create mhbuild directives. I am not sure there is any leakage now. But I am not in love with the idea of changing the leading character, because that opens the box for how should we do MIME composition, anyway? Which is not going to be easy. As a i guess i'm not sure how letting a user change the prefix character on the existing mechanism would make that worse. (and i'm not talking about 1.6.) paul We wouldn't be talking about this if we had a good solution! My opinion is that having special characters in the body is bad, like crossing the beams. It was a good hack at the time but should be put out of our misery. I think that all MIME composition should be done via headers. Y'all have done a bunch of work on my original attachment stuff. In what way is it not good enough yet? for me? it's new-fangled, and i don't trust it. ;-) seriously, it's just not how i've been doing attachments for the last 15 years. my current mechanism [1] trivially lets me attach either files or MH messages (e.g. cur, or +mh last) and i can insert them anywhere i want in my message. Attach is limited (as far as i know) to pathnames, and its attachments are always placed at the end of the message. up 'til now, i've used automimeproc=1, and i have a hook in my mh.edit script that warns me about leading '#' chars in my draft. with 1.6 i'll need to change my ways. that may mean using Attach, but it will only be part of my solution. i was just floating the idea of making the '#' configurable -- that would only be a partial solution as well. paul [1] i have an 'attach' command that takes paths and/or mh message specifications as args, and produces mhbuild directives on stdout. so (in vi) using !!attach cur or !!attach /tmp/cartoon.pdf populates the correct directives. lately i've been trying to remember to mostly use it at the bottom of the edit buffer (so attachments come last, as a courtesy to the recipient, but that's not always what i want. -- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 72.0 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
for me? it's new-fangled, and i don't trust it. ;-) Geez Paul, we only had like a huge discussion about this back in December :-/ seriously, it's just not how i've been doing attachments for the last 15 years. my current mechanism [1] trivially lets me attach either files or MH messages (e.g. cur, or +mh last) and i can insert them anywhere i want in my message. Attach is limited (as far as i know) to pathnames, and its attachments are always placed at the end of the message. That's true (although if you have a new-enough file command, it will figure out that a particular file is, for example, a message/rfc822). As we talked about in December, this is a simple mode of attaching files; designed for what the average user is going to be doing, which is creating MIME messages which looks like the ones created by nearly every other MUA out there. Now you're still free to write your own mhbuild directives and do what you did before. up 'til now, i've used automimeproc=1, and i have a hook in my mh.edit script that warns me about leading '#' chars in my draft. with 1.6 i'll need to change my ways. that may mean using Attach, but it will only be part of my solution. It does occur to me that if your only beef is automimeproc is no longer supported, then there is an easy workaround: create your own sendproc that always runs mhbuild, and you should be where you were before. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
ralph wrote: part text/plain 307 Hi Paul, for instance, if the leading character were '}', i don't think i would ever have a conflict with real text. C source code? doh! i originally thought of ')', and ']', and extrapolated incorrectly to any righthand delimiter. okay, okay. before you bring up lisp source code, i'll give up. tokens in the text is a bad idea. i'm on board now... paul -- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 62.8 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
On Apr 14, 2014, at 3:33 PM, Ralph Corderoy ra...@inputplus.co.uk wrote: C source code? Cheers, Ralph. i think this mailing list thread is going into my fortunes file ;-) signature.asc Description: Message signed with OpenPGP using GPGMail ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Right now a user can sit down, compose a message that happens to contain 8-bit characters, and send it out ... and nmh will happily blast it out, with no MIME headers at all. This is super-wrong. And it's not a theoretical problem either: http://lists.nongnu.org/archive/html/nmh-workers/2012-05/msg00141.html Hear! Hear! This is a very treacherous source of embarassment, because you may for some time be unaware of the peculiar appearance of your outgoing e-mail. I for one don't need my MUA to make me look stupid, I usually manage unaided. Just doing nothing is, unfortunately, not an option, not in this day and age. This is all about making nmh a real MIME-compliant MUA, which I hope is something we all want. This, at least, is what your humble user would very much like, as an unfortunate speaker of one of those nasty non-7-bit languages seemingly designed in response to the ASCII standard with the sole purpose of upsetting programmers' sense of good taste and no-nonsense by wantonly introducing funny characters into everyday written conversation. (Please pardon the sarcastic note.) Best regards, Rickard ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Hi Rickard, This is a very treacherous source of embarassment, because you may for some time be unaware of the peculiar appearance of your outgoing e-mail. I for one don't need my MUA to make me look stupid, I usually manage unaided. You know of the workaround where you alter your initial drafts to have hard-coded MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit headers, altered to suit? Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Hi! You know of the workaround where you alter your initial drafts to have hard-coded MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit headers, altered to suit? Maybe I was half aware of the possibility of such a workaround, although I haven't tried it in real life. Since I became aware of this pitfall, I've kept automimeproc enabled in my profile, and I believe it does the right thing for me, although for some time I wasn't very comfortable with it. My point, though, was that Nmh unfortunately makes it very easy - stretching the metaphor an inch or two - to shoot oneself in the foot without noticing, and I got the impression that this was one of Ken's points as well. Actually, I thought that he really hit the nail on the head, so I got the idea to chime in. Now I think I'll sit back again and enjoy people's educated conversation. I will keep your workaround in mind, though. Thank you! Rickard ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Hi Ken, Well, let me make this alternate proposal: - attach adds Nmh-Attachment headers as per usual. Maybe we'll add something like: attaching foo.pdf to message as application/pdf so the user can see what MIME type is being used (really, that's all I care about). - You can add or not add mhbuild directives to the message if you want. - If you add mhbuild directives, you can run mime (also, you can run mime even if you don't). mhbuild will be in charge of processing Nmh-Attachment headers. If there are mhbuild directives, they get added per usual; any content specified by Nmh-Attachment headers gets appended to the message after all other content. This is a significant change to the _implementation_, but it feels like where that functionality should belong. - If you try to attach after a mime, you get an error. - send runs mhbuild -auto -nodirectives. -auto means, don't error out if there's a MIME-Version header, just don't process the draft. -nodirectives means don't process directives. But ... Nmh-Attachment headers are still processed. How does that look? More code rework, but it feels better. Also, with this I think it actually accomplishes what you want (attach + inspection). Looks good. I can't think of any problems at the moment. Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
ralph wrote: Hi Ken, Well, let me make this alternate proposal: - attach adds Nmh-Attachment headers as per usual. Maybe we'll add something like: attaching foo.pdf to message as application/pdf so the user can see what MIME type is being used (really, that's all I care about). - You can add or not add mhbuild directives to the message if you want. - If you add mhbuild directives, you can run mime (also, you can run mime even if you don't). mhbuild will be in charge of processing Nmh-Attachment headers. If there are mhbuild directives, they get added per usual; any content specified by Nmh-Attachment headers gets appended to the message after all other content. This is a significant change to the _implementation_, but it feels like where that functionality should belong. i'm having trouble with the next two points: - If you try to attach after a mime, you get an error. - send runs mhbuild -auto -nodirectives. -auto means, don't error out if there's a MIME-Version header, just don't process the draft. -nodirectives means don't process directives. But ... Nmh-Attachment headers are still processed. if mhbuild -auto -nodirectives can still process Nmh-Attachment directives at this point, then why can't attach after a mime still work? couldn't running attach after a mime simply do the same thing that makes the send case work? paul How does that look? More code rework, but it feels better. Also, with this I think it actually accomplishes what you want (attach + inspection). Looks good. I can't think of any problems at the moment. Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers -- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 19.0 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Hi Paul, - If you try to attach after a mime, you get an error. - send runs mhbuild -auto -nodirectives. -auto means, don't error out if there's a MIME-Version header, just don't process the draft. -nodirectives means don't process directives. But ... Nmh-Attachment headers are still processed. if mhbuild -auto -nodirectives can still process Nmh-Attachment directives at this point, then why can't attach after a mime still work? Because the mhbuild step can only turn a non-MIME email into a MIME one; it can't handle being given a MIME email as input. That's one niggle with running mime at the moment; if the mhbuild-directives need improving and mime run again, one must undo the mime manually by looking for the backup file in the drafts folder as there's no undomime command. Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Paul F. wrote: i'm having trouble with the next two points: - If you try to attach after a mime, you get an error. - send runs mhbuild -auto -nodirectives. -auto means, don't error out if there's a MIME-Version header, just don't process the draft. -nodirectives means don't process directives. But ... Nmh-Attachment headers are still processed. if mhbuild -auto -nodirectives can still process Nmh-Attachment directives at this point, then why can't attach after a mime still work? couldn't running attach after a mime simply do the same thing that makes the send case work? If I understand correctly, with both -auto and -nodirectives, Nmh-Attachment headers won't be processed if the message has already been mime'd (run through mhbuild). If we were to allow them to be processed after the message was mime'd, the new attachments would have to be inserted into the existing MIME structure. Doable but I agree that it's not a good idea. If that's right and we want to revisit this, mhfixmsg does that kind of insertion. But for our current purpose, we wouldn't be using mhbuild, at least in its entirety, so I would still agree that it's not a good idea. The limitation of no attach after mime is not onerous and can be easily enforced. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
ralph wrote: Hi Paul, - If you try to attach after a mime, you get an error. - send runs mhbuild -auto -nodirectives. -auto means, don't error out if there's a MIME-Version header, just don't process the draft. -nodirectives means don't process directives. But ... Nmh-Attachment headers are still processed. if mhbuild -auto -nodirectives can still process Nmh-Attachment directives at this point, then why can't attach after a mime still work? Because the mhbuild step can only turn a non-MIME email into a MIME one; it can't handle being given a MIME email as input. That's one niggle that's what i thought. but if that's so, then how does the last bit: But ... Nmh-Attachment headers are still processed. work? paul with running mime at the moment; if the mhbuild-directives need improving and mime run again, one must undo the mime manually by looking for the backup file in the drafts folder as there's no undomime command. Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers -- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 19.9 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Ralph Corderoy writes: Hi Ken, Well, let me make this alternate proposal: - attach adds Nmh-Attachment headers as per usual. Maybe we'll add something like: attaching foo.pdf to message as application/pdf so the user can see what MIME type is being used (really, that's all I care about). - You can add or not add mhbuild directives to the message if you want. - If you add mhbuild directives, you can run mime (also, you can run mime even if you don't). mhbuild will be in charge of processing Nmh-Attachment headers. If there are mhbuild directives, they get added per usual; any content specified by Nmh-Attachment headers gets appended to the message after all other content. This is a significant change to the _implementation_, but it feels like where that functionality should belong. - If you try to attach after a mime, you get an error. - send runs mhbuild -auto -nodirectives. -auto means, don't error out if there's a MIME-Version header, just don't process the draft. -nodirectives means don't process directives. But ... Nmh-Attachment headers are still processed. How does that look? More code rework, but it feels better. Also, with this I think it actually accomplishes what you want (attach + inspection). Looks good. I can't think of any problems at the moment. Cheers, Ralph. Always one with the unpopular opinion, this doesn't do it for me. This does not address a significant enough problem to justify the amount of work and change to the code base for me. Of course, I'm not doing the work here. In my mind, the question is whether work is going to go into maintaining a cryptic ui that few people use, or whether it's going to go into making a good ui. I favor the latter. So my opinion is to live with it for now. If you're happy with attach, then use it. If you want to use mhbuild, go ahead. Just don't use both. Save your energy for a coding effort with a greater value proposition. Jon ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Hi Paul, Because the mhbuild step can only turn a non-MIME email into a MIME one; it can't handle being given a MIME email as input. that's what i thought. but if that's so, then how does the last bit: But ... Nmh-Attachment headers are still processed. work? They can only be put there by attach which refuses to do so if mime has already been run. It knows this by seeing MIME-Version is present. Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Hi Jon, So my opinion is to live with it for now. If you're happy with attach, then use it. If you want to use mhbuild, go ahead. Just don't use both. A decent point. I think Ken's go to make *some* changes to cope with always running mhbuild even though I've manually'd mime'd earlier. Still, it's Ken's Christmas. ;-) Is there a better name for -auto? It seems so called because mhbuild is going to be run automatically but AFAICS it's really telling it to skip existing mime emails; -skipmime? Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
ralph wrote: Hi Paul, Because the mhbuild step can only turn a non-MIME email into a MIME one; it can't handle being given a MIME email as input. that's what i thought. but if that's so, then how does the last bit: But ... Nmh-Attachment headers are still processed. work? They can only be put there by attach which refuses to do so if mime has already been run. It knows this by seeing MIME-Version is present. that's not true. Nmh-Attachment headers can be inserted manually as well, bypassing that attach error check. but i now see that i mis-parsed ken's original description. if i add some [clarification edits], does it still mean what ken meant to begin with? - send runs mhbuild -auto -nodirectives. -auto means, don't error out if there's a MIME-Version header, just don't process the draft [including any Nmh-Attachment headers]. -nodirectives means don't process directives. But ... [ even with -nodirectives, ] Nmh-Attachment headers are still processed. paul Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers -- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 20.1 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Hi Paul, They can only be put there by attach which refuses to do so if mime has already been run. It knows this by seeing MIME-Version is present. that's not true. Nmh-Attachment headers can be inserted manually as well, bypassing that attach error check. Thus my quotes around only. :-) I guess we're assuming the user is still allowed to shoot themselves in the foot if that's what they're like to do. but i now see that i mis-parsed ken's original description. if i add some [clarification edits], does it still mean what ken meant to begin with? Leaving that for Ken rather than muddying the waters further. Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Jon wrote: So my opinion is to live with it for now. If you're happy with attach, then use it. If you want to use mhbuild, go ahead. Just don't use both. Save your energy for a coding effort with a greater value proposition. The movtivation behind all this is to always produce MIME messages. An easy (well, not quite) way would be for post(8) to run mhbuild on every message. The way things are now, we have four cases for the draft message by the time it reaches post: 1) the user had already run mhbuild, such as via whatnow's mime 2) send(1) had already run mhbuild to actually attach what the user requested via whatnow's attach 3) the user had otherwise inserted MIME-Version and Content-Type headers 4) the draft is not formatted as MIME 1), 2), and 3) could be easily handled by -auto (or whatever it's called): it turns mhbuild into a no-op. That would be easy. For 4), the draft can't be blindly run through mhbuild because it might contain things that look like directives but aren't. That would be solved by mhbuild -nodirectives. Conceptually (or even actually), we could just leave send's handling of Nmh-Attachments as-is, and just concentrate on 4). Or to look at it another way, send's handling of Nmh-Attachment headers already implements the effect of -nodirectives. But that really should be moved into mhbuild. The lockouts really are orthogonal. Though not difficult to implement. But maybe they should be comittted separately. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Wow, I take a day off to get some Christmas stuff done, and this discussion explodes. To summarize a bunch of emails ... Paul Fox wrote: if mhbuild -auto -nodirectives can still process Nmh-Attachment directives at this point, then why can't attach after a mime still work? couldn't running attach after a mime simply do the same thing that makes the send case work? I think this was explained correctly; you can only run mhbuild once (it turns a mhbuild draft into a MIME message), and basically everyone explained that even in auto mode Nmh-Attachment headers would still be processed (I'm fine with -auto; I didn't care for Ralph's -skipmime suggestion, but I'd be open to others). And Paul, your rephrased description is correct. Ralph writes: if the mhbuild-directives need improving and mime run again, one must undo the mime manually by looking for the backup file in the drafts folder as there's no undomime command. Should we create a unmime command? You would think it wouldn't be hard, actually. Jon writes: Oh! Just looked at the file man page, and someone has added a --mime option that does the right thing and recognizes messages in ascii text. That's not part of POSIX, actually, so we can't rely on it. It seems most people use file suffixes. Also ... if you really want to forward a message as message/rfc822, we HAVE forw -mime already. Jon writes: David Levine writes: The movtivation behind all this is to always produce MIME messages. An easy (well, not quite) way would be for post(8) to run mhbuild on every message. Ah. I guess that I just don't get the need/motivation for taht. Sigh. I kinda thought this was obvious, but to restate it ... Right now a user can sit down, compose a message that happens to contain 8-bit characters, and send it out ... and nmh will happily blast it out, with no MIME headers at all. This is super-wrong. And it's not a theoretical problem either: http://lists.nongnu.org/archive/html/nmh-workers/2012-05/msg00141.html Also, we want nmh to be a MIME-conformant MUA, right? Well, take a look at RFC 2049, Section 2, to see what that entails. The short answer is that in this day and age, you're supposed to be sending all email with the basic MIME headers. mhbuild is the tool we have that does that. Now, you're objecting to the work; sure, you admit that you don't have to do it, so it's not a huge objection. The problem is ... I think you would admit that your implementation has a number of warts, and one obvious one is it has a lot of MIME knowledge in send which feels wrong to me. Moving this to mhbuild makes more sense from a long-term architectural standpoint. This isn't really about making mhbuild directives and Nmh-Attachment headers work together in the same message ... Ralph had the correct point that really, attach and mhbuild directives are two different ways of doing the same thing, so why aren't they converging more? That logic is unassialable. Being able to support both in the same file is, to me, just a side benefit. If it's trivial (and it looks like it is), why not make it work? Just doing nothing is, unfortunately, not an option, not in this day and age. This is all about making nmh a real MIME-compliant MUA, which I hope is something we all want. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
I will note one thing: I discovered recently that mutt supports an Attach header, which does exactly what you'd expect it to do. So there is prior art here. --Ken Humph! Have to check the logs, I thought that I was the prior art. Humbug. My mistake; I believe you were first. My key point was that we aren't the only ones doing that. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
You pointed out, http://lists.nongnu.org/archive/html/nmh-workers/2013-12/msg00038.html, the two paths, starting with mbuild-directives and attach-headers, take a long time to converge and interfere. mime runs mhbuild, job done. attach puts in the header which is seen late-on by post(8), and only then constructs mhbuild-directives and runs mhbuild. The attach-header is a subset of mhbuild functionality. My suggestion to alter attach to append mhbuild-directives to the draft was driven by trying to merge the two paths earlier and without interference. Alright, I can understand that, but that tells me that maybe a different approach is needed. How about if `#' was configurable and could be multiple characters? And that could further be overridden on a per-message basis by an nmh-header? Hmm ... that just strikes me as too complicated. I mean, it just feels like the wrong thing. You're suggesting mhbuild runs on the send. Does mime then disappear since mhbuild isn't idempotent? I'd like some way to inspect the results of my mhbuild-directives before the email hits the wire. Would that be a send option that feeds mhbuild-output to $PAGER and then stops? Well, let me make this alternate proposal: - attach adds Nmh-Attachment headers as per usual. Maybe we'll add something like: attaching foo.pdf to message as application/pdf so the user can see what MIME type is being used (really, that's all I care about). - You can add or not add mhbuild directives to the message if you want. - If you add mhbuild directives, you can run mime (also, you can run mime even if you don't). mhbuild will be in charge of processing Nmh-Attachment headers. If there are mhbuild directives, they get added per usual; any content specified by Nmh-Attachment headers gets appended to the message after all other content. This is a significant change to the _implementation_, but it feels like where that functionality should belong. - If you try to attach after a mime, you get an error. - send runs mhbuild -auto -nodirectives. -auto means, don't error out if there's a MIME-Version header, just don't process the draft. -nodirectives means don't process directives. But ... Nmh-Attachment headers are still processed. How does that look? More code rework, but it feels better. Also, with this I think it actually accomplishes what you want (attach + inspection). --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
On Dec 12, 2013, at 12:56 PM, Ken Hornstein k...@pobox.com wrote: How about if `#' was configurable and could be multiple characters? And that could further be overridden on a per-message basis by an nmh-header? Hmm ... that just strikes me as too complicated. I mean, it just feels like the wrong thing. What really needs to happen here is for all the commands to become MIME-aware. Construction of messages would take place by actually inserting the MIME parts as per user directive. The display of message content would reflect the current MIME structure. It's a lot of work, but it's the only sane solution. And should be deferred to a 2.x release stream. For the 1.x branch I would prefer to keep Ken locked up in the dungeon fixing up the MIME encoding issues ;-) --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
How does that look? More code rework, but it feels better. Also, with this I think it actually accomplishes what you want (attach + inspection). One additional thing ... I'd like to get rid of the ability of specifing the header name and just go with Nmh-Attachment. I realize that's an artifact of the current implementation, but I don't see the value in changing the header name, and supporting THAT requires passing down the header name to mhbuild. I'd rather just hardcode it, document it, and leave it as-is. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
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 ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Ken Hornstein writes: How does that look? More code rework, but it feels better. Also, with this I think it actually accomplishes what you want (attach + inspection). One additional thing ... I'd like to get rid of the ability of specifing the header name and just go with Nmh-Attachment. I realize that's an artifact of the current implementation, but I don't see the value in changing the header name, and supporting THAT requires passing down the header name to mhbuild. I'd rather just hardcode it, document it, and leave it as-is. --Ken I originally made it configurable because there was no guaranteed way to avoid conflicts with non-standard headers. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Jon Steinhart j...@fourwinds.com writes: Ken Hornstein writes: I will note one thing: I discovered recently that mutt supports an Attach header, which does exactly what you'd expect it to do. So there is prior art here. --Ken Humph! Have to check the logs, I thought that I was the prior art. Humbug. My mistake; I believe you were first. My key point was that we aren't the only ones doing that. --Ken 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 readingMIME messages. o I'd like to eliminate mhlist, mhstore, and mhshow from the ui. o I'd like to extend message numbers so that 432.1.2 would be part 1.2 of message number 432. o I'd like a -mime option to scan that did a more compact (1 line) summary of each message part. o I'd like the ability to show a message part. 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. 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. o I'd like to be able to override the default handling of a part when shown on the command line. On the composition and sending side. o Blasphemy! I'd like to eliminate mhbuild from the ui even if it lives in the background. o I'd like to handle forw -mime and repl -mime using new nmh-private headers similar to the attach header. 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. There! Do your worst! Almost certainly, had MH been invented today, Mime parts would have been stored in separate files, and messages would have been stored as directories. One of the very early on considerations, (before Bruce Borden came on), was efficiency, given that we were time sharing a PDP 1145. Further, MIME was decades in the future. I don't how mime parts would have been named. Naming messages as digit strings was a decision that came later. BUT all that says very little about how to morph nmh from what we have now, to something that will do Mime well. Your proposal, above, strikes me as too radical a change. Norman Shapiro ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
+1 to jon's proposal below. but this is probably enmh (even newer mail handler), not nmh. because to support it we'll have to bite a long-avoided architectural bullet and put all of the logic in a callable library, of which the command line tools are wrappers around option parsing and the libraries. programmatic users of the mail handler should not have to call system(pick), they should be calling enmh_pick(). if a team gets together that's going to cut that deep, i'll offer to be involved, for whatever good or evil images that may provoke. (i am personally responsible for more cert advisories than any other human, since about a third of sendmail's lifetime total are mine not eric's.) vixie re: Jon Steinhart j...@fourwinds.com writes: ... o I'd like to eliminate mhlist, mhstore, and mhshow from the ui. o I'd like to extend message numbers so that 432.1.2 would be part 1.2 of message number 432. o I'd like a -mime option to scan that did a more compact (1 line) summary of each message part. o I'd like the ability to show a message part. 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. 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. o I'd like to be able to override the default handling of a part when shown on the command line. On the composition and sending side. o Blasphemy! I'd like to eliminate mhbuild from the ui even if it lives in the background. o I'd like to handle forw -mime and repl -mime using new nmh-private headers similar to the attach header. 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. There! Do your worst! ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Hi Jon, The attach thing is interesting to me socially because even you mhbuild-lovers are using attach Minor point: I don't use attach, never have, as I can't see the MIME that will be sent. :-) Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Ralph Corderoy writes: Hi Jon, The attach thing is interesting to me socially because even you mhbuild-lovers are using attach Minor point: I don't use attach, never have, as I can't see the MIME that will be sent. :-) Cheers, Ralph. I stand corrected. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Ken wrote: Well, let me make this alternate proposal: - attach adds Nmh-Attachment headers as per usual. Maybe we'll add something like: attaching foo.pdf to message as application/pdf so the user can see what MIME type is being used (really, that's all I care about). - You can add or not add mhbuild directives to the message if you want. - If you add mhbuild directives, you can run mime (also, you can run mime even if you don't). mhbuild will be in charge of processing Nmh-Attachment headers. - If you try to attach after a mime, you get an error. - send runs mhbuild -auto -nodirectives. How does that look? More code rework, but it feels better. Also, with this I think it actually accomplishes what you want (attach + inspection). I like it. One question: would it make sense to put the entire mhbuild directive in the Nmh-Attachment header instead of just the path? Users could then edit it as they wish. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
ralph wrote: Hi Jon, The attach thing is interesting to me socially because even you mhbuild-lovers are using attach Minor point: I don't use attach, never have, as I can't see the MIME that will be sent. :-) i've never used it either. partly it's because i didn't know readline was available at whatnow, but mainly it's because attach removes attachment from the flow of composition -- i have to remember to attach _after_ i've written out my draft, which to me is the ready to send point. i forget to include the attachment often enough as it is -- i much prefer adding an attachment while still editing, which i can do with directives. oh, and the previously mentioned issue with bad mime types when attaching mail messages. i do understand the attraction of the symplicity of attach, though. paul Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers -- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 12.9 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
One question: would it make sense to put the entire mhbuild directive in the Nmh-Attachment header instead of just the path? Users could then edit it as they wish. I feel the answer is no. I would like to give users the option to add their own Nmh-Attachment headers; if that's just a filename, that's reasonable. If it's a mhbuild directive, then it's not. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Paul F. wrote: mainly it's because attach removes attachment from the flow of composition -- i have to remember to attach _after_ i've written out my draft, which to me is the ready to send point. i forget to include the attachment often enough as it is -- i much prefer adding an attachment while still editing, which i can do with directives. You can do it with attach, too: just pop out of the editor, attach, and edit again. Or attach before editing. I usually do that because I then easily see what I've attached. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Ken wrote: One question: would it make sense to put the entire mhbuild directive in the Nmh-Attachment header instead of just the path? Users could then edit it as they wish. I feel the answer is no. I would like to give users the option to add their own Nmh-Attachment headers; if that's just a filename, that's reasonable. If it's a mhbuild directive, then it's not. It depends on priorities: I'd rather be able to customize an attachment than manually insert a simple Nmh-Attachment header (I think that's the option you mention). I've never done that. Or given that you're fixing the header field name, we could support both. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
[...] 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. That's fair ... I was just looking at it from a ok, these things you want, how exactly could they be implemented? All part of the process. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Ken Hornstein writes:
It depends on priorities: I'd rather be able to customize
an attachment than manually insert a simple Nmh-Attachment
header (I think that's the option you mention). I've never
done that.
It's just that when I hear the word customize, I ask the question:
If you want to customize your MIME content, why aren't you just adding
a mhbuild directive to your draft? What are you customizing, exactly?
Also, the semantics behind:
Nmh-Attachment: foo.pdf
are clear to me as a casual user.
The semantics behind:
Nmh-Attachment: #application/pdf {attachment} foo.pdf
are less clear to me and requires me to parse the BNF in the mhbuild
man page. Also, more to get wrong! The only reason I want an
Nmh-Attachment header to cause a failure is from being unable to read
the file.
--Ken
I agree with Ken here. I do want to point out that the attach command
reports an error if it can't attach a file. So the only time you'd get
an error from send is if the file vanishes between the at and the s.
Pretty small window. Is this a real problem or just theoretical?
Jon
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
+1 to jon's proposal below. but this is probably enmh (even newer mail handler), not nmh. because to support it we'll have to bite a long-avoided architectural bullet and put all of the logic in a callable library, of which the command line tools are wrappers around option parsing and the libraries. programmatic users of the mail handler should not have to call system(pick), they should be calling enmh_pick(). I see Jon's proposal as a lot of UI changes that MIGHT involve changes to the backend, but doesn't necessarily require it. Although obviously some of the MIME stuff needs to be in a library now (all of the MIME parsing routines are actually in $(srcdir)/uip, which is kind of annoying and it would need a lot of restructuring). --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Paul Fox writes:
jon wrote:
Ken Hornstein writes:
It depends on priorities: I'd rather be able to customize
an attachment than manually insert a simple Nmh-Attachment
header (I think that's the option you mention). I've never
done that.
It's just that when I hear the word customize, I ask the question:
If you want to customize your MIME content, why aren't you just adding
a mhbuild directive to your draft? What are you customizing, exactly?
Also, the semantics behind:
Nmh-Attachment: foo.pdf
are clear to me as a casual user.
The semantics behind:
Nmh-Attachment: #application/pdf {attachment} foo.pdf
are less clear to me and requires me to parse the BNF in the mhbuild
man page. Also, more to get wrong! The only reason I want an
Nmh-Attachment header to cause a failure is from being unable to read
the file.
--Ken
I agree with Ken here. I do want to point out that the attach command
reports an error if it can't attach a file. So the only time you'd get
an error from send is if the file vanishes between the at and the s.
Pretty small window. Is this a real problem or just theoretical?
ignorance speaking: are whatnow and send guaranteed to run from the
same directory? (this has bitten me with constructing mhbuild directives
in the editor with unqualified pathnames.)
paul
Attach puts in absolute path names.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
As with my attach addition which is way more contentious now than it was when I implemented it, my proposal on side is compatible with the existing ui. It would look the same if you didn't turn on any of the new options. Could even leave mhlist et. al. in place for any who love 'em. It's true to the don't break things philosophy. So, out of curiousity I went back and dug into these changes ... I see they were committed on August 19th, 2002. More than 11 years ago! The previous changes to that were all in July, and then a HUGE gap from those to March of 2001. That was also back during our transition from mhost to savannah ... and from the mailing list archives, it doesn't look like you sent out any email about the change either (correction: looks like there was a brief announcement on 2002-11-29). So ... I expect the reason that it wasn't controversial was that no one noticed (I actually didn't notice that support for years, I am sure). This gets into larger issues in terms of code changes, long term direction, etc etc. Since we've touched on these meta-issues, let me speak to them more directly. Over the years we've been slowly limping toward getting better MIME support, but it's mostly been via what can kindly be called hacks. E.g., the attach support, replyfilter (and associated framework), and mhfixmsg. Most of this code went in with little discussion; well, there was some discussion about mhfixmsg, but I rammed in the framework for replyfilter through without any discussion (I think people were just happy to have some solution that they didn't care; the only serious discussion was where to put the replyfilter script). These stealth hacks are fine in and of themselves; they're driven by real needs, and more code is always welcome. But we're getting to the point where all of the easy stuff is done, and we're left with harder and harder things. Those things require us to really think about some of the larger issues that we need to grapple with. This is why I brought up the issues regarding always running mhbuild; I thought it was simple, but it turns out it ain't (like many things in nmh). That gets into the larger meta-issue of How do we want people to compose MIME content, anyway?. We're a little bit closer to making that better now. I'm not always sure of the right answer; that's why I punt a lot of these things to the list. It also forces me to defend my ideas, and frequently fighting for them makes them better (I think my new idea for mhbuild/attach is better than the old one). I guess my point is that I think the time of stealth hacks, especially when it comes to MIME support, is over. We need to start thinking larger and long-term and grapple with serious issues that have been languishing for a few decades. To me that's the core of all of these discussions. I think we're working them out, it's just going to take a while. That's not to say that everything needs to go through the mailing list, or that we need to implement something like Gerrit; use your best judgement. I suspect like Mike O'Dell suggested a little while ago we're eventually going to have to have a MIME multiplexor at some point to really handle everything properly. How that will work or be implemented really is up in the air, though. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Actually, I sent out a ton of email on it. Starting on 8/13/00. I still have the emails if they were lost due to the change. For example: I stand corrected! I did look in the archives on mhonarc.org (the most complete copy I could find), but there's a gap between 1999-04 and 2002-06. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
david wrote: Ken wrote: Can the people who want to have attach append mhbuild directives explain what their thinking is, specifically why they think their approach is preferrable? I went back and looked at the thread very carefully, and none of the proponents of this approach really covered why they thought this was better. To me, the big advantage was simplifying that decision logic that you presented. It just seems more complex than necessary. The ability to review/edit mhbuild output is a bonus, but not a primary goal for me. Another bonus would be to move error checking up: instead of send(1) tripping over a nonexistant file, whatnow(1) would. That's not of much value to me because I always ls before attach'ing, so again it minor to me. that's an interesting point, and i just realized that it's one reason i've never been comfortable with attach. my editor supports enough filename completion that when inserting the mhbuild directive (via a helper script), i can be sure that the filename is spelled correctly and exists. i don't get that early error detection service at the whatnow prompt. I have no problem putting parameters in pseudo-headers rather than directives in the body, if that's where you're headed. i'm fine with that too -- i guess i'd fill the header from within the editor, retaining the completion capability. but playing with this just now, i've hit another issue with attach (probably unrelated to the current thread, i guess). how do i use whatnow's attach to attach a file, like a mail message, with a specific Content-Type? i.e., if i use this: Nmh-Attachment: /home/pgf/Mail/inbox/2902 i get a Content-Type of text/plain rather than message/rfc822 (as would have been supplied by a #forw mhbuild directive). paul -- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 19.6 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Paul wrote: that's an interesting point, and i just realized that it's one reason i've never been comfortable with attach. my editor supports enough filename completion that when inserting the mhbuild directive (via a helper script), i can be sure that the filename is spelled correctly and exists. i don't get that early error detection service at the whatnow prompt. You get command line completion of filenames at the whatnow prompt if your nmh was built with readline. Quite useful when using attach and detach. but playing with this just now, i've hit another issue with attach (probably unrelated to the current thread, i guess). how do i use whatnow's attach to attach a file, like a mail message, with a specific Content-Type? The only way to set Content-Type with attach is via a mhshow-suffix-application directive in your profile (or mhn.defaults). Given that MH messages don't have filename extensions, there isn't a good way now to send them as message/rfc822 with attach. That's a case where a mhbuild directive is the way to go. attach isn't a complete replacement for those. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Hi Ken, The reason this is cropping up now is that we want to get to the point where a MIME headers are always generated (I assume this is non-controversial). Looks down. Mumbles No. Scuffs foot. Using the tools we have, this means running mhbuild. This was never designed to be run all of the time, hence the issues with directives. Agreed. The reason all of these various suggestions regarding putting mhbuild directives in the text feel wrong to me is that it BY DEFAULT assigns special meaning to the message body where there was none before. Yes, a significant change. trying to guess what is and isn't a directive suggests to me that we're doing the wrong thing. Yes, and means `#fowr' would go undiagnosed, for example. It's fine for users who WANT to create mhbuild directives, but it just Seems Wrong that message bodies now assign special meaning to '#' at the beginning of the line. Agreed. Can the people who want to have attach append mhbuild directives explain what their thinking is, specifically why they think their approach is preferrable? You pointed out, http://lists.nongnu.org/archive/html/nmh-workers/2013-12/msg00038.html, the two paths, starting with mbuild-directives and attach-headers, take a long time to converge and interfere. mime runs mhbuild, job done. attach puts in the header which is seen late-on by post(8), and only then constructs mhbuild-directives and runs mhbuild. The attach-header is a subset of mhbuild functionality. My suggestion to alter attach to append mhbuild-directives to the draft was driven by trying to merge the two paths earlier and without interference. Ok, Ralph did say that he wanted to look at the headers post-MIMEification to adjust them No, sorry, when I said edit I was referring to a whatnow-entry to put me back in vi so I can read-only peruse the outcome of mime. My intent is always to have mime do the work; if something's not right I go back to pre-mime and fix it because mhbuild could always do want I want AIUI. ~~~/~~~ There seem to be two issues. `#' is a poor magic character if mhbuild is to run all the time, clashing too much with unindented cpp(1) and sh(1) input. A simple way to attach files shouldn't stop mhbuild directives being used. (Personally, I think having `cd', `pwd', etc., at the whatnow-prompt for attach foo is wrong; MH's raison d'etre was to not be its own little shell and whatnow shouldn't grow to be one.) How about if `#' was configurable and could be multiple characters? And that could further be overridden on a per-message basis by an nmh-header? The new default could be /^mhb\/; something that's unlikely to be accidental. Any mhbs that don't parse stop whatnow's send working. mhb image/png \ /home/foobar/junk/picture.png mhb forw +inbox 42 43 99 A new mhbuild directive that guesses the MIME type could provide a simple attach mechanism. whatnow's attach could append these instead of adding its header. Or still add its header and they're treated as if they were additional directives at the end of the body in the order they're encountered. You're suggesting mhbuild runs on the send. Does mime then disappear since mhbuild isn't idempotent? I'd like some way to inspect the results of my mhbuild-directives before the email hits the wire. Would that be a send option that feeds mhbuild-output to $PAGER and then stops? Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Ralph Corderoy writes: Hi Ken, The reason this is cropping up now is that we want to get to the point where a MIME headers are always generated (I assume this is non-controversial). Looks down. Mumbles No. Scuffs foot. No, I don't always want MIME headers. I'm old-fashioned and don't need a kilobyte where 10 bytes will suffice. I like nmh because text-plain is good enough for most of what I do. Ok, Ralph did say that he wanted to look at the headers post-MIMEification to adjust them No, sorry, when I said edit I was referring to a whatnow-entry to put me back in vi so I can read-only peruse the outcome of mime. My intent is always to have mime do the work; if something's not right I go back to pre-mime and fix it because mhbuild could always do want I want AIUI. Do the big MUAs let you do this? Can you look at post-MIME stuff in thunderbird? Or do you just attach things and be happy with the results There seem to be two issues. `#' is a poor magic character if mhbuild is to run all the time, clashing too much with unindented cpp(1) and sh(1) input. A simple way to attach files shouldn't stop mhbuild directives being used. (Personally, I think having `cd', `pwd', etc., at the whatnow-prompt for attach foo is wrong; MH's raison d'etre was to not be its own little shell and whatnow shouldn't grow to be one.) I agree (as the culprit) that having cd, pwd, etc. at whatnow is wrong. But only because whatnow is wrong. IMHO one should finish composing a draft and then use a send command or other command like tools like attach. To some degree this is how it gets used in emacs I believe. How about if `#' was configurable and could be multiple characters? And that could further be overridden on a per-message basis by an nmh-header? The new default could be /^mhb\/; something that's unlikely to be accidental. Any mhbs that don't parse stop whatnow's send working. mhb image/png \ /home/foobar/junk/picture.png mhb forw +inbox 42 43 99 I can't support making a cryptic interface more cryptic. A new mhbuild directive that guesses the MIME type could provide a simple attach mechanism. whatnow's attach could append these instead of adding its header. Or still add its header and they're treated as if they were additional directives at the end of the body in the order they're encountered. This is why I suggested having some optional arguments on the attach header and attach command. And why I suggested a -check option to verify that everything is OK before send. Nobody complains about whom -check! Jon ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Hi Jon, No, sorry, when I said edit I was referring to a whatnow-entry to put me back in vi so I can read-only peruse the outcome of mime. My intent is always to have mime do the work; if something's not right I go back to pre-mime and fix it because mhbuild could always do want I want AIUI. Do the big MUAs let you do this? Can you look at post-MIME stuff in thunderbird? Or do you just attach things and be happy with the results They do not. But then I can only attach a file using their simplistic GUI and hope they get everything they choose right, e.g. text/plain v. message/rfc822, and miss out on the chance to specify the character encoding or give a content description. That's one reason why I don't use them and prefer nmh. (Though I don't think I can set the content-disposition's modification-date?) mhb image/png \ /home/foobar/junk/picture.png mhb forw +inbox 42 43 99 I can't support making a cryptic interface more cryptic. s/#/mhb / seems *slightly* less cryptic to me. :-) A new mhbuild directive that guesses the MIME type could provide a simple attach mechanism. whatnow's attach could append these instead of adding its header. Or still add its header and they're treated as if they were additional directives at the end of the body in the order they're encountered. This is why I suggested having some optional arguments on the attach header and attach command. Sorry, to do what? Memory's going. Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Ralph Corderoy writes: Hi Jon, No, sorry, when I said edit I was referring to a whatnow-entry to put me back in vi so I can read-only peruse the outcome of mime. My intent is always to have mime do the work; if something's not right I go back to pre-mime and fix it because mhbuild could always do want I want AIUI. Do the big MUAs let you do this? Can you look at post-MIME stuff in thunderbird? Or do you just attach things and be happy with the results They do not. But then I can only attach a file using their simplistic GUI and hope they get everything they choose right, e.g. text/plain v. message/rfc822, and miss out on the chance to specify the character encoding or give a content description. That's one reason why I don't use them and prefer nmh. (Though I don't think I can set the content-disposition's modification-date?) My point was that most of the rest of the world gets by without this level of control and it works. Makes me wonder if there is some defect in the way that nmh works that keeps things from working. This is why I suggested having some optional arguments on the attach header and attach command. Sorry, to do what? Memory's going. I know the problem. Maybe we need attach foo.jpg -type image/png that would make an attachment header with the -type option on it so that you could control the picky details. At some level, this is adding mhbuild options to attach which doesn't bug me a lot since attach invokes mhbuild anyway. Of course, once the door is open for one option then *someone* on this list will want all of them. And then there's the error handling... BTW, while I don't feel the need for it, attach could check for a valid file and do any additional argument checking before returning to the whatnow prompt. Maybe that would help. Maybe attach -check would report the automatically selected MIME types. From my standpoint, the biggest issues are combining forwarding or replying to MIME messages and then adding attachments. I'd prefer that we really thought about how to fix this; I'd rather not add a third wart to the first two. Jon ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
david wrote: Paul wrote: that's an interesting point, and i just realized that it's one reason i've never been comfortable with attach. my editor supports enough filename completion that when inserting the mhbuild directive (via a helper script), i can be sure that the filename is spelled correctly and exists. i don't get that early error detection service at the whatnow prompt. You get command line completion of filenames at the whatnow prompt if your nmh was built with readline. Quite useful when using attach and detach. oh, neat. i'll look more closely at my build options. but playing with this just now, i've hit another issue with attach (probably unrelated to the current thread, i guess). how do i use whatnow's attach to attach a file, like a mail message, with a specific Content-Type? The only way to set Content-Type with attach is via a mhshow-suffix-application directive in your profile (or mhn.defaults). Given that MH messages don't have filename extensions, there isn't a good way now to send them as message/rfc822 with attach. That's a case where a mhbuild directive is the way to go. attach isn't a complete replacement for those. thanks. paul -- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 28.6 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
What I like about attach is that it just does the right thing and I don't have to know how it does it internally. It would be really nice if the same were true with other parts of the ui. The nmh MIME support comes across to me as a wart. No offense intended, it's a really useful wart and I use it every day. But it's not really integrated into the ui in a pleasant way. That's an unfortunate truth, and one that is a constant problem. For example, this is exactly the issue we're dealing with here; MIME composition was kind of grafted on the MH UI. It didn't help that the original vision of MIME was that normal email was still 7-bit ASCII and MIME email was a rarity. The world has moved on since those days, but MH didn't keep up. But we're slowly improving. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
To deal with the false directives when using attach: WhatNow could look for any lines that begin with # during the first call to attach, and warn or refuse. Those who use # for replied-to text would have to find something else. Or we could get more sophisticated, back to the challenging aspect above. Okay, this sort of puts my finger on the issue in my mind. The reason this is cropping up now is that we want to get to the point where a MIME headers are always generated (I assume this is non-controversial). Using the tools we have, this means running mhbuild. This was never designed to be run all of the time, hence the issues with directives. The reason all of these various suggestions regarding putting mhbuild directives in the text feel wrong to me is that it BY DEFAULT assigns special meaning to the message body where there was none before. That seems like a major change, and just feels wrong. I know, David suggested looking for false mhbuild directives, but in addition to the technical challenges that just feels wrong to me; trying to guess what is and isn't a directive suggests to me that we're doing the wrong thing. It's fine for users who WANT to create mhbuild directives, but it just Seems Wrong that message bodies now assign special meaning to '#' at the beginning of the line. That would mean we're now unilaterally switching from users creating a message draft to a mhbuild composition file. In contrast, the current implementation of attach that creates a special header actually feels more right; creating headers and having the tools use them to process a message is more the MH way, as we've seen time and time again. Can the people who want to have attach append mhbuild directives explain what their thinking is, specifically why they think their approach is preferrable? I went back and looked at the thread very carefully, and none of the proponents of this approach really covered why they thought this was better. Ok, Ralph did say that he wanted to look at the headers post-MIMEification to adjust them; I kinda feel that's an expert mode feature and people who want to do that are probably comfortable with mhbuild directives. I really do want to understand people's arguments before I make a decision. (It occurs to me that the logic to do the MIME to filetype mapping that is done in post really should be moved into mhbuild, as that's more mhbuild's job. Just an implementation detail, though). --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Ken Hornstein writes: Gave this a bit more thought. What *exactly* is the issue? Is it a lack of confidence that attach will do the *right thing* and the desire to check and change it if desired? No, I read it as people are suggesting to solve the mime/attach conflict to change attach to appending mhbuild directives to the message body (I believe that is bad idea, for reasons enumerated before). I will note one thing: I discovered recently that mutt supports an Attach header, which does exactly what you'd expect it to do. So there is prior art here. --Ken Humph! Have to check the logs, I thought that I was the prior art. Humbug. Jon ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Ken wrote: Can the people who want to have attach append mhbuild directives explain what their thinking is, specifically why they think their approach is preferrable? I went back and looked at the thread very carefully, and none of the proponents of this approach really covered why they thought this was better. To me, the big advantage was simplifying that decision logic that you presented. It just seems more complex than necessary. The ability to review/edit mhbuild output is a bonus, but not a primary goal for me. Another bonus would be to move error checking up: instead of send(1) tripping over a nonexistant file, whatnow(1) would. That's not of much value to me because I always ls before attach'ing, so again it minor to me. I have no problem putting parameters in pseudo-headers rather than directives in the body, if that's where you're headed. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Ken wrote: [Ralph wrote:] If attach instead appended an mhbuild directive to the draft, would that make the path after that simpler? No. My feeling is that if you put a mhbuild directive in the draft, you're prepared to deal with any issues arising from it. But I don't think it's reasonable to use attach and have it put mhbuild directives in the body of the email. Why wouldn't that be reasonable? The logic would be simpler: In WhatNow? - If you run mime, run mhbuild on the draft. - If you attach, add the appropriate mhbuild directive. Do not do this if there is a MIME-Version header. In post(8): - Run mhbuild -auto -nodirectives. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Why wouldn't that be reasonable? The logic would be simpler:
In WhatNow?
- If you run mime, run mhbuild on the draft.
- If you attach, add the appropriate mhbuild directive. Do not do
this if there is a MIME-Version header.
In post(8):
- Run mhbuild -auto -nodirectives.
The problem here is that if you use -nodirectives, then the directives that
attach put in the draft wouldn't be executed.
Ralph said:
It would also mean I could attach, then edit to look at it, perhaps
embellish, then mime to process it, then edit again to check things
over before I send
You can do this now; if you attach, you can edit the draft and adjust the
pseudo-header that attach adds.
The problem with using mhbuild directives is that it creates special
semantics for the message body; specifically, you can't have lines that
start with '#' without special escaping. That's fine for people who
want to do that, but I think it's a poor solution for the average user.
I was thinking of a special #attach directive that used the same logic
as attach; instead of:
#image/jpeg {attachment} /tmp/foo.jpg
You'd just have:
#attach /tmp/foo.jpg
To provide an easier-to-use MIME experience that covers the common case.
--Ken
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Why wouldn't that be reasonable? The logic would be simpler:
In WhatNow?
- If you run mime, run mhbuild on the draft.
- If you attach, add the appropriate mhbuild directive. Do not do
this if there is a MIME-Version header.
In post(8):
- Run mhbuild -auto -nodirectives.
The problem here is that if you use -nodirectives, then the
directives that attach put in the draft wouldn't be executed.
I think it'd be worth trying to solve that. Could we look for
false mhbuild directives and escape them if not already escaped?
Then we wouldn't need to default to -nodirectives. Directives
are arcane enough that I think collisions with non-directive
text are unlikely. But maybe those who have been using them for
the last decade should comment on that :-)
Ralph said:
It would also mean I could attach, then edit to look at it, perhaps
embellish, then mime to process it, then edit again to check things
over before I send
You can do this now; if you attach, you can edit the draft and adjust the
pseudo-header that attach adds.
It's not the pseudo-header, it's the mhbuild directives. attach
users can't view/modify them now. This would be a benefit, and
though I have cured myself of the urge to look at them, I would if
I could.
The problem with using mhbuild directives is that it creates special
semantics for the message body; specifically, you can't have lines that
start with '#' without special escaping. That's fine for people who
want to do that, but I think it's a poor solution for the average user.
If we're going to address that, I think we should step back and
consider whether some other approach would make sense. I don't
think adding more directive types just to simplify the user
interface is a good idea.
I was thinking of a special #attach directive that used the same logic
as attach; instead of:
#image/jpeg {attachment} /tmp/foo.jpg
You'd just have:
#attach /tmp/foo.jpg
To provide an easier-to-use MIME experience that covers the common case.
At the cost of arcane-ness, which would increase the likelihood
of confusion of text with an mhbuild directive.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
As the guy who created this mess in the first place, I appreciate the work that y'all are doing 'cause I unfortunately don't have time right now. I take the blame for attach beinging incompatible with mhbuild because it uses mhbuild internally. The problem is that attach has to deal with drafts that contain lines that begin with a # because the draft might be something like a snippet of C code with #include or something. So I don't think that adding more magic directives is really going to help. I personally don't have any problem with the way that it works now. I never use mhbuild directly, and am happy seeing the list of attachments with al at whatnow; I don't need to see them expanded as gobs of gibberish. If I was going to pick at something that is truly error-prone that I screw up all of the time it's forwarding and replying to multipart messages. I don't like automime because it needlessly complicates simple messages, but I often forget to mime things at whatnow and screw 'em up. What I like about attach is that it just does the right thing and I don't have to know how it does it internally. It would be really nice if the same were true with other parts of the ui. The nmh MIME support comes across to me as a wart. No offense intended, it's a really useful wart and I use it every day. But it's not really integrated into the ui in a pleasant way. I would be more interested in rethinking the ui in a holistic way than picking at details that exist because of how the ui evolved. And I wish that I had time to contribute more. Jon ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Hi Ken, It would also mean I could attach, then edit to look at it, perhaps embellish, then mime to process it, then edit again to check things over before I send You can do this now; if you attach, you can edit the draft and adjust the pseudo-header that attach adds. It does not allow me to look at it post-mime, as mhbuild directives do. Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
I think it'd be worth trying to solve that. Could we look for
false mhbuild directives and escape them if not already escaped?
I think it would be challenging; the code that does that is the regular
MIME parsing code. Also, the syntax is that if it's not something that
is recognized after the #, then it's a content-type.
Then we wouldn't need to default to -nodirectives. Directives
are arcane enough that I think collisions with non-directive
text are unlikely. But maybe those who have been using them for
the last decade should comment on that :-)
So, I fit that bill. Here's the evolution of my thinking:
- I use to run with automimeproc set. But that's lousy; if you include C
code in your text, it fails. Totally non-obvious and I always forget it.
It got to be such a problem that I turned it off.
- I use mhbuild directives, and I use them enough that I remember the syntax.
But it's a fair amount of typing. E.g.:
#application/pdf {attachment} /path/to/file
Also, no auto-complete! It works and you get exact control over the
MIME content, but it sucks.
- Attach is, FOR THE GENERAL case, much nicer. Does the right thing and
I can forget about the details.
It's not the pseudo-header, it's the mhbuild directives. attach
users can't view/modify them now. This would be a benefit, and
though I have cured myself of the urge to look at them, I would if
I could.
Well, that's what I was thinking with #attach; that would give you the
benefits of attach (picking the MIME type and automatically adding
the right disposition).
If we're going to address that, I think we should step back and
consider whether some other approach would make sense. I don't
think adding more directive types just to simplify the user
interface is a good idea.
Well, I'm not completely wedded to this idea; that's why I asked for
feedback. What do you think we should do instead?
At the cost of arcane-ness, which would increase the likelihood
of confusion of text with an mhbuild directive.
More arcane than the existing syntax? :-)
--Ken
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
You can do this now; if you attach, you can edit the draft and adjust the pseudo-header that attach adds. It does not allow me to look at it post-mime, as mhbuild directives do. I guess my feeling is that attach is for people who don't want to look at the content post-mime. But that's what the #attach directive would accomplish. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Gave this a bit more thought. What *exactly* is the issue? Is it a lack of confidence that attach will do the *right thing* and the desire to check and change it if desired? If so, I have two fairly simple suggestions: 1. Add a -check option to the whatnow attach command that generates a list of attachments whatever you want like content-type, encoding, etc. 2. Allow options on the attachment header so that the content-type, encoding, etc. can be overridden. Jon ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
I think it'd be worth trying to solve that. Could we look for false mhbuild directives and escape them if not already escaped? I think it would be challenging; the code that does that is the regular MIME parsing code. Also, the syntax is that if it's not something that is recognized after the #, then it's a content-type. Challenging but I think it would be possible. It's not the pseudo-header, it's the mhbuild directives. attach users can't view/modify them now. This would be a benefit, and though I have cured myself of the urge to look at them, I would if I could. Well, that's what I was thinking with #attach; that would give you the benefits of attach (picking the MIME type and automatically adding the right disposition). Let me add that being able to view/modify the mhbuild directives inserted by attach would be a very, very small benefit. I don't even think about it any more. If we're going to address that, I think we should step back and consider whether some other approach would make sense. I don't think adding more directive types just to simplify the user interface is a good idea. Well, I'm not completely wedded to this idea; that's why I asked for feedback. What do you think we should do instead? I just realized that I misunderstood something: -nodirectives means don't process directives, not something else that I thought. So, would this work: In WhatNow? - If you run mime, run mhbuild on the draft. - If you attach, add the appropriate mhbuild directive. Refuse if if there is a MIME-Version header. Optionally, run mime when you're done attaching if you want to see/edit what mhbuild did. In send(1): - If there were any attach calls (Nmh-Attachment header), run mime if there isn't a MIME-Version header. In post(8): - Run mhbuild -auto -nodirectives. To deal with the false directives when using attach: WhatNow could look for any lines that begin with # during the first call to attach, and warn or refuse. Those who use # for replied-to text would have to find something else. Or we could get more sophisticated, back to the challenging aspect above. This is where we want to end up, right: 1) Run mhbuild -directives if the draft has directives and doesn't have false directives. 2) Always run mhbuild -auto -nodirectives. At the cost of arcane-ness, which would increase the likelihood of confusion of text with an mhbuild directive. More arcane than the existing syntax? :-) My point was that #attach is less arcane, I didn't say that clearly. It's therefore more likely to get confused with text that isn't intended to be a directive. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Jon wrote: Gave this a bit more thought. What *exactly* is the issue? I'll take a shot, but Ken can probably do better: we want nmh to always produce mime messages without getting confused by text that isn't a mhbuild directive but looks like it, while still supporting attach. Is it a lack of confidence that attach will do the *right thing* Not for me. and the desire to check and change it if desired? If we can get that easily, but I don't think it's a priority. If so, I have two fairly simple suggestions: 1. Add a -check option to the whatnow attach command that generates a list of attachments whatever you want like content-type, encoding, etc. That would be neat, and easy if whatnow inserted build directives. Or, we could move the guts of attach out of send so that whatnow could get to them for this purpose. But again, I don't think it's a high priority. 2. Allow options on the attachment header so that the content-type, encoding, etc. can be overridden. No! :-) mhbuild directives aren't going away and should be used if overrides are needed. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Hi Ken,
But it's a fair amount of typing. E.g.:
#application/pdf {attachment} /path/to/file
Also, no auto-complete!
Don't know what editor you're using, but in vim I
!!ls /s^I/lo^I/pa^I/to/f^I
on a blank line to get auto-complete on /some/long/path/to/file.
Cheers, Ralph.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Me again,
But it's a fair amount of typing. E.g.:
#application/pdf {attachment} /path/to/file
Also, no auto-complete!
Don't know what editor you're using, but in vim I
!!ls /s^I/lo^I/pa^I/to/f^I
on a blank line to get auto-complete on /some/long/path/to/file.
Thinking it must have a built-in method, I found vim has ^X^F in
insert-mode, so /etc/pa^X^F.
Cheers, Ralph.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
Hi Ken, The way that attach works is that when you mark a file to be attached, it ends up with a special header in the message. post(8) sees this header and constructs mhbuild directives and runs it for you. That works fine. The way the mime command works is that it just runs mhbuild for you; any mhbuild directives in the draft end up being processed to build the final draft. If attach instead appended an mhbuild directive to the draft, would that make the path after that simpler? Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Conflict between mime command and attach
If attach instead appended an mhbuild directive to the draft, would that make the path after that simpler? No. My feeling is that if you put a mhbuild directive in the draft, you're prepared to deal with any issues arising from it. But I don't think it's reasonable to use attach and have it put mhbuild directives in the body of the email. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] Conflict between mime command and attach
The final piece to making MIME encoding happen by default to simply run it at send(1) time (really post(8)). But as always, there's a slight wrinkle. Right now we have two basic ways of doing attaching files; you can use the attach command at the What now? prompt, or put in mhbuild(1) directives and execute mhbuild via the mime command at the What now? prompt. But these two things don't place nicely together. First off, I already know some people don't like attach, and some people don't like writing mhbuild directives. That's fine ... I think both approaches are valid and each has their positives and negatives. I can probably already recite the arguments made by everyone here, so there's no need to rehash them now :-) I'm more concerned about technical details. The way that attach works is that when you mark a file to be attached, it ends up with a special header in the message. post(8) sees this header and constructs mhbuild directives and runs it for you. That works fine. The way the mime command works is that it just runs mhbuild for you; any mhbuild directives in the draft end up being processed to build the final draft. As an additional wrinkle, we now always want to run mhbuild automatically, which would (in theory) use a not-yet-written flag called -auto to make it exit silently if the draft always has a MIME-Version header. The basic problem today is that if you use attach it will interfere with the mime command; the mhbuild invocation will run as part of the mime command, and when post(8) goes to run mhbuild for the attach command headers you'll get an error (because it will get an error because it's already been MIME-ified). So it seems to be the right approach is to lock out both attach and mime at WhatNow? time; you can either do one or the other, but not both. That's relatively straightforward. So the logic would be: In WhatNow? - If you run mime, run mhbuild on the draft. Do not run if there's a Nmh-Attachment header. - If you attach, add the appropriate header. Do not do this if there is a MIME-Version header. In post(8): - If there's a Nmh-attachment header, construct the mhbuild directives and run mhbuild. - Otherwise, run mhbuild -auto -nodirectives. (-auto will cause it to silently exit if there's a MIME-Version header; -nodirectives will cause it to ignore directives by default unless they're explicitly enabled). Thoughts? --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
