My apologies for the delay ... been busy, wanted to give this some thought.
>repl would need to determine the correct charset parameter and >C-T-E, and would also need to check that there was exactly one >iCalendar request in the message being replied to. I'm not sure >what to do if there's more than one. I have yet to receive such >a message, so my inclination is to punt. The user could instead >extract and reply to each request by itself. Or, repl could >reply to each one the same way. I don't think it's worth >complicating the interface to support different replies to >multiple requests in a message. Some meta-thoughts: - What were your thoughts in terms of what the interface would look like at the "repl" level? Just a new switch? Did you want to make it more generic? - What were you thinking in terms of implementation details? Yes, I understand about the mhical utility, but I was thinking of what you'd need in all of the other tools to make it work. - Are you sure you want to have a mhbuild directive in the reply? The last question is actually the most interesting one. We're trying to grapple with the larger meta-question on how to better handle MIME. I think for the tools that display or process message content we have a reasonable handle on what needs to be done. Sure, there's a lot of work that needs to be done there, but I don't think any of it is particularly controversial. Composing a new message is a bit more complicated, but I think with the update to the attachment system we have a reasonable thing in place. There are implementation warts, but those should easily be fixable. This handles the 95% case where we want text content followed by one or more non-text parts. For people who want to have complete control over their MIME content, mhbuild directives are still available. But I've been using the Attach: headers recently and they are very nice; I'm happy how that worked out and the new implementation feels much more like the "MH way", in that headers are used to control message processing. If people disagree with this, I'd like to hear about it and your suggestions for a better composition interface. Now, replying to a message is kind of an unholy combination of displaying and composition. We've never really figured out how to bridge the gap here very well. To be fair, nobody else seems to handle this really well either; a few things are special-cased in MUAs (like calendar requests, although in my experience what happens there is that you have to do something at message display time) but mostly they don't deal with non-text parts for replies. Maybe we should do better! The question is ... what do we do? A general thought is that we shouldn't have nmh commands output mhbuild directives into drafts. That just seems like the wrong approach; it gives special meaning to the message body and it requires the user to know to run the "mime" command at the WhatNow? prompt. The more I use it, the more I think the attach command's general interface is more reasonable; headers already have special meaning, we have a specialized tool to manipulate them (anno) and it seems to work out well in practice. People will point out that some MH commands already emit mhbuild directives, but I view that as a wart that shouldn't be repeated. Specifically, if you run "forw -mime", instead of a message that contains: #forw +inbox 8 22 You should probably have a message that has a header like this: Forward: +inbox 8 22 Or, maybe, something else; that's just an off-the-cuff idea. So it occurs to me that maybe we should have some mechanism to allow repl to insert generic headers into the reply draft that mhbuild could later process. The devil really is in the details there, though; the mechanics of that would have to be carefully thought out. --Ken _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
