From mboxrd@z Thu Jan 1 00:00:00 1970 From: marc.hartstein@alum.vassar.edu (Marc Hartstein) Date: Mon, 28 Apr 2008 00:11:06 -0400 Subject: [sup-talk] [PATCH] Config control over how From address is generated when replying. In-Reply-To: <1209278945-sup-1601@south> References: <1209278945-sup-1601@south> Message-ID: <1209354047-sup-9578@cabinet> Excerpts from William Morgan's message of Sun Apr 27 02:49:25 -0400 2008: > I appreciate the idea behind this patch, but I'm making a concerted > effort to keep the config options down to a minimum. I'd prefer a hook > that passed in all the relevant header values as parameters > (@m.recipient_email, @m.to, @m.cc, etc) and returned the desired From: > address. Then people can implement their own logic without the config > file starting down the path of Mutt-style configuration insanity. I can appreciate the desire not to have so many configuration settings that you have to read through a tome to find the one you want (and might simply never know that the one you want exists). Is there a reason not to simply pass in the message object to the hook, as is done for attribution? > You could actually technically accomplish this already with the > before-edit hook, but I'd be happy with a special purpose hook. I didn't see any straightforward way to do it using before-edit, as before-edit is only passed the header hash and the body. Unless the References/In-Reply-To headers contain enough information to pull up the message being replied to, the information I'm using isn't available. I have two thoughts on how to do this right now, on which I'd appreciate input. First, a new hook "before-edit-reply", like before-edit but with a third parameter which is the message to which the user is replying. Should probably be called in addition to before-edit so users don't have to repeat themselves between the two (or explicitly make their before-edit-reply call into their before-edit). The second idea is to modify before-edit to provide the message object for the message being replied to or forwarded, if any, and some indication of whether this is a brand-new message, a reply, a forward, or a bounce. User can then put all the logic in here, which I think makes sense. However, it changes an existing API, and I don't know if it can be done in a way which doesn't break current before-edit hooks. I think I slightly prefer the change to before-edit approach, mostly because it allows for the forward and bounce cases if somebody wants to do some special handling there. I'd definitely like some feedback, though, as I'm not quite happy with either idea. Thanks for getting back to me, Marc P.S. William, I noticed your recent round of posts to the list lacked In-Reply-To and References headers, so they didn't thread with the posts they were replying to. Want to make sure you're aware of it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: not available URL: