* [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; 7+ 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] 7+ 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; 7+ 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] 7+ 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; 7+ 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] 7+ 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; 7+ 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] 7+ 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; 7+ 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] 7+ 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; 7+ 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] 7+ messages in thread
* [sup-talk] [PATCH] Config control over how From address is generated when replying.
@ 2008-04-23 21:02 Marc Hartstein
0 siblings, 0 replies; 7+ messages in thread
From: Marc Hartstein @ 2008-04-23 21:02 UTC (permalink / raw)
Two new boolean options are now recognized in .sup/config.yaml
:reply_from_recipient: Check headers for the real email address the message
ultimately arrived at, and use it if it's one of
your accounts (or an alternate/regexp for such).
:reply_from_tocc: Check To and CC for an address which matches one of
your accounts and use the first such found.
Both options default to true if missing, preserving the traditional sup
behavior.
Setting ...recipient to false and ...tocc to true will emulate mutt's behavior
with reverse_name=true
Setting both to false will always reply from your default account.
---
lib/sup/modes/reply-mode.rb | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/sup/modes/reply-mode.rb b/lib/sup/modes/reply-mode.rb
index e7b2929..82ce912 100644
--- a/lib/sup/modes/reply-mode.rb
+++ b/lib/sup/modes/reply-mode.rb
@@ -29,10 +29,12 @@ EOS
## first, determine the address at which we received this email. this will
## become our From: address in the reply.
+ check_recipient = $config[:reply_from_recipient].nil? || $config[:reply_from_recipient]
+ check_tocc = $config[:reply_from_tocc].nil? || $config[:reply_from_tocc]
from =
- if @m.recipient_email && AccountManager.is_account_email?(@m.recipient_email)
+ if check_recipient && @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 })
+ elsif check_tocc && (b = (@m.to + @m.cc).find { |p| AccountManager.is_account? p })
b
else
AccountManager.default_account
--
1.5.3.7
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2008-06-19 17:56 UTC | newest]
Thread overview: 7+ 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
-- strict thread matches above, loose matches on Subject: below --
2008-04-23 21:02 [sup-talk] [PATCH] Config control over how From address is generated when replying Marc Hartstein
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox