[PATCH 0/3] build fixes
On Mon, 14 Jun 2010 17:17:00 +0300, Felipe Contreras wrote: > Hi, > > Is anything wrong with these patches? cworth - our fearless leader - is extremely busy with his day job right now. He tends to respond to all the patches on the mailing list as soon as he finds time; sometimes within minutes, sometimes it takes weeks... you appear to have hit one of the slow spots. /D -- Dirk Hohndel Intel Open Source Technology Center
[PATCH] remove message archiving from show-advance-and-archive
On 2010-06-09, Dirk Hohndel wrote: > Oh - and I really want a way to do surgery on threads. Merge threads to > fix Blackberry users breaking threads. And split threads for > hijackers... Which will open other cans of worms :-) Have fun splitting the below thread between msg 1 and 2. Where will msg 3 end up? :-) (OK, OK, *usually* you should get a reply-to header...) Msg id1 Blah... Msg id2 References: id1 Bloh... Msg id3 References: id1 id2 Bleh... -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100615/373dffb6/attachment.pgp>
[PATCH] remove message archiving from show-advance-and-archive
> For that, I think I want the current '|' binding to pipe the current
> message and then a new binding ("M-|" ?) to pipe every (open) message in
> the thread.
+1
> Which makes me think that other operations should work similarly. '+'
> and '-' should change tags on the current message (as they do currently)
> and then new "M-+" and "M--" could change tags on all (open) messages in
> the thread.
+1
> That would highlight the current 'a' as out of place since it's
> currently archiving every message in the thread. So I'd then fix it to
> be 'a' for the current message and "M-a" for every (open) message in the
> thread.
It would indeed be out of place, but I would like to voice support for
the status-quo. In General I like to press as few keys as possible
(since I use emacs my meta keys are getting worn out quite quickly).
and I usually archive whole threads rather than single messages, so I
would vote for "a" as archive thread. Is it inconsistent? Yes. Does it
let me press fewer keys? Yes...
Anyway, I can always customize it the way I like it best :-)
Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100615/cac121fa/attachment.pgp>
Python bindings and Xapian exceptions
> A Xapian exception occurred finding message: The revision being read > has been discarded - you should call Xapian::Database::reopen() and > retry the operation. > It makes the Python bindings almost useless to me. Not sure, if the python bindings should simply drop and reopen a database connection in that case? But I am not sure if libnotmuch.so still simply exits on such an error case. The proper fix, and a reason why I am not immediately hacking around in the python bindings is that notmuch the library would actually return a proper error value rather than print to stderr and quit. Happy to receive suggestions on how to handle this best from the python side of things. Sebastian -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100615/a63b69e4/attachment.pgp>
Python bindings and Xapian exceptions
On Tue, 15 Jun 2010 11:03:55 +0200, "Sebastian Spaeth" wrote: > > A Xapian exception occurred finding message: The revision being read > > has been discarded - you should call Xapian::Database::reopen() and > > retry the operation. > > It makes the Python bindings almost useless to me. > > Not sure, if the python bindings should simply drop and reopen a > database connection in that case? But I am not sure if libnotmuch.so > still simply exits on such an error case. > > The proper fix, and a reason why I am not immediately hacking around in > the python bindings is that notmuch the library would actually return a > proper error value rather than print to stderr and quit. > > Happy to receive suggestions on how to handle this best from the python > side of things. Unfortunately I'm an ignorant about the best solution. Having the Python layer hide the fact that the database was re-opened seems as though it might be dangerous (in case I mix state from before and after the re-opening), but I can't give a concrete example of something that would fail. Given that exception based programming is common in Python, simple raising the exception and allowing the application to handle it appears to make sense. dme. -- David Edmondson, http://dme.org -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100615/4aaf9188/attachment.pgp>
Re: Python bindings and Xapian exceptions
A Xapian exception occurred finding message: The revision being read has been discarded - you should call Xapian::Database::reopen() and retry the operation. It makes the Python bindings almost useless to me. Not sure, if the python bindings should simply drop and reopen a database connection in that case? But I am not sure if libnotmuch.so still simply exits on such an error case. The proper fix, and a reason why I am not immediately hacking around in the python bindings is that notmuch the library would actually return a proper error value rather than print to stderr and quit. Happy to receive suggestions on how to handle this best from the python side of things. Sebastian pgpUhij3YDFKm.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] remove message archiving from show-advance-and-archive
For that, I think I want the current '|' binding to pipe the current message and then a new binding (M-| ?) to pipe every (open) message in the thread. +1 Which makes me think that other operations should work similarly. '+' and '-' should change tags on the current message (as they do currently) and then new M-+ and M-- could change tags on all (open) messages in the thread. +1 That would highlight the current 'a' as out of place since it's currently archiving every message in the thread. So I'd then fix it to be 'a' for the current message and M-a for every (open) message in the thread. It would indeed be out of place, but I would like to voice support for the status-quo. In General I like to press as few keys as possible (since I use emacs my meta keys are getting worn out quite quickly). and I usually archive whole threads rather than single messages, so I would vote for a as archive thread. Is it inconsistent? Yes. Does it let me press fewer keys? Yes... Anyway, I can always customize it the way I like it best :-) Sebastian pgp4SSJqlKkbs.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] remove message archiving from show-advance-and-archive
On 2010-06-09, Dirk Hohndel wrote: Oh - and I really want a way to do surgery on threads. Merge threads to fix Blackberry users breaking threads. And split threads for hijackers... Which will open other cans of worms :-) Have fun splitting the below thread between msg 1 and 2. Where will msg 3 end up? :-) (OK, OK, *usually* you should get a reply-to header...) Msg id1 Blah... Msg id2 References: id1 Bloh... Msg id3 References: id1 id2 Bleh... pgpHcICvFPRQc.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Python bindings and Xapian exceptions
On Tue, 15 Jun 2010 11:03:55 +0200, Sebastian Spaeth sebast...@sspaeth.de wrote: A Xapian exception occurred finding message: The revision being read has been discarded - you should call Xapian::Database::reopen() and retry the operation. It makes the Python bindings almost useless to me. Not sure, if the python bindings should simply drop and reopen a database connection in that case? But I am not sure if libnotmuch.so still simply exits on such an error case. The proper fix, and a reason why I am not immediately hacking around in the python bindings is that notmuch the library would actually return a proper error value rather than print to stderr and quit. Happy to receive suggestions on how to handle this best from the python side of things. Unfortunately I'm an ignorant about the best solution. Having the Python layer hide the fact that the database was re-opened seems as though it might be dangerous (in case I mix state from before and after the re-opening), but I can't give a concrete example of something that would fail. Given that exception based programming is common in Python, simple raising the exception and allowing the application to handle it appears to make sense. dme. -- David Edmondson, http://dme.org pgp9NLrqXna70.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 0/3] build fixes
On Mon, 14 Jun 2010 17:17:00 +0300, Felipe Contreras felipe.contre...@gmail.com wrote: Hi, Is anything wrong with these patches? cworth - our fearless leader - is extremely busy with his day job right now. He tends to respond to all the patches on the mailing list as soon as he finds time; sometimes within minutes, sometimes it takes weeks... you appear to have hit one of the slow spots. /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
