[notmuch] [PATCH 5/9] Forward individual messages using message-forward

[Keith Amidon]

{-- Sat, 28 Nov 2009 09:49:58 -0800: Carl  wrote: --}
  Carl> So when there are quick and easy things, (like calling an
  Carl> existing function on an 'f' binding like above), that totally
  Carl> makes sense to do. We can look at things like that as interim
  Carl> solutions until the C program grows up.

  Carl> Long-term, I do expect a lot of features to end up being
  Carl> implemented in the C program.

Thanks for your perspective on the best place for things to be
implemented.  I like the pragmatism of using what's easily available in
emacs now and moving to using functions provided by the C implementation
as they become available in the future.  

Since I have relatively limited time right now, I'll probably be a lot
more productive hacking elisp code.  I won't get too attached to that
code though... :-)

--- Keith

[notmuch] [PATCH 5/9] Forward individual messages using message-forward

[Carl Worth]

On Sat, 28 Nov 2009 09:32:00 -0800, Keith Amidon  
wrote:
> What are your thoughts generally about integration with things like
> message mode vs. implementing more into the C program?  If you think the
> message-mode enhancements will have a life I'll spend some time on this
> and getting the semi-broken version of the reply functions I posted
> working more correctly as well.

My style has generally been to do whatever I think is easiest. And since
I'm a user of the emacs interface to notmuch, that often means trying to
use some of the very full-featured code within emacs first.

But then again, as you've seen, just trying to figure out to use that
code can be a challenge in and of itself. And meanwhile, the
improvements to the C program will benefit the other backends.

So when there are quick and easy things, (like calling an existing
function on an 'f' binding like above), that totally makes sense to
do. We can look at things like that as interim solutions until the C
program grows up.

Long-term, I do expect a lot of features to end up being implemented in
the C program.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

[notmuch] [PATCH 5/9] Forward individual messages using message-forward

[Keith Amidon]

{-- Fri, 27 Nov 2009 21:15:15 -0800: Carl  wrote: --}


  Carl> On Fri, 27 Nov 2009 05:30:11 -0800, camalot at picnicpark.org wrote:
  >> From: Keith Amidon 
  >> Sometimes forwarding a message is preferable to replying and
  >> modifying the set of recipients.  This commit provides that ability
  >> using the message-forward function.

  Carl> This is nice functionality---we were obviously missing a
  Carl> "forward" command before. So I've pushed this.

Thanks.

  Carl> Meanwhile, this does miss one piece of functionality that we
  Carl> have in "notmuch reply" which is to select the From: address
  Carl> based on which configured email address of the user was found in
  Carl> the recipient list of the original message being forwarded.

  Carl> Any suggestion for this functionality? Does message-mode provide
  Carl> something similar? And if so, should notmuch.el simply read the
  Carl> notmuch configuration for the various email addresses and
  Carl> provide them to message-mode? I definitely don't want new users
  Carl> of notmuch to have to configure email addresses both inside of
  Carl> notmuch and also inside of message-mode, for example.

I'm sure message-mode can be tweaked either gracefully or savagely in
order to provide this.  I'd be happy to look into it although I
unfortunately don't have a lot of time to code right now. 

What are your thoughts generally about integration with things like
message mode vs. implementing more into the C program?  If you think the
message-mode enhancements will have a life I'll spend some time on this
and getting the semi-broken version of the reply functions I posted
working more correctly as well.

   --- Keith

Re: [notmuch] [PATCH 5/9] Forward individual messages using message-forward

[Keith Amidon]

{-- Sat, 28 Nov 2009 09:49:58 -0800: Carl cwo...@cworth.org wrote: --}
  Carl So when there are quick and easy things, (like calling an
  Carl existing function on an 'f' binding like above), that totally
  Carl makes sense to do. We can look at things like that as interim
  Carl solutions until the C program grows up.

  Carl Long-term, I do expect a lot of features to end up being
  Carl implemented in the C program.

Thanks for your perspective on the best place for things to be
implemented.  I like the pragmatism of using what's easily available in
emacs now and moving to using functions provided by the C implementation
as they become available in the future.  

Since I have relatively limited time right now, I'll probably be a lot
more productive hacking elisp code.  I won't get too attached to that
code though... :-)

--- Keith



___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] [PATCH 5/9] Forward individual messages using message-forward

[Carl Worth]

On Fri, 27 Nov 2009 05:30:11 -0800, camalot at picnicpark.org wrote:
> From: Keith Amidon 
> 
> Sometimes forwarding a message is preferable to replying and modifying
> the set of recipients.  This commit provides that ability using the
> message-forward function.

This is nice functionality---we were obviously missing a "forward"
command before. So I've pushed this.

Meanwhile, this does miss one piece of functionality that we have in
"notmuch reply" which is to select the From: address based on which
configured email address of the user was found in the recipient list of
the original message being forwarded.

Any suggestion for this functionality? Does message-mode provide
something similar? And if so, should notmuch.el simply read the notmuch
configuration for the various email addresses and provide them to
message-mode? I definitely don't want new users of notmuch to have to
configure email addresses both inside of notmuch and also inside of
message-mode, for example.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: