Emacs client scalability for long, deeply-nested threads

[Michael Hudson-Doyle]

I have encountered this too.  A C-u before entering the thread helps
(this means already read messages are not rendered I think), as does a
M-x notmuch-show-toggle-thread-indentation .  Something less manual
would be nice, I guess...

On 24 March 2015 at 07:09, Jed Brown  wrote:
> I occasionally end up with threads containing several hundred messages
> and deep nesting.  Eventually, displaying them exceeds the default
> max-specpdl-size and later max-lisp-eval-depth.  These variables can be
> increased, but the time required to display the thread stretches to
> minutes.  Does anyone have suggestions for improving performance in such
> scenarios?
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
>

Re: Emacs client scalability for long, deeply-nested threads

[Michael Hudson-Doyle]

I have encountered this too.  A C-u before entering the thread helps
(this means already read messages are not rendered I think), as does a
M-x notmuch-show-toggle-thread-indentation .  Something less manual
would be nice, I guess...

On 24 March 2015 at 07:09, Jed Brown j...@59a2.org wrote:
 I occasionally end up with threads containing several hundred messages
 and deep nesting.  Eventually, displaying them exceeds the default
 max-specpdl-size and later max-lisp-eval-depth.  These variables can be
 increased, but the time required to display the thread stretches to
 minutes.  Does anyone have suggestions for improving performance in such
 scenarios?

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

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

auto-choosing reply addresses in notmuch-emacs

[Michael Hudson-Doyle]

Jameson Graef Rollins  writes:

> Hi, folks.  I wonder if anyone knows of a way to tell the emacs client
> to use different email addresses to respond to mail from different
> sources.  So for instance, I would like to respond to mail to one
> mailing list from one address, and to another mailing list from a
> different address.  Ideally I would be able to set up some sort of
> filter rules such that if the mail is from ".*@example.com" I would
> respond with my me at example.com address, and if the mail is from
> ".*@example.org" I would respond with my jrollins at finestructure.net
> address.
>
> Does anyone already do anything like this?  I would how hard it would be
> to setup built-in support for something like that.  Given that notmuch
> generates replies, maybe we could add it to the notmuch cli somehow,
> with some new config fields?

You can use gnus-alias for this.  Put

(autoload 'gnus-alias-determine-identity "gnus-alias" "" t)
(add-hook 'message-setup-hook 'gnus-alias-determine-identity)

in .emacs and then M-x customize-group gnus-alias.  I would be more
helpful but I no longer need this functionality and have forgotten how
it works :)

Cheers,
mwh
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 

Re: auto-choosing reply addresses in notmuch-emacs

[Michael Hudson-Doyle]

Jameson Graef Rollins jroll...@finestructure.net writes:

 Hi, folks.  I wonder if anyone knows of a way to tell the emacs client
 to use different email addresses to respond to mail from different
 sources.  So for instance, I would like to respond to mail to one
 mailing list from one address, and to another mailing list from a
 different address.  Ideally I would be able to set up some sort of
 filter rules such that if the mail is from .*@example.com I would
 respond with my m...@example.com address, and if the mail is from
 .*@example.org I would respond with my jroll...@finestructure.net
 address.

 Does anyone already do anything like this?  I would how hard it would be
 to setup built-in support for something like that.  Given that notmuch
 generates replies, maybe we could add it to the notmuch cli somehow,
 with some new config fields?

You can use gnus-alias for this.  Put

(autoload 'gnus-alias-determine-identity gnus-alias  t)
(add-hook 'message-setup-hook 'gnus-alias-determine-identity)

in .emacs and then M-x customize-group gnus-alias.  I would be more
helpful but I no longer need this functionality and have forgotten how
it works :)

Cheers,
mwh


pgpwzJa2lD49k.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

How much is not much?

[Michael Hudson-Doyle]

James Cloos  writes:

> The last time I tried to run notmuch new on my incoming archive it
> crashed the box.
>
> But back then the archive was on an external drive, several usb-storage
> and general usb bugs have been fixed since then, and my dives are all
> internal now.
>
> So it is time for another try.
>
> But first, how much ram and disk should I expect to need, as a function
> of the size of the maildir archive?
>
> (It is a tree of dirs, with maildir dirs at the leaves.  OTOH 20+ M
> messages and just under 256 Go, base on du(1).)
>
> Trying to avoid data loss due to crashes...

I can't answer to memory, but as a rule of thumb the notmuch database
seems to be around the same size as the mail it indexes.  I think by any
measure you have quite a lot of mail :-)

Cheers,
mwh

Re: How much is not much?

[Michael Hudson-Doyle]

James Cloos cl...@jhcloos.com writes:

 The last time I tried to run notmuch new on my incoming archive it
 crashed the box.

 But back then the archive was on an external drive, several usb-storage
 and general usb bugs have been fixed since then, and my dives are all
 internal now.

 So it is time for another try.

 But first, how much ram and disk should I expect to need, as a function
 of the size of the maildir archive?

 (It is a tree of dirs, with maildir dirs at the leaves.  OTOH 20+ M
 messages and just under 256 Go, base on du(1).)

 Trying to avoid data loss due to crashes...

I can't answer to memory, but as a rule of thumb the notmuch database
seems to be around the same size as the mail it indexes.  I think by any
measure you have quite a lot of mail :-)

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

gnus-alias integration bug

[Michael Hudson-Doyle]

Ian Kelling  writes:

> gnus-alias allows you to set your identity based on the headers in the
> message you are replying. This is an essential feature in a mail client
> for me, I want to automatically reply as the person an email was sent to
> for certain addresses. This does not work in notmuch.

Which version of notmuch are you using?  gnus-alias is working fine for
me with notmuch 0.17 and emacs-version "GNU Emacs 24.4.50.2
(x86_64-pc-linux-gnu, GTK+ Version 3.8.6) of 2014-04-04 on wani04"

Cheers,
mwh

Re: gnus-alias integration bug

[Michael Hudson-Doyle]

Ian Kelling i...@iankelling.org writes:

 gnus-alias allows you to set your identity based on the headers in the
 message you are replying. This is an essential feature in a mail client
 for me, I want to automatically reply as the person an email was sent to
 for certain addresses. This does not work in notmuch.

Which version of notmuch are you using?  gnus-alias is working fine for
me with notmuch 0.17 and emacs-version GNU Emacs 24.4.50.2
(x86_64-pc-linux-gnu, GTK+ Version 3.8.6) of 2014-04-04 on wani04

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

notmuch-emacs bug report -- infinite looping trying to select next message

[Michael Hudson-Doyle]

David Bremner  writes:

> Michael Hudson-Doyle  writes:
>
>> The attached gzipped mbox appears to trip up the emacs interface.  The
>> problem seems to come from the message with id
>> CAGNsrLCWv6=36q+q+5Hc_SzgdZ2ergeKkapT7T3xXvim=2cK+A at mail.gmail.com.
>>
>
> I can't reproduce this bug in current git, so I'm going to assume
> something fixed it in the intervening years.

I find the same.

> In particular our handling of error reporting for corrupted parts
> changed, so maybe that was it.

When I load up the thread that caused the problem I end up with this in
the buffer:

 [ message/external-body ]
 !!! Bodypart insert error: Couldn't find access type !!!
 [ text/plain ]

so I think it's pretty likely your guess is accurate.

> Thanks so much for including a test case with your bug report,

No problem, thanks for checking this ancient report!  (And thanks to
myself for including the message-id in the report...)

Cheers,
mwh

Re: notmuch-emacs bug report -- infinite looping trying to select next message

[Michael Hudson-Doyle]

David Bremner da...@tethera.net writes:

 Michael Hudson-Doyle michael.hud...@canonical.com writes:

 The attached gzipped mbox appears to trip up the emacs interface.  The
 problem seems to come from the message with id
 CAGNsrLCWv6=36q+q+5Hc_SzgdZ2ergeKkapT7T3xXvim=2c...@mail.gmail.com.


 I can't reproduce this bug in current git, so I'm going to assume
 something fixed it in the intervening years.

I find the same.

 In particular our handling of error reporting for corrupted parts
 changed, so maybe that was it.

When I load up the thread that caused the problem I end up with this in
the buffer:

 [ message/external-body ]
 !!! Bodypart insert error: Couldn't find access type !!!
 [ text/plain ]

so I think it's pretty likely your guess is accurate.

 Thanks so much for including a test case with your bug report,

No problem, thanks for checking this ancient report!  (And thanks to
myself for including the message-id in the report...)

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

Any tips on emacs and different signatures per address

[Michael Hudson-Doyle]

Tomi Ollila  writes:

> On Wed, Jun 13 2012, Svend Sorensen  wrote:
>
>> On Wed, 06 Jun 2012 09:16:16 +0300, Tomi Ollila  
>> wrote:
>>> 
>>> could you write a wiki page about gnus-alias, like
>>> emacstips/gnus-alias.mdwn.
>>> 
>>> That would be very useful.
>>> 
>>> Tomi
>>
>> I've added information on gnus-alias to the emacstips page on the
>> notmuch wiki [1].
>>
>> http://notmuchmail.org/emacstips/
>
> Thanks, that was just something I needed to get started to look into it;
> I also added some more content around your stuff...

Thanks guys, this lets me work around my problems with notmuch selecting
the wrong from address!  Beer is owed, if there is ever a notmuch
conference or anything terrifying like that.

Cheers,
mwh

[PATCH 1/2] cli: also use Delivered-To header to figure out the reply from address

[Michael Hudson-Doyle]

Jani Nikula  writes:

> Add another fallback header Delivered-To for guessing the user's from
> address for notmuch reply before using the Received
> headers. Apparently some MTAs use Delivered-To instead of
> X-Original-To (which already exists as a fallback).
>
> Reported-by: Michael Hudson-Doyle 
> Signed-off-by: Jani Nikula 

Firstly, thank you so much for doing this!

Unfortunately it doesn't work for me :( Poking around a bit reveals why:
I have two Delivered-To: headers in the problem mails, and only the
lower/earlier one containst the email address I want to be used as
From:.  And it seems that the only header one can get all values for is
Received...

Cheers,
mwh

Re: [PATCH 1/2] cli: also use Delivered-To header to figure out the reply from address

[Michael Hudson-Doyle]

Jani Nikula j...@nikula.org writes:

 Add another fallback header Delivered-To for guessing the user's from
 address for notmuch reply before using the Received
 headers. Apparently some MTAs use Delivered-To instead of
 X-Original-To (which already exists as a fallback).

 Reported-by: Michael Hudson-Doyle michael.hud...@canonical.com
 Signed-off-by: Jani Nikula j...@nikula.org

Firstly, thank you so much for doing this!

Unfortunately it doesn't work for me :( Poking around a bit reveals why:
I have two Delivered-To: headers in the problem mails, and only the
lower/earlier one containst the email address I want to be used as
From:.  And it seems that the only header one can get all values for is
Received...

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

notmuch-emacs bug report -- infinite looping trying to select next message

[Michael Hudson-Doyle]

Thanks for the reply!

On Tue, 14 Feb 2012 10:41:20 +0100, Rodney Lorrimar  wrote:
> Hi Michael,
> 
> On Tue, 14 Feb 2012 11:01:56 +1300, Michael Hudson-Doyle  canonical.com> wrote:
> > The attached gzipped mbox appears to trip up the emacs interface.  The
> > problem seems to come from the message with id
> > CAGNsrLCWv6=36q+q+5Hc_SzgdZ2ergeKkapT7T3xXvim=2cK+A at mail.gmail.com.
> > 
> > If you load up the thread in emacs, you get a message:
> > 
> > mm-extern-cache-contents: Couldn't find access type
> 
> If you put (require 'gnus-art) into your .emacs and eval it, does the
> problem go away?

No.

> I had a similar problem when running a newer emacs-snapshot with
> notmuch. See this thread: id:"87d3aaqyur.fsf at eve.chaoflow.net"

I'm running emacs-snapshot-gtk from Ubuntu Oneiric, emacs-version says

GNU Emacs 23.3.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.5) of 2011-08-15 on 
allspice, modified by Debian

> > Then attempting to advance past the last display message (or pressing A,
> > or a few other things I expect gets emacs to loop indefinitely.
> > toggle-debug-on-quit gets me this backtrace:
> 
> I believe the actual bug is in gnus but I don't really like the loop on
> error behaviour of notmuch. I would like to try and fix it but haven't
> found the time.

As far as I can tell, gnus isn't involved here.  I may be wrong, of
course!

Cheers,
mwh

notmuch-emacs bug report -- infinite looping trying to select next message

[Michael Hudson-Doyle]

The attached gzipped mbox appears to trip up the emacs interface.  The
problem seems to come from the message with id
CAGNsrLCWv6=36q+q+5Hc_SzgdZ2ergeKkapT7T3xXvim=2cK+A at mail.gmail.com.

If you load up the thread in emacs, you get a message:

mm-extern-cache-contents: Couldn't find access type

Then attempting to advance past the last display message (or pressing A,
or a few other things I expect gets emacs to loop indefinitely.
toggle-debug-on-quit gets me this backtrace:

Debugger entered--Lisp error: (quit)
  notmuch-show-message-extent()
  notmuch-show-message-bottom()
  notmuch-show-move-to-message-bottom()
  notmuch-show-goto-message-next()
  notmuch-show-next-open-message(nil)
  call-interactively(notmuch-show-next-open-message nil nil)

Looking at the suspect message one sees this:

--20cf305b0f1a1caaf604b875ea95
Content-Type: message/external-body; access-type=x-mutt-deleted;
expiration="Wed, 8 Feb 2012 08:45:08 -0800"; length=644023

Content-Type: text/x-log; charset=US-ASCII; name="binary.log"
Content-Disposition: attachment; filename="binary.log"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gyejghyz0


--20cf305b0f1a1caaf604b875ea95
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

which looks a bit odd to me (maybe mailman stripped an attachment), but
I don't know much about MIME :-)

Cheers,
mwh

-- next part --
A non-text attachment was scrubbed...
Name: notmuch-el-hang.mbox.gz
Type: application/octet-stream
Size: 25936 bytes
Desc: not available
URL: 

Re: notmuch-emacs bug report -- infinite looping trying to select next message

[Michael Hudson-Doyle]

Thanks for the reply!

On Tue, 14 Feb 2012 10:41:20 +0100, Rodney Lorrimar d...@rodney.id.au wrote:
 Hi Michael,
 
 On Tue, 14 Feb 2012 11:01:56 +1300, Michael Hudson-Doyle 
 michael.hud...@canonical.com wrote:
  The attached gzipped mbox appears to trip up the emacs interface.  The
  problem seems to come from the message with id
  CAGNsrLCWv6=36q+q+5Hc_SzgdZ2ergeKkapT7T3xXvim=2c...@mail.gmail.com.
  
  If you load up the thread in emacs, you get a message:
  
  mm-extern-cache-contents: Couldn't find access type
 
 If you put (require 'gnus-art) into your .emacs and eval it, does the
 problem go away?

No.

 I had a similar problem when running a newer emacs-snapshot with
 notmuch. See this thread: id:87d3aaqyur@eve.chaoflow.net

I'm running emacs-snapshot-gtk from Ubuntu Oneiric, emacs-version says

GNU Emacs 23.3.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.5) of 2011-08-15 on 
allspice, modified by Debian

  Then attempting to advance past the last display message (or pressing A,
  or a few other things I expect gets emacs to loop indefinitely.
  toggle-debug-on-quit gets me this backtrace:
 
 I believe the actual bug is in gnus but I don't really like the loop on
 error behaviour of notmuch. I would like to try and fix it but haven't
 found the time.

As far as I can tell, gnus isn't involved here.  I may be wrong, of
course!

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

notmuch-emacs bug report -- infinite looping trying to select next message

[Michael Hudson-Doyle]

The attached gzipped mbox appears to trip up the emacs interface.  The
problem seems to come from the message with id
CAGNsrLCWv6=36q+q+5Hc_SzgdZ2ergeKkapT7T3xXvim=2c...@mail.gmail.com.

If you load up the thread in emacs, you get a message:

mm-extern-cache-contents: Couldn't find access type

Then attempting to advance past the last display message (or pressing A,
or a few other things I expect gets emacs to loop indefinitely.
toggle-debug-on-quit gets me this backtrace:

Debugger entered--Lisp error: (quit)
  notmuch-show-message-extent()
  notmuch-show-message-bottom()
  notmuch-show-move-to-message-bottom()
  notmuch-show-goto-message-next()
  notmuch-show-next-open-message(nil)
  call-interactively(notmuch-show-next-open-message nil nil)

Looking at the suspect message one sees this:

--20cf305b0f1a1caaf604b875ea95
Content-Type: message/external-body; access-type=x-mutt-deleted;
expiration=Wed, 8 Feb 2012 08:45:08 -0800; length=644023

Content-Type: text/x-log; charset=US-ASCII; name=binary.log
Content-Disposition: attachment; filename=binary.log
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gyejghyz0


--20cf305b0f1a1caaf604b875ea95
Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

which looks a bit odd to me (maybe mailman stripped an attachment), but
I don't know much about MIME :-)

Cheers,
mwh



notmuch-el-hang.mbox.gz
Description: Binary data
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

More ideas about logging.

[Michael Hudson-Doyle]

On Fri, 16 Dec 2011 08:02:17 -0400, David Bremner  wrote:
> On Fri, 16 Dec 2011 20:16:51 +1300, Michael Hudson-Doyle  canonical.com> wrote:
> > 
> > It's a tangent, but would this sort of thing allow a "undo last tagging
> > operation" command in emacs?
> > 
> 
> It seems like it would be much simpler to track that information in a
> data structure in emacs?

I think that would require tracking more information than is currently
tracked -- when press 'a' on a thread, emacs would have to remember
which emails had the inbox tag before running 'notmuch tag -inbox
thread:xxx' or whatever it runs today.

You are probably right that what you're talking about here is not the
easiest way to do this though.

Cheers,
mwh

Re: More ideas about logging.

[Michael Hudson-Doyle]

On Fri, 16 Dec 2011 08:02:17 -0400, David Bremner brem...@debian.org wrote:
 On Fri, 16 Dec 2011 20:16:51 +1300, Michael Hudson-Doyle 
 michael.hud...@canonical.com wrote:
  
  It's a tangent, but would this sort of thing allow a undo last tagging
  operation command in emacs?
  
 
 It seems like it would be much simpler to track that information in a
 data structure in emacs?

I think that would require tracking more information than is currently
tracked -- when press 'a' on a thread, emacs would have to remember
which emails had the inbox tag before running 'notmuch tag -inbox
thread:xxx' or whatever it runs today.

You are probably right that what you're talking about here is not the
easiest way to do this though.

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

More ideas about logging.

[Michael Hudson-Doyle]

On Thu, 15 Dec 2011 22:09:08 -0400, David Bremner  wrote:
> Various discussions (mostly on IRC) from my jlog proposal, and a from
> Thomas's mtime
> (id:"1323796305-28789-1-git-send-email-schnouki at schnouki.net") proposal
> got me thinking.  So let me know what you think about the following.
>
> The goal here is to log tag adds and deletes (including those implicit
> in message deletion) to facilitate tag synchonization.

It's a tangent, but would this sort of thing allow a "undo last tagging
operation" command in emacs?

Cheers,
mwh

Re: More ideas about logging.

[Michael Hudson-Doyle]

On Thu, 15 Dec 2011 22:09:08 -0400, David Bremner brem...@debian.org wrote:
 Various discussions (mostly on IRC) from my jlog proposal, and a from
 Thomas's mtime
 (id:1323796305-28789-1-git-send-email-schno...@schnouki.net) proposal
 got me thinking.  So let me know what you think about the following.

 The goal here is to log tag adds and deletes (including those implicit
 in message deletion) to facilitate tag synchonization.

It's a tangent, but would this sort of thing allow a undo last tagging
operation command in emacs?

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

notmuch reply From:-guessing heuristics

[Michael Hudson-Doyle]

Hi all,

I have a specific example where "notmuch reply" does not set a useful
from: header.  The set is:

1) I have a google apps-for-your-domain address,
   michael.hudson at linaro.org

2) There is a group/alias, validation at linaro.org that only accepts mail
   from members

3) michael.hudson at linaro.org forwards to michael.hudson at canonical.com,
   from where I get email with offlineimap.

4) michael.hudson at linaro.org and michael.hudson at canonical.com are both
   configured as addresses in ~/.notmuch-config with the linaro.org
   address being primary.

When I reply to a mail to validation at linaro.org, the guessed address is
michael.hudson at canonical.com and unless I change it, the reply bounces,
which is obviously a bit annoying.

Looking at the headers (and the notmuch source),
michael.hudson at canonical.com seems to be being found in the Received
headers.  michael.hudson at linaro.org is not in any Received header, which
is a bit strange, but in any case I think the code would find
michael.hudson at canonical.com first (would it perhaps make more sense to
search backwards through received?  An earlier header is probably closer
to what was intended, in some sense).

michael.hudson at linaro.org does appear in a Delivered-To: header, so
maybe those could be considered (it seems that some MTAs add a
Delivered-To header from the envelope address, so it would have some
legitimacy)?  It would work in this case, but only because the
Delivered-To that the canonical.com MTA adds is an internal address
that's not configured as an address for me in notmuch...

Alternatively, *I* wouldn't mind if notmuch stopped trying at all hard,
and just used the primary address if there was nothing matching in
to:/cc: but I guess that wouldn't work on mailing lists at all...

Hm, I guess I've argued myself around to thinking that considering
Delivered-To as a source of potential from addresses would be an
improvement.  What do you guys think?

Cheers,
mwh

notmuch reply From:-guessing heuristics

[Michael Hudson-Doyle]

Hi all,

I have a specific example where notmuch reply does not set a useful
from: header.  The set is:

1) I have a google apps-for-your-domain address,
   michael.hud...@linaro.org

2) There is a group/alias, validat...@linaro.org that only accepts mail
   from members

3) michael.hud...@linaro.org forwards to michael.hud...@canonical.com,
   from where I get email with offlineimap.

4) michael.hud...@linaro.org and michael.hud...@canonical.com are both
   configured as addresses in ~/.notmuch-config with the linaro.org
   address being primary.

When I reply to a mail to validat...@linaro.org, the guessed address is
michael.hud...@canonical.com and unless I change it, the reply bounces,
which is obviously a bit annoying.

Looking at the headers (and the notmuch source),
michael.hud...@canonical.com seems to be being found in the Received
headers.  michael.hud...@linaro.org is not in any Received header, which
is a bit strange, but in any case I think the code would find
michael.hud...@canonical.com first (would it perhaps make more sense to
search backwards through received?  An earlier header is probably closer
to what was intended, in some sense).

michael.hud...@linaro.org does appear in a Delivered-To: header, so
maybe those could be considered (it seems that some MTAs add a
Delivered-To header from the envelope address, so it would have some
legitimacy)?  It would work in this case, but only because the
Delivered-To that the canonical.com MTA adds is an internal address
that's not configured as an address for me in notmuch...

Alternatively, *I* wouldn't mind if notmuch stopped trying at all hard,
and just used the primary address if there was nothing matching in
to:/cc: but I guess that wouldn't work on mailing lists at all...

Hm, I guess I've argued myself around to thinking that considering
Delivered-To as a source of potential from addresses would be an
improvement.  What do you guys think?

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

[PATCH] Do not import notmuch in setup.py (again).

[Michael Hudson-Doyle]

rOn Wed, 24 Aug 2011 09:20:51 +0200, Sebastian Spaeth  
wrote:
> On Wed, 24 Aug 2011 12:45:34 +1200, Michael Hudson-Doyle  canonical.com> wrote:
> > Revert part of 8826f.  As explained in c39b492c, importing notmuch in 
> > setup.py breaks make -f debian/rules clean in an environment that does not 
> > have notmuch installed already.
> 
> Ahh, sorry, I must have missed that patch (or forgotten about it). I
> solved this now by having the version number in version.py (which
> contains nothing else, so David Bremner can easily overwrite it with
> makefile magic :-)).

Ah cool.

> @David, feel free to automagically modify (or overwrite)
> bindings/python/notmuch/version.py.
> 
> We read in version.py using execfile() and verify that getting the
> version number actually worked.
> 
> Sorry, I did not apply your patch as I had fixed this before even seeing
> your patch.

No worries.  5dc189c seems to be building fine so far...

Cheers,
mwh

[PATCH] Do not import notmuch in setup.py (again).

[Michael Hudson-Doyle]

Revert part of 8826f.  As explained in c39b492c, importing notmuch in setup.py
breaks make -f debian/rules clean in an environment that does not have notmuch
installed already.
---
This is my first time using git format-patch, please be gentle :-)

 bindings/python/setup.py |   20 +++-
 1 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/bindings/python/setup.py b/bindings/python/setup.py
index 19b6558..671b0d3 100644
--- a/bindings/python/setup.py
+++ b/bindings/python/setup.py
@@ -2,19 +2,29 @@

 import os
 import re
-import sys
 from distutils.core import setup
-dirname = os.path.dirname(os.path.abspath(__file__)) # Package's main folder
-sys.path.insert(0, dirname)
 import notmuch

+def get_version():
+file = open('notmuch/__init__.py')
+try:
+for line in file:
+if re.match('__VERSION__\s*=\s*',line) != None:
+version = line.split('=', 1)[1]
+return eval(version, {}, {})
+finally:
+file.close()
+raise IOError('Unexpected end-of-file')
+
+__VERSION__=get_version()
+
 setup(name='notmuch',
-  version=notmuch.__VERSION__,
+  version=__VERSION__,
   description='Python binding of the notmuch mail search and indexing 
library.',
   author='Sebastian Spaeth',
   author_email='Sebastian at SSpaeth.de',
   url='http://notmuchmail.org/',
-  download_url='http://notmuchmail.org/releases/notmuch-'+ 
notmuch.__VERSION__+'.tar.gz',
+  download_url='http://notmuchmail.org/releases/notmuch-'+ 
__VERSION__+'.tar.gz',
   packages=['notmuch'],
   keywords = ["library", "email"],
   long_description="""Overview
-- 
1.7.4.1

Re: [PATCH] Do not import notmuch in setup.py (again).

[Michael Hudson-Doyle]

rOn Wed, 24 Aug 2011 09:20:51 +0200, Sebastian Spaeth sebast...@sspaeth.de 
wrote:
 On Wed, 24 Aug 2011 12:45:34 +1200, Michael Hudson-Doyle 
 michael.hud...@canonical.com wrote:
  Revert part of 8826f.  As explained in c39b492c, importing notmuch in 
  setup.py breaks make -f debian/rules clean in an environment that does not 
  have notmuch installed already.
 
 Ahh, sorry, I must have missed that patch (or forgotten about it). I
 solved this now by having the version number in version.py (which
 contains nothing else, so David Bremner can easily overwrite it with
 makefile magic :-)).

Ah cool.

 @David, feel free to automagically modify (or overwrite)
 bindings/python/notmuch/version.py.
 
 We read in version.py using execfile() and verify that getting the
 version number actually worked.
 
 Sorry, I did not apply your patch as I had fixed this before even seeing
 your patch.

No worries.  5dc189c seems to be building fine so far...

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

Undo tag operation?

[Michael Hudson-Doyle]

On Wed, 20 Jul 2011 14:37:50 -0700, Jameson Graef Rollins  wrote:
> On Wed, 20 Jul 2011 22:02:47 +0200, Olivier Schwander  chadok.info> wrote:
> > I wonder if it may be possible to create a journal of all the operations
> > on tags: a file where all the changes are registered, with a timestamp.
> > 
> > Two benefits:
> >  - going through the history to undo mistakes
> >  - being able to build a diff of two journals in order to synchronize db on 
> > multiple
> >hosts
> 
> I'm having trouble finding the thread right now, but wasn't there just
> recently a discussion about just this (i.e. time-stamping tag
> operations)?  Unless there is a big performance hit, I'm starting to
> think this sounds like a good idea.
> 
> Being also to share tags alone would be super cool.

I think the discussion was on IRC, not the mailing list.  It would be
very cool :)

Cheers,
mwh

Re: Undo tag operation?

[Michael Hudson-Doyle]

On Wed, 20 Jul 2011 14:37:50 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 On Wed, 20 Jul 2011 22:02:47 +0200, Olivier Schwander 
 olivier.schwan...@chadok.info wrote:
  I wonder if it may be possible to create a journal of all the operations
  on tags: a file where all the changes are registered, with a timestamp.
  
  Two benefits:
   - going through the history to undo mistakes
   - being able to build a diff of two journals in order to synchronize db on 
  multiple
 hosts
 
 I'm having trouble finding the thread right now, but wasn't there just
 recently a discussion about just this (i.e. time-stamping tag
 operations)?  Unless there is a big performance hit, I'm starting to
 think this sounds like a good idea.
 
 Being also to share tags alone would be super cool.

I think the discussion was on IRC, not the mailing list.  It would be
very cool :)

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

Preventing the user shooting themself in the foot

[Michael Hudson-Doyle]

On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth  wrote:
Non-text part: multipart/mixed
Non-text part: multipart/signed

not sure why notmuch reply is putting that there :)

> The lack of a "move to next thread" binding helps encourage me to form
> good habits. The goal I have when processing my inbox is to get
> everything *out* of my inbox. I can do that by deciding one of several
> common things:
> 
> * I have nothing to do
> 
>   In this case I should just archive the message immediately
> 
> * I can deal with this message "on the spot" (such as a quick reply)
> 
>   In this case, I should deal with the message, then archive it
> 
> * I can't deal with this now, but need to later
> 
>   This is the key scenario. The wrong thing to do is to leave the
>   message in my inbox, (that just makes things pile up and makes
>   my future inbox processing slow, demotivating, and
>   unreliable). The right thing to do is to tag this message in a
>   way that I'm sure I'll find it again when I will be equipped to
>   deal with it. And then I can archive the message.

I'm come to strongly agree that this is the Right Way to process email
too, so should there be a keybinding for this last operation?  It should
tag the message (or the thread?) with, say, 'task', and then proceeded
as 'a' does.  'task' should be in the default searches you get in
the notmuch hello buffer.

I realize there is endless bikeshedding to be done on tag names and so
on and also on allowing people to choose their own workflow, but I also
think that this shouldn't stop the addition of a sensible default :)

Cheers,
mwh

Re: Preventing the user shooting themself in the foot

[Michael Hudson-Doyle]

On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth cwo...@cworth.org wrote:
Non-text part: multipart/mixed
Non-text part: multipart/signed

not sure why notmuch reply is putting that there :)

 The lack of a move to next thread binding helps encourage me to form
 good habits. The goal I have when processing my inbox is to get
 everything *out* of my inbox. I can do that by deciding one of several
 common things:
 
 * I have nothing to do
 
   In this case I should just archive the message immediately
 
 * I can deal with this message on the spot (such as a quick reply)
 
   In this case, I should deal with the message, then archive it
 
 * I can't deal with this now, but need to later
 
   This is the key scenario. The wrong thing to do is to leave the
   message in my inbox, (that just makes things pile up and makes
   my future inbox processing slow, demotivating, and
   unreliable). The right thing to do is to tag this message in a
   way that I'm sure I'll find it again when I will be equipped to
   deal with it. And then I can archive the message.

I'm come to strongly agree that this is the Right Way to process email
too, so should there be a keybinding for this last operation?  It should
tag the message (or the thread?) with, say, 'task', and then proceeded
as 'a' does.  'task' should be in the default searches you get in
the notmuch hello buffer.

I realize there is endless bikeshedding to be done on tag names and so
on and also on allowing people to choose their own workflow, but I also
think that this shouldn't stop the addition of a sensible default :)

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

one-time-iterators

[Michael Hudson-Doyle]

On Thu, 26 May 2011 10:20:21 -0700, Carl Worth  wrote:
> On Thu, 26 May 2011 09:31:19 +0100, Patrick Totzke  googlemail.com> wrote:
> > Wow. This reads really complicated. All I want to say is:
> > if I change tags in my search-results view, I get Xapian errors :)
> 
> Yes, that's frustrating. I wish that we had a more reliable interface at
> the notmuch library level. But I'm not entirely sure what would be the
> best way to do this.
> 
> > The question: How do you solve this in the emacs code?
> > do you store all tids of a query? 
> 
> The emacs code does not use the notmuch library interface like your
> python bindings do. Instead, it uses the notmuch command-line tool, (and
> buffers up the text output by it). The support for asynchronous
> operations in the emacs interface means that it's likely possible
> someone could run into a similar problem:
> 
>   1. Start a search returning a *lot* of results
> 
>   2. When the first results come in, make some tag changes
> 
>   3. See if the original search aborts
> 
> I may have even had this happen to me before, but if I did I've never
> actually noticed it. I don't know what a good answer might be for this
> problem.

I've had exactly this happen to me.  Yay for post-vacation email
mountains and slow laptop drives...

Cheers,
mwh

Re: one-time-iterators

[Michael Hudson-Doyle]

On Thu, 26 May 2011 10:20:21 -0700, Carl Worth cwo...@cworth.org wrote:
 On Thu, 26 May 2011 09:31:19 +0100, Patrick Totzke 
 patricktot...@googlemail.com wrote:
  Wow. This reads really complicated. All I want to say is:
  if I change tags in my search-results view, I get Xapian errors :)
 
 Yes, that's frustrating. I wish that we had a more reliable interface at
 the notmuch library level. But I'm not entirely sure what would be the
 best way to do this.
 
  The question: How do you solve this in the emacs code?
  do you store all tids of a query? 
 
 The emacs code does not use the notmuch library interface like your
 python bindings do. Instead, it uses the notmuch command-line tool, (and
 buffers up the text output by it). The support for asynchronous
 operations in the emacs interface means that it's likely possible
 someone could run into a similar problem:
 
   1. Start a search returning a *lot* of results
 
   2. When the first results come in, make some tag changes
 
   3. See if the original search aborts
 
 I may have even had this happen to me before, but if I did I've never
 actually noticed it. I don't know what a good answer might be for this
 problem.

I've had exactly this happen to me.  Yay for post-vacation email
mountains and slow laptop drives...

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