sup talk - Apr 2008 - [PATCH] Config control over how From address is generated when replying.

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>

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>

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>

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

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>

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>