* [sup-talk] [PATCH] Config control over how From address is generated when replying.
@ 2008-04-27 6:49 William Morgan
2008-04-28 4:11 ` Marc Hartstein
0 siblings, 1 reply; 6+ messages in thread
From: William Morgan @ 2008-04-27 6:49 UTC (permalink / raw)
Hi Marc,
Reformatted excerpts from Marc Hartstein's message of 2008-04-23:
> Two new boolean options are now recognized in .sup/config.yaml
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.
You could actually technically accomplish this already with the
before-edit hook, but I'd be happy with a special purpose hook.
--
William <wmorgan-sup at masanjin.net>
^ permalink raw reply [flat|nested] 6+ messages in thread* [sup-talk] [PATCH] Config control over how From address is generated when replying. 2008-04-27 6:49 [sup-talk] [PATCH] Config control over how From address is generated when replying William Morgan @ 2008-04-28 4:11 ` Marc Hartstein 2008-04-29 16:19 ` William Morgan 0 siblings, 1 reply; 6+ messages in thread From: Marc Hartstein @ 2008-04-28 4:11 UTC (permalink / raw) 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: <http://rubyforge.org/pipermail/sup-talk/attachments/20080428/5bcbc136/attachment.bin> ^ permalink raw reply [flat|nested] 6+ messages in thread
* [sup-talk] [PATCH] Config control over how From address is generated when replying. 2008-04-28 4:11 ` Marc Hartstein @ 2008-04-29 16:19 ` William Morgan 2008-06-12 16:05 ` [sup-talk] [PATCH] add reply-from hook for user-defined handling of default from in replies Marc Hartstein 0 siblings, 1 reply; 6+ messages in thread From: William Morgan @ 2008-04-29 16:19 UTC (permalink / raw) Reformatted excerpts from Marc Hartstein's message of 2008-04-27: > 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). There's that, and there's the fact that people want all sorts of crazy things to happen with their email and I'd rather provide them a programming language to describe their ideas than have to implement a configuration option for each one. > 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. You're right. I was thinking before-edit passed in the message object. > 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. What about something that more specifically addresses the problem at hand? E.g. a reply-from hook, that takes the message object, and returns a Person object to be used as the from? Adding a hook is very low cost, so I'm not opposed to having fairly specific things like this. > 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. Yeah... I discovered on 4/27 that all my outgoing messages since 4/23 had been discarded. So I re-sent them with Sup's edit-as-new command, which doesn't preserve Reply-To and References headers. It probably should. Sorry! -- William <wmorgan-sup at masanjin.net> ^ permalink raw reply [flat|nested] 6+ messages in thread
* [sup-talk] [PATCH] add reply-from hook for user-defined handling of default from in replies 2008-04-29 16:19 ` William Morgan @ 2008-06-12 16:05 ` Marc Hartstein 2008-06-12 16:12 ` Marc Hartstein 0 siblings, 1 reply; 6+ messages in thread From: Marc Hartstein @ 2008-06-12 16:05 UTC (permalink / raw) The reply-from hook can now be used to process headers in a different manner than the default for purposes of generating a default From: header when replying to an email. --- lib/sup/modes/reply-mode.rb | 23 ++++++++++++++++++++++- 1 files changed, 22 insertions(+), 1 deletions(-) diff --git a/lib/sup/modes/reply-mode.rb b/lib/sup/modes/reply-mode.rb index e7b2929..d6a7dc6 100644 --- a/lib/sup/modes/reply-mode.rb +++ b/lib/sup/modes/reply-mode.rb @@ -19,6 +19,16 @@ Return value: A string containing the text of the quote line (can be multi-line) EOS + HookManager.register "reply-from", <<EOS +Selects a default address for the From: header of a new reply. +Variables: + message: a message object representing the message being replied to + (useful values include message.recipient_email, message.to, and message.cc) +Return value: + A Person to be used as the default for the From: header, or nil to use the + default behavior. +EOS + def initialize message @m = message @@ -29,8 +39,19 @@ EOS ## first, determine the address at which we received this email. this will ## become our From: address in the reply. + hook_reply_from = HookManager.run "reply-from", :message => @m + + ## sanity check that selection is a Person (or we'll fail below) + ## don't check that it's an Account, though; assume they know what they're doing. + if hook_reply_from && !(hook_reply_from.is_a? Person) + Redwood::log "reply-from returned non-Person, using default from." + hook_reply_from = nil + end + from = - if @m.recipient_email && AccountManager.is_account_email?(@m.recipient_email) + if hook_reply_from + hook_reply_from + elsif @m.recipient_email && AccountManager.is_account_email?(@m.recipient_email) PersonManager.person_for(@m.recipient_email) elsif(b = (@m.to + @m.cc).find { |p| AccountManager.is_account? p }) b -- 1.5.3.7 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [sup-talk] [PATCH] add reply-from hook for user-defined handling of default from in replies 2008-06-12 16:05 ` [sup-talk] [PATCH] add reply-from hook for user-defined handling of default from in replies Marc Hartstein @ 2008-06-12 16:12 ` Marc Hartstein 2008-06-19 17:56 ` William Morgan 0 siblings, 1 reply; 6+ messages in thread From: Marc Hartstein @ 2008-06-12 16:12 UTC (permalink / raw) Excerpts from Marc Hartstein's message of Thu Jun 12 12:05:46 -0400 2008: > The reply-from hook can now be used to process headers in a different manner > than the default for purposes of generating a default From: header when > replying to an email. Note that this patch is against master; it requires a bit of (trivial) handholding to apply to next, as patch cannot figure out how to apply it with the excellent reply-to patch in place. I decided to check that the return value is a Person (else later code would fail), but not to confirm that it's actually a registered Account -- if someone wants to do something weird like that, I'll assume they meant to. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20080612/5f4b8fce/attachment.bin> ^ permalink raw reply [flat|nested] 6+ messages in thread
* [sup-talk] [PATCH] add reply-from hook for user-defined handling of default from in replies 2008-06-12 16:12 ` Marc Hartstein @ 2008-06-19 17:56 ` William Morgan 0 siblings, 0 replies; 6+ messages in thread From: William Morgan @ 2008-06-19 17:56 UTC (permalink / raw) Reformatted excerpts from marc.hartstein's message of 2008-06-12: > Excerpts from Marc Hartstein's message of Thu Jun 12 12:05:46 -0400 2008: > > The reply-from hook can now be used to process headers in a different manner > > than the default for purposes of generating a default From: header when > > replying to an email. In next. Thanks! > I decided to check that the return value is a Person (else later code > would fail), but not to confirm that it's actually a registered > Account -- if someone wants to do something weird like that, I'll > assume they meant to. I think that makes sense. -- William <wmorgan-sup at masanjin.net> ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2008-06-19 17:56 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-04-27 6:49 [sup-talk] [PATCH] Config control over how From address is generated when replying William Morgan 2008-04-28 4:11 ` Marc Hartstein 2008-04-29 16:19 ` William Morgan 2008-06-12 16:05 ` [sup-talk] [PATCH] add reply-from hook for user-defined handling of default from in replies Marc Hartstein 2008-06-12 16:12 ` Marc Hartstein 2008-06-19 17:56 ` William Morgan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox