[PATCH] emacs: Make the queries used in the all-tags section

[Daniel Kahn Gillmor]

On 05/26/2011 06:04 PM, Carl Worth wrote:
> 2. The hello screen is now lying a bit by saying "all tags".
> 
>Perhaps if the user has the notmuch-hello-hide-tags variable set to
>non-nil the text might change somewhat? I'm not sure to what exactly.

maybe "all non-hidden tags" ?

--dkg

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110526/37e267ed/attachment.pgp>

one-time-iterators

[Patrick Totzke]

Excerpts from Austin Clements's message of Thu May 26 22:43:02 +0100 2011:
> http://notmuch.198994.n3.nabble.com/notmuch-s-idea-of-concurrency-failing-an-invocation-tp2373468p2565731.html
ah, good old peterson :P thanks.

> > > Though, Patrick, that solution doesn't address your problem.? On the
> > > other hand, it's not clear to me what concurrent access semantics
> > > you're actually expecting.? I suspect you don't want the remaining
> > > iteration to reflect the changes, since your changes could equally
> > > well have affected earlier iteration results.?
> > That's right. 
> > > But if you want a
> > > consistent view of your query results, something's going to have to
> > > materialize that iterator, and it might as well be you (or Xapian
> > > would need more sophisticated concurrency control than it has).? But
> > > this shouldn't be expensive because all you need to materialize are
> > > the document ids; you shouldn't need to eagerly fetch the per-thread
> > > information.  
> > I thought so, but it seems that Query.search_threads() already
> > caches more than the id of each item. Which is as expected
> > because it is designed to return thread objects, not their ids.
> > As you can see above, this _is_ too expensive for me.
> 
> I'd forgotten that constructing threads on the C side was eager about
> the thread tags, author list and subject (which, without Istvan's
> proposed patch, even requires opening and parsing the message file).
> This is probably what's killing you.
> 
> Out of curiosity, what is your situation that you won't wind up paying
> the cost of this iteration one way or the other and that the latency
> of doing these tag changes matters?

I'm trying to implement a terminal interface for notmuch in python
that resembles sup.
For the search results view, i read an initial portion from a Threads iterator 
to fill my teminal window with threadline-widgets. Obviously, for a
large number of results I don't want to go through all of them.
The problem arises if you toggle a tag on the selected threadline and afterwards
continue to scroll down.

> > > Have you tried simply calling list() on your thread
> > > iterator to see how expensive it is?  My bet is that it's quite cheap,
> > > both memory-wise and CPU-wise.
> > Funny thing:
> >  q=Database().create_query('*')
> >  time tlist = list(q.search_threads())
> > raises a NotmuchError(STATUS.NOT_INITIALIZED) exception. For some reason
> > the list constructor must read mere than once from the iterator.
> > So this is not an option, but even if it worked, it would show
> > the same behaviour as my above test..
> 
> Interesting.  Looks like the Threads class implements __len__ and that
> its implementation exhausts the iterator.  Which isn't a great idea in
> itself, but it turns out that Python's implementation of list() calls
> __len__ if it's available (presumably to pre-size the list) before
> iterating over the object, so it exhausts the iterator before even
> using it.
> 
> That said, if list(q.search_threads()) did work, it wouldn't give you
> better performance than your experiment above.
> 
> > would it be very hard to implement a Query.search_thread_ids() ?
> > This name is a bit off because it had to be done on a lower level.
> 
> Lazily fetching the thread metadata on the C side would probably
> address your problem automatically.  But what are you doing that
> doesn't require any information about the threads you're manipulating?
Agreed. Unfortunately, there seems to be no way to get a list of thread
ids or a reliable iterator thereof by using the current python bindings.
It would be enough for me to have the ids because then I could
search for the few threads I actually need individually on demand.

Here is the branch in which I'm trying out these things. Sorry for the
messy code, its late :P
https://github.com/pazz/notmuch-gui/tree/toggletags

/p
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110526/a8045534/attachment.pgp>

one-time-iterators

[Patrick Totzke]

hehe, did it again (dropping the list from cc). I need to stop
using sup :P thanks Austin.

Excerpts from Carl Worth's message of Thu May 26 18:20:21 +0100 2011:
> 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.
Actually, I expected something like this. For this reason each sup instance 
locks its index.
At the moment I'm going for custom wrapper classes around notmuch.Thread
and notmuch.Messages that cache the result of the calls relevant for me.
But the real issue seems to be the iterator:
It takes an awful lot of time just to copy the thread ids of all threads from 
large a query result.

I tried the following in ipython:
 q=Database().create_query('*')
 time tids = [t.get_thread_id() for t in q.search_threads()]

which results in
CPU times: user 7.64 s, sys: 2.06 s, total: 9.70 s
Wall time: 9.84 s

It would really help if the Query object could return an iterator
of thread-ids that makes this copying unnecessary. Is it possible to
implement this? Or would this require the same amount of copying to happen
at a lower level?
I have not looked into the code for the bindings or the C code so far,
but I guess the Query.search_threads() translates to some 
"SELECT id,morestuff from threads"
where for me a "SELECT is from threads" would totally suffice. Copying 
(in the C code) only the ids so some list that yields an iterator should be 
faster.

> > 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). 
Ahh ok. Thanks for the explanation.

Excerpts from Austin Clements's message of Thu May 26 21:18:53 +0100 2011:
> I proposed a solution to this problem a while ago
> (id:"AANLkTi=KOx8aTJipkiArFVjEHE6zt_JypoASMiiAWBZ6 at mail.gmail.com"),
> though I haven't tried implementing it yet.
Sorry, I wasn't on the list back then.

> Though, Patrick, that solution doesn't address your problem.? On the
> other hand, it's not clear to me what concurrent access semantics
> you're actually expecting.? I suspect you don't want the remaining
> iteration to reflect the changes, since your changes could equally
> well have affected earlier iteration results.?
That's right. 
> But if you want a
> consistent view of your query results, something's going to have to
> materialize that iterator, and it might as well be you (or Xapian
> would need more sophisticated concurrency control than it has).? But
> this shouldn't be expensive because all you need to materialize are
> the document ids; you shouldn't need to eagerly fetch the per-thread
> information.  
I thought so, but it seems that Query.search_threads() already
caches more than the id of each item. Which is as expected
because it is designed to return thread objects, not their ids.
As you can see above, this _is_ too expensive for me.

> Have you tried simply calling list() on your thread
> iterator to see how expensive it is?  My bet is that it's quite cheap,
> both memory-wise and CPU-wise.
Funny thing:
 q=Database().create_query('*')
 time tlist = list(q.search_threads())
raises a NotmuchError(STATUS.NOT_INITIALIZED) exception. For some reason
the list constructor must read mere than once from the iterator.
So this is not an option, but even if it worked, it would show
the same behaviour as my above test..

would it be very hard to implement a Query.search_thread_ids() ?
This name is a bit off because it had to be done on a lower level.
Cheers,
/p
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110526/41ac78f0/attachment.pgp>

one-time-iterators

[Austin Clements]

On Thu, May 26, 2011 at 6:22 PM, Patrick Totzke
 wrote:
> Excerpts from Austin Clements's message of Thu May 26 22:43:02 +0100 2011:
>> > > Though, Patrick, that solution doesn't address your problem.? On the
>> > > other hand, it's not clear to me what concurrent access semantics
>> > > you're actually expecting.? I suspect you don't want the remaining
>> > > iteration to reflect the changes, since your changes could equally
>> > > well have affected earlier iteration results.
>> > That's right.
>> > > But if you want a
>> > > consistent view of your query results, something's going to have to
>> > > materialize that iterator, and it might as well be you (or Xapian
>> > > would need more sophisticated concurrency control than it has).? But
>> > > this shouldn't be expensive because all you need to materialize are
>> > > the document ids; you shouldn't need to eagerly fetch the per-thread
>> > > information.
>> > I thought so, but it seems that Query.search_threads() already
>> > caches more than the id of each item. Which is as expected
>> > because it is designed to return thread objects, not their ids.
>> > As you can see above, this _is_ too expensive for me.
>>
>> I'd forgotten that constructing threads on the C side was eager about
>> the thread tags, author list and subject (which, without Istvan's
>> proposed patch, even requires opening and parsing the message file).
>> This is probably what's killing you.
>>
>> Out of curiosity, what is your situation that you won't wind up paying
>> the cost of this iteration one way or the other and that the latency
>> of doing these tag changes matters?
>
> I'm trying to implement a terminal interface for notmuch in python
> that resembles sup.
> For the search results view, i read an initial portion from a Threads iterator
> to fill my teminal window with threadline-widgets. Obviously, for a
> large number of results I don't want to go through all of them.
> The problem arises if you toggle a tag on the selected threadline and 
> afterwards
> continue to scroll down.

Ah, that makes sense.

>> > > Have you tried simply calling list() on your thread
>> > > iterator to see how expensive it is? ?My bet is that it's quite cheap,
>> > > both memory-wise and CPU-wise.
>> > Funny thing:
>> > ?q=Database().create_query('*')
>> > ?time tlist = list(q.search_threads())
>> > raises a NotmuchError(STATUS.NOT_INITIALIZED) exception. For some reason
>> > the list constructor must read mere than once from the iterator.
>> > So this is not an option, but even if it worked, it would show
>> > the same behaviour as my above test..
>>
>> Interesting. ?Looks like the Threads class implements __len__ and that
>> its implementation exhausts the iterator. ?Which isn't a great idea in
>> itself, but it turns out that Python's implementation of list() calls
>> __len__ if it's available (presumably to pre-size the list) before
>> iterating over the object, so it exhausts the iterator before even
>> using it.
>>
>> That said, if list(q.search_threads()) did work, it wouldn't give you
>> better performance than your experiment above.
>>
>> > would it be very hard to implement a Query.search_thread_ids() ?
>> > This name is a bit off because it had to be done on a lower level.
>>
>> Lazily fetching the thread metadata on the C side would probably
>> address your problem automatically. ?But what are you doing that
>> doesn't require any information about the threads you're manipulating?
> Agreed. Unfortunately, there seems to be no way to get a list of thread
> ids or a reliable iterator thereof by using the current python bindings.
> It would be enough for me to have the ids because then I could
> search for the few threads I actually need individually on demand.

There's no way to do that from the C API either, so don't feel left
out.  ]:--8)  It seems to me that the right solution to your problem
is to make thread information lazy (effectively, everything gathered
in lib/thread.cc:_thread_add_message).  Then you could probably
materialize that iterator cheaply.  In fact, it's probably worth
trying a hack where you put dummy information in the thread object
from _thread_add_message and see how long it takes just to walk the
iterator (unfortunately I don't think profiling will help much here
because much of your time is probably spent waiting for I/O).

I don't think there would be any downside to doing this for eager
consumers like the CLI.

Re: [PATCH] emacs: Make the queries used in the all-tags section

[Daniel Kahn Gillmor]

On 05/26/2011 06:04 PM, Carl Worth wrote:
> 2. The hello screen is now lying a bit by saying "all tags".
> 
>Perhaps if the user has the notmuch-hello-hide-tags variable set to
>non-nil the text might change somewhat? I'm not sure to what exactly.

maybe "all non-hidden tags" ?

--dkg



signature.asc
Description: OpenPGP digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] test: add test-lib.el file with `visible-buffer-string' function

[Dmitry Kurochkin]

The patch adds test-lib.el file for Emacs tests auxiliary stuff.
Currently, it implements two functions: `visible-buffer-string'
and `visible-buffer-substring'.  These are similar to standard
counterparts without "visible-" prefix but exclude invisible
text.  The functions are not used anywhere at the moment but
should be useful for testing hiding/showing in the Emacs
interface.
---
 test/test-lib.el |   35 +++
 test/test-lib.sh |5 +++--
 2 files changed, 38 insertions(+), 2 deletions(-)
 create mode 100644 test/test-lib.el

diff --git a/test/test-lib.el b/test/test-lib.el
new file mode 100644
index 000..9439996
--- /dev/null
+++ b/test/test-lib.el
@@ -0,0 +1,35 @@
+;; test-lib.el --- auxiliary stuff for Notmuch Emacs tests.
+;;
+;; Copyright ? Carl Worth
+;; Copyright ? David Edmondson
+;;
+;; This file is part of Notmuch test suit.
+;;
+;; Notmuch is free software: you can redistribute it and/or modify it
+;; under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+;;
+;; Notmuch is distributed in the hope that it will be useful, but
+;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+;; General Public License for more details.
+;;
+;; You should have received a copy of the GNU General Public License
+;; along with Notmuch.  If not, see .
+;;
+;; Authors: Dmitry Kurochkin 
+
+(defun visible-buffer-string ()
+  "Same as `buffer-string', but excludes invisible text."
+  (visible-buffer-substring (point-min) (point-max)))
+
+(defun visible-buffer-substring (start end)
+  "Same as `buffer-substring', but excludes invisible text."
+  (let (str)
+(while (< start end)
+  (let ((next-pos (next-char-property-change start end)))
+   (when (not (invisible-p start))
+ (setq str (concat str (buffer-substring start next-pos
+   (setq start next-pos)))
+str))
diff --git a/test/test-lib.sh b/test/test-lib.sh
index 7cc43cd..9645567 100755
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -843,9 +843,9 @@ fi
 #
 # --no-site-file   Don't load the site-wide startup stuff
 #
-# --directory  Ensure that the local notmuch.el source is found
+# --directory  Ensure that the local elisp sources are found
 #
-# --load   Force loading of notmuch.el
+# --load   Force loading of notmuch.el and test-lib.el
 #
 # notmuch-test-waitFunction for tests to use to wait for process completion
 #
@@ -855,6 +855,7 @@ fi

 emacs \$BATCH --no-init-file --no-site-file \
--directory ../../emacs --load notmuch.el \
+   --directory .. --load test-lib.el \
--eval "(defun notmuch-test-wait ()
(while (get-buffer-process (current-buffer))
(sleep-for 0.1)))" \
-- 
1.7.5.1

Re: one-time-iterators

[Austin Clements]

On Thu, May 26, 2011 at 6:22 PM, Patrick Totzke
 wrote:
> Excerpts from Austin Clements's message of Thu May 26 22:43:02 +0100 2011:
>> > > Though, Patrick, that solution doesn't address your problem.  On the
>> > > other hand, it's not clear to me what concurrent access semantics
>> > > you're actually expecting.  I suspect you don't want the remaining
>> > > iteration to reflect the changes, since your changes could equally
>> > > well have affected earlier iteration results.
>> > That's right.
>> > > But if you want a
>> > > consistent view of your query results, something's going to have to
>> > > materialize that iterator, and it might as well be you (or Xapian
>> > > would need more sophisticated concurrency control than it has).  But
>> > > this shouldn't be expensive because all you need to materialize are
>> > > the document ids; you shouldn't need to eagerly fetch the per-thread
>> > > information.
>> > I thought so, but it seems that Query.search_threads() already
>> > caches more than the id of each item. Which is as expected
>> > because it is designed to return thread objects, not their ids.
>> > As you can see above, this _is_ too expensive for me.
>>
>> I'd forgotten that constructing threads on the C side was eager about
>> the thread tags, author list and subject (which, without Istvan's
>> proposed patch, even requires opening and parsing the message file).
>> This is probably what's killing you.
>>
>> Out of curiosity, what is your situation that you won't wind up paying
>> the cost of this iteration one way or the other and that the latency
>> of doing these tag changes matters?
>
> I'm trying to implement a terminal interface for notmuch in python
> that resembles sup.
> For the search results view, i read an initial portion from a Threads iterator
> to fill my teminal window with threadline-widgets. Obviously, for a
> large number of results I don't want to go through all of them.
> The problem arises if you toggle a tag on the selected threadline and 
> afterwards
> continue to scroll down.

Ah, that makes sense.

>> > > Have you tried simply calling list() on your thread
>> > > iterator to see how expensive it is?  My bet is that it's quite cheap,
>> > > both memory-wise and CPU-wise.
>> > Funny thing:
>> >  q=Database().create_query('*')
>> >  time tlist = list(q.search_threads())
>> > raises a NotmuchError(STATUS.NOT_INITIALIZED) exception. For some reason
>> > the list constructor must read mere than once from the iterator.
>> > So this is not an option, but even if it worked, it would show
>> > the same behaviour as my above test..
>>
>> Interesting.  Looks like the Threads class implements __len__ and that
>> its implementation exhausts the iterator.  Which isn't a great idea in
>> itself, but it turns out that Python's implementation of list() calls
>> __len__ if it's available (presumably to pre-size the list) before
>> iterating over the object, so it exhausts the iterator before even
>> using it.
>>
>> That said, if list(q.search_threads()) did work, it wouldn't give you
>> better performance than your experiment above.
>>
>> > would it be very hard to implement a Query.search_thread_ids() ?
>> > This name is a bit off because it had to be done on a lower level.
>>
>> Lazily fetching the thread metadata on the C side would probably
>> address your problem automatically.  But what are you doing that
>> doesn't require any information about the threads you're manipulating?
> Agreed. Unfortunately, there seems to be no way to get a list of thread
> ids or a reliable iterator thereof by using the current python bindings.
> It would be enough for me to have the ids because then I could
> search for the few threads I actually need individually on demand.

There's no way to do that from the C API either, so don't feel left
out.  ]:--8)  It seems to me that the right solution to your problem
is to make thread information lazy (effectively, everything gathered
in lib/thread.cc:_thread_add_message).  Then you could probably
materialize that iterator cheaply.  In fact, it's probably worth
trying a hack where you put dummy information in the thread object
from _thread_add_message and see how long it takes just to walk the
iterator (unfortunately I don't think profiling will help much here
because much of your time is probably spent waiting for I/O).

I don't think there would be any downside to doing this for eager
consumers like the CLI.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] emacs: Add a customization allowing to always prompt for the "From" address when composing a new message

[Thomas Jost]

---
Hi Jameson,

Here it is :) I'm sure it will be useful for many other people too, including
myself. To be applied on top of my other patches, then you can set
notmuch-always-prompt-for-sender to t.

Regards,
Thomas

 emacs/notmuch-mua.el |   11 ---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index f2d86bb..7c05a81 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -154,6 +154,11 @@ name and addresses configured in the notmuch configuration 
file."
   :group 'notmuch
   :type '(repeat string))

+(defcustom notmuch-always-prompt-for-sender nil
+  "Always prompt for the From: address when composing a new message."
+  :group 'notmuch
+  :type 'boolean)
+
 (defun notmuch-mua-sender-collection ()
   (if notmuch-identities
   notmuch-identities
@@ -176,7 +181,7 @@ If PROMPT-FOR-SENDER is non-nil, the user will be prompted 
for
 the From: address first."
   (interactive "P")
   (let ((other-headers
-(when prompt-for-sender
+(when (or prompt-for-sender notmuch-always-prompt-for-sender)
   (list (cons 'from (notmuch-mua-prompt-for-sender))
 (notmuch-mua-mail nil nil other-headers)))

@@ -186,7 +191,7 @@ the From: address first."
 If PROMPT-FOR-SENDER is non-nil, the user will be prompted for
 the From: address first."
   (interactive "P")
-  (if prompt-for-sender
+  (if (or prompt-for-sender notmuch-always-prompt-for-sender)
   (let* ((sender (notmuch-mua-prompt-for-sender))
 (address-components (mail-extract-address-components sender))
 (user-full-name (car address-components))
@@ -198,7 +203,7 @@ the From: address first."
   "Invoke the notmuch reply window."
   (interactive "P")
   (let ((sender
-(when prompt-for-sender
+(when (or prompt-for-sender notmuch-always-prompt-for-sender)
   (notmuch-mua-prompt-for-sender
 (notmuch-mua-reply query-string sender)))

-- 
1.7.5.2

[PATCH 2/2] Emacs changes for reply to sender

[Mark Walters]

Reply to sender is currently bound to R
---
 emacs/notmuch-mua.el  |6 --
 emacs/notmuch-show.el |6 ++
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index dc7b386..4b8590f 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -69,13 +69,15 @@ list."
(push header message-hidden-headers)))
notmuch-mua-hidden-headers))

-(defun notmuch-mua-reply (query-string)
+(defun notmuch-mua-reply (query-string &optional option-string)
   (let (headers body)
 ;; This make assumptions about the output of `notmuch reply', but
 ;; really only that the headers come first followed by a blank
 ;; line and then the body.
 (with-temp-buffer
-  (call-process notmuch-command nil t nil "reply" query-string)
+  (if option-string
+ (call-process notmuch-command nil t nil "reply" option-string 
query-string)
+   (call-process notmuch-command nil t nil "reply" query-string))
   (goto-char (point-min))
   (if (re-search-forward "^$" nil t)
  (save-excursion
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 9a38d9c..5dbc103 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -795,6 +795,7 @@ function is used. "
(define-key map "m" 'notmuch-mua-mail)
(define-key map "f" 'notmuch-show-forward-message)
(define-key map "r" 'notmuch-show-reply)
+   (define-key map "R" 'notmuch-show-reply-one)
(define-key map "|" 'notmuch-show-pipe-message)
(define-key map "w" 'notmuch-show-save-attachments)
(define-key map "V" 'notmuch-show-view-raw-message)
@@ -1103,6 +1104,11 @@ any effects from previous calls to
   (interactive)
   (notmuch-mua-reply (notmuch-show-get-message-id)))

+(defun notmuch-show-reply-one ()
+  "Reply to the current message."
+  (interactive)
+  (notmuch-mua-reply (notmuch-show-get-message-id) "--format=one"))
+
 (defun notmuch-show-forward-message ()
   "Forward the current message."
   (interactive)
-- 
1.7.2.5

[PATCH 1/2] Command line changes for reply-to-sender

[Mark Walters]

Adds the format "--format=one" to possible reply formats which only
replies to the sender.

More precisely the function follows these rules:
reply only to sender unless it was the user
reply only to all people on the to line unless they were all the user
reply to all people on the cc line

The most common expected case is we just reply to sender, but if we reply to
our own email then we reply to the whole to line.

Implementation details

Note we continue parsing addresses beyond the ones we reply to because
we want to make sure the from address is correct. (At the very least it
is the same as it would be if we replied to all.)

We overload the message variable in add_recipients_for_address_list so
if it is NULL we parse the address (looking for the users address)
but do not add to the message recipients list

We add the variable reply_to_all to the function chain to keep track
of whether we should reply to everyone.
---
 notmuch-reply.c |   38 +++---
 1 files changed, 27 insertions(+), 11 deletions(-)

diff --git a/notmuch-reply.c b/notmuch-reply.c
index ab15650..3df3b52 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -191,7 +191,8 @@ add_recipients_for_address_list (GMimeMessage *message,
if (ret == NULL)
ret = addr;
} else {
-   g_mime_message_add_recipient (message, type, name, addr);
+if (message) 
+ g_mime_message_add_recipient (message, type, name, addr);
}
}
 }
@@ -271,7 +272,8 @@ reply_to_header_is_redundant (notmuch_message_t *message)
 static const char *
 add_recipients_from_message (GMimeMessage *reply,
 notmuch_config_t *config,
-notmuch_message_t *message)
+notmuch_message_t *message,
+int reply_to_all)
 {
 struct {
const char *header;
@@ -311,9 +313,20 @@ add_recipients_from_message (GMimeMessage *reply,
recipients = notmuch_message_get_header (message,
 reply_to_map[i].fallback);

-   addr = add_recipients_for_string (reply, config,
- reply_to_map[i].recipient_type,
- recipients);
+
+   /* We add the addresses if we are replying to all or we have not yet 
found
+* a non-user address. We have to keep parsing to make sure we do find 
the 
+* correct from address for the user, but we pass a NULL message
+*/
+   if ((reply_to_all) || (g_mime_message_get_all_recipients (reply) == 
NULL))
+   addr = add_recipients_for_string (reply, config,
+ reply_to_map[i].recipient_type,
+ recipients);
+   else
+addr = add_recipients_for_string (NULL, config,
+  reply_to_map[i].recipient_type,
+  recipients);
+
if (from_addr == NULL)
from_addr = addr;
 }
@@ -453,7 +466,7 @@ guess_from_received_header (notmuch_config_t *config, 
notmuch_message_t *message
 }

 static int
-notmuch_reply_format_default(void *ctx, notmuch_config_t *config, 
notmuch_query_t *query)
+notmuch_reply_format_default(void *ctx, notmuch_config_t *config, 
notmuch_query_t *query, int reply_to_all)
 {
 GMimeMessage *reply;
 notmuch_messages_t *messages;
@@ -484,7 +497,7 @@ notmuch_reply_format_default(void *ctx, notmuch_config_t 
*config, notmuch_query_
g_mime_message_set_subject (reply, subject);
}

-   from_addr = add_recipients_from_message (reply, config, message);
+   from_addr = add_recipients_from_message (reply, config, message, 
reply_to_all);

if (from_addr == NULL)
from_addr = guess_from_received_header (config, message);
@@ -531,7 +544,7 @@ notmuch_reply_format_default(void *ctx, notmuch_config_t 
*config, notmuch_query_

 /* This format is currently tuned for a git send-email --notmuch hook */
 static int
-notmuch_reply_format_headers_only(void *ctx, notmuch_config_t *config, 
notmuch_query_t *query)
+notmuch_reply_format_headers_only(void *ctx, notmuch_config_t *config, 
notmuch_query_t *query, int reply_to_all)
 {
 GMimeMessage *reply;
 notmuch_messages_t *messages;
@@ -571,7 +584,7 @@ notmuch_reply_format_headers_only(void *ctx, 
notmuch_config_t *config, notmuch_q
g_mime_object_set_header (GMIME_OBJECT (reply),
  "References", references);

-   (void)add_recipients_from_message (reply, config, message);
+   (void)add_recipients_from_message (reply, config, message, 
reply_to_all);

reply_headers = g_mime_object_to_string (GMIME_OBJECT (reply));
printf ("%s", reply_headers);
@@ -593,7 +606,8 @@ notmuch_reply_command (void *ct

[PATCH 0/2] Implement reply to sender

[Mark Walters]

These patches implement a reply to sender function.
On the command line this is done via a new format
"--format=one" to notmuch reply.
In emacs it is bound to the key R

I have been running a similar patch set for some time but 
only tidied it up today. It compiles and works for me.

This is my first submission to the project so I hope that I
have done everything right.

Signed-off-by: Mark Walters 

Mark Walters (2):
  Command line changes for reply-to-sender
  Emacs changes for reply to sender

 emacs/notmuch-mua.el  |6 --
 emacs/notmuch-show.el |6 ++
 notmuch-reply.c   |   38 +++---
 3 files changed, 37 insertions(+), 13 deletions(-)

-- 
1.7.2.5

[PATCH v2 3/3] Emacs changes for reply to sender

[Mark Walters]

Reply to sender is currently bound to R
---
 emacs/notmuch-mua.el  |   10 ++
 emacs/notmuch-show.el |8 +++-
 emacs/notmuch.el  |2 +-
 3 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 61a723b..c9c5854 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -69,13 +69,15 @@ list."
(push header message-hidden-headers)))
notmuch-mua-hidden-headers))
 
-(defun notmuch-mua-reply (query-string &optional sender)
+(defun notmuch-mua-reply (query-string option-string &optional sender)
   (let (headers body)
 ;; This make assumptions about the output of `notmuch reply', but
 ;; really only that the headers come first followed by a blank
 ;; line and then the body.
 (with-temp-buffer
-  (call-process notmuch-command nil t nil "reply" query-string)
+  (if option-string
+ (call-process notmuch-command nil t nil "reply" option-string 
query-string)
+   (call-process notmuch-command nil t nil "reply" query-string))
   (goto-char (point-min))
   (if (re-search-forward "^$" nil t)
  (save-excursion
@@ -194,13 +196,13 @@ the From: address first."
(notmuch-mua-forward-message))
 (notmuch-mua-forward-message)))
 
-(defun notmuch-mua-new-reply (query-string &optional prompt-for-sender)
+(defun notmuch-mua-new-reply (query-string option-string &optional 
prompt-for-sender)
   "Invoke the notmuch reply window."
   (interactive "P")
   (let ((sender
 (when (or prompt-for-sender notmuch-always-prompt-for-sender)
   (notmuch-mua-prompt-for-sender
-(notmuch-mua-reply query-string sender)))
+(notmuch-mua-reply query-string option-string sender)))
 
 (defun notmuch-mua-send-and-exit (&optional arg)
   (interactive "P")
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 2ba151e..852dadf 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -795,6 +795,7 @@ function is used. "
(define-key map "m" 'notmuch-mua-new-mail)
(define-key map "f" 'notmuch-show-forward-message)
(define-key map "r" 'notmuch-show-reply)
+   (define-key map "R" 'notmuch-show-reply-sender)
(define-key map "|" 'notmuch-show-pipe-message)
(define-key map "w" 'notmuch-show-save-attachments)
(define-key map "V" 'notmuch-show-view-raw-message)
@@ -1101,7 +1102,12 @@ any effects from previous calls to
 (defun notmuch-show-reply (&optional prompt-for-sender)
   "Reply to the current message."
   (interactive "P")
-  (notmuch-mua-new-reply (notmuch-show-get-message-id) prompt-for-sender))
+  (notmuch-mua-new-reply (notmuch-show-get-message-id) nil prompt-for-sender))
+
+(defun notmuch-show-reply-sender (&optional prompt-for-sender)
+  "Reply to the current message."
+  (interactive "P")
+  (notmuch-mua-new-reply (notmuch-show-get-message-id) "--reply-to=sender" 
prompt-for-sender))
 
 (defun notmuch-show-forward-message (&optional prompt-for-sender)
   "Forward the current message."
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index c22add7..e956420 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -440,7 +440,7 @@ Complete list of currently available key bindings:
   "Begin composing a reply to the entire current thread in a new buffer."
   (interactive "P")
   (let ((message-id (notmuch-search-find-thread-id)))
-(notmuch-mua-new-reply message-id prompt-for-sender)))
+(notmuch-mua-new-reply message-id nil prompt-for-sender)))
 
 (defun notmuch-call-notmuch-process (&rest args)
   "Synchronously invoke \"notmuch\" with the given list of arguments.
-- 
1.7.2.5

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

[PATCH v2 2/3] Documentation changes for --reply-to= option to notmuch reply.

[Mark Walters]

---
 notmuch.1 |   13 +
 notmuch.c |   10 ++
 2 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/notmuch.1 b/notmuch.1
index a1c7fa8..c434e77 100644
--- a/notmuch.1
+++ b/notmuch.1
@@ -388,6 +388,19 @@ Includes subject and quoted message body.
 .BR headers\-only
 Only produces In\-Reply\-To, References, To, Cc, and Bcc headers.
 .RE
+.RE
+.RS
+.TP 4
+.BR \-\-reply\-to= ( sender | all )
+.RS
+.TP 4
+.BR sender
+Replies only to the sender (or to all addresses in the To header if
+the sending address is one of the user's email addresses).
+.TP
+.BR all " (default)"
+Replies to all addresses.
+.RE
 
 See the
 .B "SEARCH SYNTAX"
diff --git a/notmuch.c b/notmuch.c
index 262d677..631f8e7 100644
--- a/notmuch.c
+++ b/notmuch.c
@@ -338,6 +338,16 @@ static command_t commands[] = {
   "\t\t\tOnly produces In-Reply-To, References, To\n"
   "\t\t\tCc, and Bcc headers.\n"
   "\n"
+  "\t--reply-to=(sender|all)\n"
+  "\n"
+  "\t\tsender:\n"
+  "\t\t\tReplies  only  to the sender (or to all addresses in the\n"
+  "\t\t\tTo header if the sending address is one of the user's\n"
+  "\t\t\temail addresses).\n"
+  "\n"
+  "\t\tall: (default)\n"
+  "\t\t\tReplies to all recipients.\n"
+  "\n"
   "\tSee \"notmuch help search-terms\" for details of the search\n"
   "\tterms syntax." },
 { "tag", notmuch_tag_command,
-- 
1.7.2.5

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

[PATCH v2 1/3] Adds the option "--reply-to=" to notmuch reply.

[Mark Walters]

Possible values are "sender" which replies just to sender and
"all" (the default).

More precisely reply to sender follows these rules:
reply only to sender unless it was the user
reply only to all people on the to line unless they were all the user
reply to all people on the cc line

Implementation details

Note we continue parsing addresses beyond the ones we reply to because
we want to make sure the from address is correct. (At the very least it
is the same as it would be if we replied to all.)

We overload the message variable in add_recipients_for_address_list so
if it is NULL we parse the address (looking for the users address)
but do not add to the message recipients list

We add the variable reply_to_all to the function chain to keep track
of whether we should reply to everyone.
---
 notmuch-reply.c |   46 +++---
 1 files changed, 35 insertions(+), 11 deletions(-)

diff --git a/notmuch-reply.c b/notmuch-reply.c
index ab15650..98ae94a 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -191,7 +191,8 @@ add_recipients_for_address_list (GMimeMessage *message,
if (ret == NULL)
ret = addr;
} else {
-   g_mime_message_add_recipient (message, type, name, addr);
+if (message)
+ g_mime_message_add_recipient (message, type, name, addr);
}
}
 }
@@ -271,7 +272,8 @@ reply_to_header_is_redundant (notmuch_message_t *message)
 static const char *
 add_recipients_from_message (GMimeMessage *reply,
 notmuch_config_t *config,
-notmuch_message_t *message)
+notmuch_message_t *message,
+int reply_to_all)
 {
 struct {
const char *header;
@@ -311,9 +313,20 @@ add_recipients_from_message (GMimeMessage *reply,
recipients = notmuch_message_get_header (message,
 reply_to_map[i].fallback);
 
-   addr = add_recipients_for_string (reply, config,
- reply_to_map[i].recipient_type,
- recipients);
+
+   /* We add the addresses if we are replying to all or we have not yet 
found
+* a non-user address. We have to keep parsing to make sure we do find 
the
+* correct from address for the user, but we pass a NULL message
+*/
+   if ((reply_to_all) || (g_mime_message_get_all_recipients (reply) == 
NULL))
+   addr = add_recipients_for_string (reply, config,
+ reply_to_map[i].recipient_type,
+ recipients);
+   else
+addr = add_recipients_for_string (NULL, config,
+  reply_to_map[i].recipient_type,
+  recipients);
+
if (from_addr == NULL)
from_addr = addr;
 }
@@ -453,7 +466,7 @@ guess_from_received_header (notmuch_config_t *config, 
notmuch_message_t *message
 }
 
 static int
-notmuch_reply_format_default(void *ctx, notmuch_config_t *config, 
notmuch_query_t *query)
+notmuch_reply_format_default(void *ctx, notmuch_config_t *config, 
notmuch_query_t *query, int reply_to_all)
 {
 GMimeMessage *reply;
 notmuch_messages_t *messages;
@@ -484,7 +497,7 @@ notmuch_reply_format_default(void *ctx, notmuch_config_t 
*config, notmuch_query_
g_mime_message_set_subject (reply, subject);
}
 
-   from_addr = add_recipients_from_message (reply, config, message);
+   from_addr = add_recipients_from_message (reply, config, message, 
reply_to_all);
 
if (from_addr == NULL)
from_addr = guess_from_received_header (config, message);
@@ -531,7 +544,7 @@ notmuch_reply_format_default(void *ctx, notmuch_config_t 
*config, notmuch_query_
 
 /* This format is currently tuned for a git send-email --notmuch hook */
 static int
-notmuch_reply_format_headers_only(void *ctx, notmuch_config_t *config, 
notmuch_query_t *query)
+notmuch_reply_format_headers_only(void *ctx, notmuch_config_t *config, 
notmuch_query_t *query, int reply_to_all)
 {
 GMimeMessage *reply;
 notmuch_messages_t *messages;
@@ -571,7 +584,7 @@ notmuch_reply_format_headers_only(void *ctx, 
notmuch_config_t *config, notmuch_q
g_mime_object_set_header (GMIME_OBJECT (reply),
  "References", references);
 
-   (void)add_recipients_from_message (reply, config, message);
+   (void)add_recipients_from_message (reply, config, message, 
reply_to_all);
 
reply_headers = g_mime_object_to_string (GMIME_OBJECT (reply));
printf ("%s", reply_headers);
@@ -593,7 +606,8 @@ notmuch_reply_command (void *ctx, int argc, char *argv[])
 notmuch_query_t *query;
 char *opt, *query_string;
 int i, ret = 0;
-int (*r

[PATCH v2 0/3] Implement reply to sender

[Mark Walters]

Many thanks for the rapid response: I have modified the
patches as suggested and this version includes the
necessary documentation changes. I have also modified the
emacs portion to apply to current master.

Best wishes

Mark


These patches implement a reply to sender function.

On the command line this is done via a new option
to notmuch-reply: --reply-to=(sender|all) with all being
the default (as suggested).

In emacs it is bound to the key R. (Note it does not touch the
reply to thread command from notmuch-search: it is unclear to me
what reply to sender would mean there.)

Mark Walters (3):
  Adds the option "--reply-to" to notmuch reply.
  Documentation changes for --reply-to= option to notmuch reply.
  Emacs changes for reply to sender

 emacs/notmuch-mua.el  |   10 ++
 emacs/notmuch-show.el |8 +++-
 emacs/notmuch.el  |2 +-
 notmuch-reply.c   |   46 +++---
 notmuch.1 |   13 +
 notmuch.c |   10 ++
 6 files changed, 72 insertions(+), 17 deletions(-)

-- 
1.7.2.5

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

one-time-iterators

[Austin Clements]

On May 26, 2011 1:20 PM, "Carl Worth"  wrote:
> > 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 proposed a solution to this problem a while ago
(id:"AANLkTi=KOx8aTJipkiArFVjEHE6zt_JypoASMiiAWBZ6 at mail.gmail.com"),
though I haven't tried implementing it yet.

Though, Patrick, that solution doesn't address your problem.? On the
other hand, it's not clear to me what concurrent access semantics
you're actually expecting.? I suspect you don't want the remaining
iteration to reflect the changes, since your changes could equally
well have affected earlier iteration results.? But if you want a
consistent view of your query results, something's going to have to
materialize that iterator, and it might as well be you (or Xapian
would need more sophisticated concurrency control than it has).? But
this shouldn't be expensive because all you need to materialize are
the document ids; you shouldn't need to eagerly fetch the per-thread
information.  Have you tried simply calling list() on your thread
iterator to see how expensive it is?  My bet is that it's quite cheap,
both memory-wise and CPU-wise.

Re: [PATCH] fixed return value check of sysoncf in get_name_from_passwd_file / get_username_from_passwd_file

[Carl Worth]

On Wed, 25 May 2011 14:27:55 +0200, Matthias Guedemann 
 wrote:
> 
> When trying to port notmuch to DragonFlyBSD I found it core dumped
> immediately. The reason was that the "sysconf(_SC_GETPW_R_SIZE_MAX)"
> call returned -1 which is used for talloc memory allocation. The check
> was there but was done _after_ the allocation, the attached patch fixes
> this.

Thanks for the (obvious in hindsight) fix, Matthias.

I've pushed this out now.

-Carl

-- 
carl.d.wo...@intel.com


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

[PATCH] fixed return value check of sysoncf in get_name_from_passwd_file / get_username_from_passwd_file

[Carl Worth]

On Wed, 25 May 2011 14:27:55 +0200, Matthias Guedemann  wrote:
> 
> When trying to port notmuch to DragonFlyBSD I found it core dumped
> immediately. The reason was that the "sysconf(_SC_GETPW_R_SIZE_MAX)"
> call returned -1 which is used for talloc memory allocation. The check
> was there but was done _after_ the allocation, the attached patch fixes
> this.

Thanks for the (obvious in hindsight) fix, Matthias.

I've pushed this out now.

-Carl

-- 
carl.d.worth at intel.com
-- 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/20110526/bcd02f68/attachment.pgp>

Re: [PATCH] emacs: Add a customization allowing to always prompt for the "From" address when composing a new message

[Jameson Graef Rollins]

Another thing I'm realizing is that I don't think I want the from select
to be happening when I'm replying to messages.  The reply is already
smartly picking From: address based on the To: address of the message
being replied to.  What if we just make from selector work for just
composing new messages and forwarding?

jamie.


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

[PATCH] emacs: Add a customization allowing to always prompt for the "From" address when composing a new message

[Jameson Graef Rollins]

Another thing I'm realizing is that I don't think I want the from select
to be happening when I'm replying to messages.  The reply is already
smartly picking From: address based on the To: address of the message
being replied to.  What if we just make from selector work for just
composing new messages and forwarding?

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110526/d9468e2d/attachment.pgp>

Re: one-time-iterators

[Patrick Totzke]

Excerpts from Austin Clements's message of Thu May 26 22:43:02 +0100 2011:
> http://notmuch.198994.n3.nabble.com/notmuch-s-idea-of-concurrency-failing-an-invocation-tp2373468p2565731.html
ah, good old peterson :P thanks.

> > > Though, Patrick, that solution doesn't address your problem.  On the
> > > other hand, it's not clear to me what concurrent access semantics
> > > you're actually expecting.  I suspect you don't want the remaining
> > > iteration to reflect the changes, since your changes could equally
> > > well have affected earlier iteration results. 
> > That's right. 
> > > But if you want a
> > > consistent view of your query results, something's going to have to
> > > materialize that iterator, and it might as well be you (or Xapian
> > > would need more sophisticated concurrency control than it has).  But
> > > this shouldn't be expensive because all you need to materialize are
> > > the document ids; you shouldn't need to eagerly fetch the per-thread
> > > information.  
> > I thought so, but it seems that Query.search_threads() already
> > caches more than the id of each item. Which is as expected
> > because it is designed to return thread objects, not their ids.
> > As you can see above, this _is_ too expensive for me.
> 
> I'd forgotten that constructing threads on the C side was eager about
> the thread tags, author list and subject (which, without Istvan's
> proposed patch, even requires opening and parsing the message file).
> This is probably what's killing you.
> 
> Out of curiosity, what is your situation that you won't wind up paying
> the cost of this iteration one way or the other and that the latency
> of doing these tag changes matters?

I'm trying to implement a terminal interface for notmuch in python
that resembles sup.
For the search results view, i read an initial portion from a Threads iterator 
to fill my teminal window with threadline-widgets. Obviously, for a
large number of results I don't want to go through all of them.
The problem arises if you toggle a tag on the selected threadline and afterwards
continue to scroll down.

> > > Have you tried simply calling list() on your thread
> > > iterator to see how expensive it is?  My bet is that it's quite cheap,
> > > both memory-wise and CPU-wise.
> > Funny thing:
> >  q=Database().create_query('*')
> >  time tlist = list(q.search_threads())
> > raises a NotmuchError(STATUS.NOT_INITIALIZED) exception. For some reason
> > the list constructor must read mere than once from the iterator.
> > So this is not an option, but even if it worked, it would show
> > the same behaviour as my above test..
> 
> Interesting.  Looks like the Threads class implements __len__ and that
> its implementation exhausts the iterator.  Which isn't a great idea in
> itself, but it turns out that Python's implementation of list() calls
> __len__ if it's available (presumably to pre-size the list) before
> iterating over the object, so it exhausts the iterator before even
> using it.
> 
> That said, if list(q.search_threads()) did work, it wouldn't give you
> better performance than your experiment above.
> 
> > would it be very hard to implement a Query.search_thread_ids() ?
> > This name is a bit off because it had to be done on a lower level.
> 
> Lazily fetching the thread metadata on the C side would probably
> address your problem automatically.  But what are you doing that
> doesn't require any information about the threads you're manipulating?
Agreed. Unfortunately, there seems to be no way to get a list of thread
ids or a reliable iterator thereof by using the current python bindings.
It would be enough for me to have the ids because then I could
search for the few threads I actually need individually on demand.

Here is the branch in which I'm trying out these things. Sorry for the
messy code, its late :P
https://github.com/pazz/notmuch-gui/tree/toggletags

/p


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

Re: [PATCH] Change in increment_mtime for BSD compatibility of test suite

[Carl Worth]

On Wed, 25 May 2011 15:07:52 +0200, Felix Geller  wrote:
Non-text part: multipart/mixed
Non-text part: multipart/signed
> Use `-t' option rather than `-d' which is not supported by BSD's
> touch. I'm not sure whether this is the cleanest way to do this, please
> let me know if there is a better way.

I don't know of a better way, but...

> +last_mod_date=`date -j -f %Y%m%d%H%M%S \`stat -f %Sm -t %Y%m%d%H%M%S 
> ${dir}\` +%s`
>  increment_mtime_amount=$((increment_mtime_amount + 1))
> -touch -d "+${increment_mtime_amount} seconds" "$dir"
> +new_date=`date -j -r ${last_mod_date} -v+${increment_mtime_amount}S 
> +%Y%m%d%H%M.%S`
> +touch -t ${new_date} ${dir}

$ date -j
date: invalid option -- 'j'
Try `date --help' for more information.

:-P

> There are additional changes
> (e.g., sed does not support `-r' but instead `-E') but they seem to be
> incompatible between GNU and BSD. What's the recommended way to handle
> this?

That sounds like something we could test inside our configure
script. In addition to the current Makefile.config file it's creating,
it could also create a little test-config.sh file for things like this.

What do you think?

-Carl

-- 
carl.d.wo...@intel.com


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

[PATCH] Change in increment_mtime for BSD compatibility of test suite

[Carl Worth]

On Wed, 25 May 2011 15:07:52 +0200, Felix Geller  wrote:
Non-text part: multipart/mixed
Non-text part: multipart/signed
> Use `-t' option rather than `-d' which is not supported by BSD's
> touch. I'm not sure whether this is the cleanest way to do this, please
> let me know if there is a better way.

I don't know of a better way, but...

> +last_mod_date=`date -j -f %Y%m%d%H%M%S \`stat -f %Sm -t %Y%m%d%H%M%S 
> ${dir}\` +%s`
>  increment_mtime_amount=$((increment_mtime_amount + 1))
> -touch -d "+${increment_mtime_amount} seconds" "$dir"
> +new_date=`date -j -r ${last_mod_date} -v+${increment_mtime_amount}S 
> +%Y%m%d%H%M.%S`
> +touch -t ${new_date} ${dir}

$ date -j
date: invalid option -- 'j'
Try `date --help' for more information.

:-P

> There are additional changes
> (e.g., sed does not support `-r' but instead `-E') but they seem to be
> incompatible between GNU and BSD. What's the recommended way to handle
> this?

That sounds like something we could test inside our configure
script. In addition to the current Makefile.config file it's creating,
it could also create a little test-config.sh file for things like this.

What do you think?

-Carl

-- 
carl.d.worth at intel.com
-- 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/20110526/8dd65f3a/attachment.pgp>

Re: [PATCH] emacs: Make the queries used in the all-tags section

[Carl Worth]

On Wed, 25 May 2011 23:21:54 +0200, Daniel Schoepe 
 wrote:
> I incorporated most of you recommendations in the attached patch.

Looks good, thanks!

I've pushed this out now.

I only have two suggestions:

1. Could you please add some basic testing for this?

   The existing notmuch-hello tests should make a good starting point.

2. The hello screen is now lying a bit by saying "all tags".

   Perhaps if the user has the notmuch-hello-hide-tags variable set to
   non-nil the text might change somewhat? I'm not sure to what exactly.

-Carl

-- 
carl.d.wo...@intel.com


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

[PATCH] emacs: Make the queries used in the all-tags section

[Carl Worth]

On Wed, 25 May 2011 23:21:54 +0200, Daniel Schoepe  wrote:
> I incorporated most of you recommendations in the attached patch.

Looks good, thanks!

I've pushed this out now.

I only have two suggestions:

1. Could you please add some basic testing for this?

   The existing notmuch-hello tests should make a good starting point.

2. The hello screen is now lying a bit by saying "all tags".

   Perhaps if the user has the notmuch-hello-hide-tags variable set to
   non-nil the text might change somewhat? I'm not sure to what exactly.

-Carl

-- 
carl.d.worth at intel.com
-- 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/20110526/a9e24561/attachment-0001.pgp>

Re: [PATCH 2/2] Workaround for Emacs bug #8721.

[Dmitry Kurochkin]

On Fri, 27 May 2011 01:38:35 +0400, Dmitry Kurochkin 
 wrote:
> The patch adds `notmuch-isearch-range-invisible' function which
> is the same as `isearch-range-invisible' but with fixed Emacs bug
> `notmuch-isearch-range-invisible' instead of the original
> `isearch-range-invisible' when in `notmuch-show-mode'.

I've screwed up the commit message because of a line starting with '#'.

Attach is an amended patch.

Regards,
  Dmitry
>From ead308fb53725d593562d7d4e3cd4aa82412aa70 Mon Sep 17 00:00:00 2001
From: Dmitry Kurochkin 
Date: Fri, 27 May 2011 01:35:09 +0400
Subject: [PATCH] Workaround for Emacs bug #8721.

The patch adds `notmuch-isearch-range-invisible' function which
is the same as `isearch-range-invisible' but with fixed Emacs bug
 #8721.  Advice added for `isearch-range-invisible' which calls
`notmuch-isearch-range-invisible' instead of the original
`isearch-range-invisible' when in `notmuch-show-mode'.
---
 emacs/notmuch-wash.el |   67 +
 1 files changed, 67 insertions(+), 0 deletions(-)

diff --git a/emacs/notmuch-wash.el b/emacs/notmuch-wash.el
index 992fa8f..f37fd95 100644
--- a/emacs/notmuch-wash.el
+++ b/emacs/notmuch-wash.el
@@ -298,4 +298,71 @@ for error."
 
 ;;
 
+;; Temporary workaround for Emacs bug #8721
+;; http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8721
+
+(defun notmuch-isearch-range-invisible (beg end)
+  "Same as `isearch-range-invisible' but with fixed Emacs bug #8721."
+  (when (/= beg end)
+;; Check that invisibility runs up to END.
+(save-excursion
+  (goto-char beg)
+  (let (;; can-be-opened keeps track if we can open some overlays.
+	(can-be-opened (eq search-invisible 'open))
+	;; the list of overlays that could be opened
+	(crt-overlays nil))
+	(when (and can-be-opened isearch-hide-immediately)
+	  (isearch-close-unnecessary-overlays beg end))
+	;; If the following character is currently invisible,
+	;; skip all characters with that same `invisible' property value.
+	;; Do that over and over.
+	(while (and (< (point) end) (invisible-p (point)))
+	  (if (get-text-property (point) 'invisible)
+	  (progn
+		(goto-char (next-single-property-change (point) 'invisible
+			nil end))
+		;; if text is hidden by an `invisible' text property
+		;; we cannot open it at all.
+		(setq can-be-opened nil))
+	(when can-be-opened
+	  (let ((overlays (overlays-at (point)))
+		ov-list
+		o
+		invis-prop)
+		(while overlays
+		  (setq o (car overlays)
+			invis-prop (overlay-get o 'invisible))
+		  (if (invisible-p invis-prop)
+		  (if (overlay-get o 'isearch-open-invisible)
+			  (setq ov-list (cons o ov-list))
+			;; We found one overlay that cannot be
+			;; opened, that means the whole chunk
+			;; cannot be opened.
+			(setq can-be-opened nil)))
+		  (setq overlays (cdr overlays)))
+		(if can-be-opened
+		;; It makes sense to append to the open
+		;; overlays list only if we know that this is
+		;; t.
+		(setq crt-overlays (append ov-list crt-overlays)
+	(goto-char (next-overlay-change (point)
+	;; See if invisibility reaches up thru END.
+	(if (>= (point) end)
+	(if (and can-be-opened (consp crt-overlays))
+		(progn
+		  (setq isearch-opened-overlays
+			(append isearch-opened-overlays crt-overlays))
+		  (mapc 'isearch-open-overlay-temporary crt-overlays)
+		  nil)
+	  (setq isearch-hidden t)))
+
+(defadvice isearch-range-invisible (around notmuch-isearch-range-invisible-advice activate)
+  "Call `notmuch-isearch-range-invisible' instead of the original
+`isearch-range-invisible' when in `notmuch-show-mode' mode."
+  (if (eq major-mode 'notmuch-show-mode)
+  (setq ad-return-value (notmuch-isearch-range-invisible beg end))
+ad-do-it))
+
+;;
+
 (provide 'notmuch-wash)
-- 
1.7.5.1

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

Re: one-time-iterators

[Patrick Totzke]

hehe, did it again (dropping the list from cc). I need to stop
using sup :P thanks Austin.

Excerpts from Carl Worth's message of Thu May 26 18:20:21 +0100 2011:
> On Thu, 26 May 2011 09:31:19 +0100, Patrick Totzke 
>  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.
Actually, I expected something like this. For this reason each sup instance 
locks its index.
At the moment I'm going for custom wrapper classes around notmuch.Thread
and notmuch.Messages that cache the result of the calls relevant for me.
But the real issue seems to be the iterator:
It takes an awful lot of time just to copy the thread ids of all threads from 
large a query result.

I tried the following in ipython:
 q=Database().create_query('*')
 time tids = [t.get_thread_id() for t in q.search_threads()]

which results in
CPU times: user 7.64 s, sys: 2.06 s, total: 9.70 s
Wall time: 9.84 s

It would really help if the Query object could return an iterator
of thread-ids that makes this copying unnecessary. Is it possible to
implement this? Or would this require the same amount of copying to happen
at a lower level?
I have not looked into the code for the bindings or the C code so far,
but I guess the Query.search_threads() translates to some 
"SELECT id,morestuff from threads"
where for me a "SELECT is from threads" would totally suffice. Copying 
(in the C code) only the ids so some list that yields an iterator should be 
faster.

> > 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). 
Ahh ok. Thanks for the explanation.

Excerpts from Austin Clements's message of Thu May 26 21:18:53 +0100 2011:
> I proposed a solution to this problem a while ago
> (id:"AANLkTi=kox8atjipkiarfvjehe6zt_jypoasmiiaw...@mail.gmail.com"),
> though I haven't tried implementing it yet.
Sorry, I wasn't on the list back then.

> Though, Patrick, that solution doesn't address your problem.  On the
> other hand, it's not clear to me what concurrent access semantics
> you're actually expecting.  I suspect you don't want the remaining
> iteration to reflect the changes, since your changes could equally
> well have affected earlier iteration results. 
That's right. 
> But if you want a
> consistent view of your query results, something's going to have to
> materialize that iterator, and it might as well be you (or Xapian
> would need more sophisticated concurrency control than it has).  But
> this shouldn't be expensive because all you need to materialize are
> the document ids; you shouldn't need to eagerly fetch the per-thread
> information.  
I thought so, but it seems that Query.search_threads() already
caches more than the id of each item. Which is as expected
because it is designed to return thread objects, not their ids.
As you can see above, this _is_ too expensive for me.

> Have you tried simply calling list() on your thread
> iterator to see how expensive it is?  My bet is that it's quite cheap,
> both memory-wise and CPU-wise.
Funny thing:
 q=Database().create_query('*')
 time tlist = list(q.search_threads())
raises a NotmuchError(STATUS.NOT_INITIALIZED) exception. For some reason
the list constructor must read mere than once from the iterator.
So this is not an option, but even if it worked, it would show
the same behaviour as my above test..

would it be very hard to implement a Query.search_thread_ids() ?
This name is a bit off because it had to be done on a lower level.
Cheers,
/p


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

Re: [PATCH 3/5] Fix hiding a message while some citations are shown in notmuch-show view.

[Dmitry Kurochkin]

On Thu, 26 May 2011 14:31:30 -0700, Carl Worth  wrote:
> On Thu, 26 May 2011 14:26:34 +0400, Dmitry Kurochkin 
>  wrote:
> > It is called indirectly.  What is the best way to fix it?  I imagine
> > that we can replace `isearch-range-invisible' function with another one,
> > which would call the fixed function if some special variable is set, or
> > if we are searching in a notmuch-show view.  Otherwise it would call the
> > original function.
> 
> I'm not sure what the best approach would be. I'd like to be a good
> "emacs citizen" but I don't know what the best way to do that is here.
> 

Agreed on being a good "emacs citizen".

> If we can predict what the first emacs release will be that contains the
> fix, then we could restrict our kludge here to older, unfixed
> emacs. That would help avoid some problems with "bad citizenship here".
> 
> I'm willing to take whatever you this is best here.
> 

I have just send two more patches to this thread.  One with new tests.
Another with a workaround for the bug.  The workaround should not break
anything since it affects only notmuch-show mode.

Regards,
  Dmitry

> -Carl
> 
> -- 
> carl.d.wo...@intel.com
Non-text part: application/pgp-signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH 2/2] Workaround for Emacs bug #8721.

[Dmitry Kurochkin]

The patch adds `notmuch-isearch-range-invisible' function which
is the same as `isearch-range-invisible' but with fixed Emacs bug
`notmuch-isearch-range-invisible' instead of the original
`isearch-range-invisible' when in `notmuch-show-mode'.
---
 emacs/notmuch-wash.el |   67 +
 1 files changed, 67 insertions(+), 0 deletions(-)

diff --git a/emacs/notmuch-wash.el b/emacs/notmuch-wash.el
index 992fa8f..f37fd95 100644
--- a/emacs/notmuch-wash.el
+++ b/emacs/notmuch-wash.el
@@ -298,4 +298,71 @@ for error."
 
 ;;
 
+;; Temporary workaround for Emacs bug #8721
+;; http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8721
+
+(defun notmuch-isearch-range-invisible (beg end)
+  "Same as `isearch-range-invisible' but with fixed Emacs bug #8721."
+  (when (/= beg end)
+;; Check that invisibility runs up to END.
+(save-excursion
+  (goto-char beg)
+  (let (;; can-be-opened keeps track if we can open some overlays.
+   (can-be-opened (eq search-invisible 'open))
+   ;; the list of overlays that could be opened
+   (crt-overlays nil))
+   (when (and can-be-opened isearch-hide-immediately)
+ (isearch-close-unnecessary-overlays beg end))
+   ;; If the following character is currently invisible,
+   ;; skip all characters with that same `invisible' property value.
+   ;; Do that over and over.
+   (while (and (< (point) end) (invisible-p (point)))
+ (if (get-text-property (point) 'invisible)
+ (progn
+   (goto-char (next-single-property-change (point) 'invisible
+   nil end))
+   ;; if text is hidden by an `invisible' text property
+   ;; we cannot open it at all.
+   (setq can-be-opened nil))
+   (when can-be-opened
+ (let ((overlays (overlays-at (point)))
+   ov-list
+   o
+   invis-prop)
+   (while overlays
+ (setq o (car overlays)
+   invis-prop (overlay-get o 'invisible))
+ (if (invisible-p invis-prop)
+ (if (overlay-get o 'isearch-open-invisible)
+ (setq ov-list (cons o ov-list))
+   ;; We found one overlay that cannot be
+   ;; opened, that means the whole chunk
+   ;; cannot be opened.
+   (setq can-be-opened nil)))
+ (setq overlays (cdr overlays)))
+   (if can-be-opened
+   ;; It makes sense to append to the open
+   ;; overlays list only if we know that this is
+   ;; t.
+   (setq crt-overlays (append ov-list crt-overlays)
+   (goto-char (next-overlay-change (point)
+   ;; See if invisibility reaches up thru END.
+   (if (>= (point) end)
+   (if (and can-be-opened (consp crt-overlays))
+   (progn
+ (setq isearch-opened-overlays
+   (append isearch-opened-overlays crt-overlays))
+ (mapc 'isearch-open-overlay-temporary crt-overlays)
+ nil)
+ (setq isearch-hidden t)))
+
+(defadvice isearch-range-invisible (around 
notmuch-isearch-range-invisible-advice activate)
+  "Call `notmuch-isearch-range-invisible' instead of the original
+`isearch-range-invisible' when in `notmuch-show-mode' mode."
+  (if (eq major-mode 'notmuch-show-mode)
+  (setq ad-return-value (notmuch-isearch-range-invisible beg end))
+ad-do-it))
+
+;;
+
 (provide 'notmuch-wash)
-- 
1.7.5.1

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

[PATCH 1/2] test: add tests for hiding messages in notmuch-show view

[Dmitry Kurochkin]

---
 test/emacs |   16 
 .../notmuch-show-thread-with-hidden-messages   |3 +++
 2 files changed, 19 insertions(+), 0 deletions(-)
 create mode 100644 
test/emacs.expected-output/notmuch-show-thread-with-hidden-messages

diff --git a/test/emacs b/test/emacs
index ccf02af..7421650 100755
--- a/test/emacs
+++ b/test/emacs
@@ -152,4 +152,20 @@ output=$(test_emacs "(notmuch-show 
\"$maildir_storage_thread\")
 expected=$(cat $EXPECTED/notmuch-show-thread-maildir-storage)
 test_expect_equal "$output" "$expected"
 
+test_begin_subtest "Hiding message in notmuch-show view"
+output=$(test_emacs '(notmuch-show 
"id:f35dbb950911171438k5df6eb56k77b6c0944e2e7...@mail.gmail.com")
+(notmuch-show-toggle-message)
+(princ (visible-buffer-string))')
+expected=$(cat $EXPECTED/notmuch-show-thread-with-hidden-messages)
+test_expect_equal "$output" "$expected"
+
+test_begin_subtest "Hiding message with visible citation in notmuch-show view"
+output=$(test_emacs '(notmuch-show 
"id:f35dbb950911171438k5df6eb56k77b6c0944e2e7...@mail.gmail.com")
+(search-forward "Click/Enter to show.")
+(button-activate (button-at (point)))
+(notmuch-show-toggle-message)
+(princ (visible-buffer-string))')
+expected=$(cat $EXPECTED/notmuch-show-thread-with-hidden-messages)
+test_expect_equal "$output" "$expected"
+
 test_done
diff --git 
a/test/emacs.expected-output/notmuch-show-thread-with-hidden-messages 
b/test/emacs.expected-output/notmuch-show-thread-with-hidden-messages
new file mode 100644
index 000..5df6606
--- /dev/null
+++ b/test/emacs.expected-output/notmuch-show-thread-with-hidden-messages
@@ -0,0 +1,3 @@
+Jan Janak  (2009-11-17) (inbox unread)
+ Jan Janak  (2009-11-17) (inbox)
+ Carl Worth  (2009-11-18) (inbox unread)
-- 
1.7.5.1

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

Re: [PATCH] emacs: Add a customization allowing to always prompt for the "From" address when composing a new message

[Jameson Graef Rollins]

On Thu, 26 May 2011 14:11:11 -0700, Carl Worth  wrote:
> It's a nice patch series, and I've pushed it all out now.

After using this feature for a day, I think it's great.  But it would be
nice if the name was just automatically filled in, since that doesn't
change, and the ido selection cycled through just the email addresses.
I think that would make the interface a lot cleaner.  Currently I see my
name a whole bunch of times as I'm trying to search for just small
differences in the address field.

jamie.


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

[PATCH] emacs: Add a customization allowing to always prompt for the "From" address when composing a new message

[Jameson Graef Rollins]

On Thu, 26 May 2011 14:11:11 -0700, Carl Worth  wrote:
> It's a nice patch series, and I've pushed it all out now.

After using this feature for a day, I think it's great.  But it would be
nice if the name was just automatically filled in, since that doesn't
change, and the ido selection cycled through just the email addresses.
I think that would make the interface a lot cleaner.  Currently I see my
name a whole bunch of times as I'm trying to search for just small
differences in the address field.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110526/d00aa435/attachment.pgp>

Re: [PATCH 3/5] Fix hiding a message while some citations are shown in notmuch-show view.

[Carl Worth]

On Thu, 26 May 2011 14:26:34 +0400, Dmitry Kurochkin 
 wrote:
> It is called indirectly.  What is the best way to fix it?  I imagine
> that we can replace `isearch-range-invisible' function with another one,
> which would call the fixed function if some special variable is set, or
> if we are searching in a notmuch-show view.  Otherwise it would call the
> original function.

I'm not sure what the best approach would be. I'd like to be a good
"emacs citizen" but I don't know what the best way to do that is here.

If we can predict what the first emacs release will be that contains the
fix, then we could restrict our kludge here to older, unfixed
emacs. That would help avoid some problems with "bad citizenship here".

I'm willing to take whatever you this is best here.

-Carl

-- 
carl.d.wo...@intel.com


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

[PATCH 3/5] Fix hiding a message while some citations are shown in notmuch-show view.

[Carl Worth]

On Thu, 26 May 2011 14:26:34 +0400, Dmitry Kurochkin  wrote:
> It is called indirectly.  What is the best way to fix it?  I imagine
> that we can replace `isearch-range-invisible' function with another one,
> which would call the fixed function if some special variable is set, or
> if we are searching in a notmuch-show view.  Otherwise it would call the
> original function.

I'm not sure what the best approach would be. I'd like to be a good
"emacs citizen" but I don't know what the best way to do that is here.

If we can predict what the first emacs release will be that contains the
fix, then we could restrict our kludge here to older, unfixed
emacs. That would help avoid some problems with "bad citizenship here".

I'm willing to take whatever you this is best here.

-Carl

-- 
carl.d.worth at intel.com
-- 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/20110526/06f565d9/attachment.pgp>

[PATCH 3/5] Fix hiding a message while some citations are shown in notmuch-show view.

[Dmitry Kurochkin]

On Wed, 25 May 2011 18:02:49 -0700, Carl Worth  wrote:
> On Thu, 26 May 2011 03:10:11 +0400, Dmitry Kurochkin  gmail.com> wrote:
> > On Wed, 25 May 2011 15:46:40 -0700, Carl Worth  wrote:
> > Well, emacs trunk is not broken :)  The bug is in lisp code, so you can
> > fix it in .emacs by redefining `isearch-range-invisible' function.  I do
> > that now.
> 
> Oh, in that case we can fix this is notmuch emacs lisp by just defining
> and using a fixed function. Is the broken function something we're
> calling directly? Or is it being called indirectly? (being called by
> other emacs lisp code that we are calling)?
> 

It is called indirectly.  What is the best way to fix it?  I imagine
that we can replace `isearch-range-invisible' function with another one,
which would call the fixed function if some special variable is set, or
if we are searching in a notmuch-show view.  Otherwise it would call the
original function.

> If we can incorporate the fix, that would be great.
> 
> > Please consider pushing other patches from the series.  They do not fix
> > any bug, but do simplify the code.  The last patch uses list for
> > invisible overlay property as well.  But it does not break isearch
> > because we do not search in hidden messages.
> 
> Hmmm... we should probably do that. I'd like isearch in notmuch to
> search anything that is hidden.
> 

That is easy to fix.  I can do that once we are done with this stuff.

> > BTW would be nice to have a set of known-to-fail tests, i.e. bugs that
> > are not fixed yet.  If we had it, the above test could be implemented
> > and committed before we have the fix pushed.
> 
> We do! Use test_expect_equal_failure (yes, the name is horrible!)
> instead of test_expect_equal and you should get what you want.
> 

I should look at it, thanks.

Regards,
  Dmitry

> -Carl
> 
> -- 
> carl.d.worth at intel.com

Re: [PATCH 0/2] Implement reply to sender

[Carl Worth]

On Thu, 26 May 2011 17:06:50 +0100, Mark Walters  
wrote:
> These patches implement a reply to sender function.
> On the command line this is done via a new format
> "--format=one" to notmuch reply.
> In emacs it is bound to the key R

I like the feature (at the emacs level). Doing this with "--format=one"
isn't correct though. This new functionality should be orthogonal to
format, (for example, one might want --format=headers-only and still
reply only to the sender).

How about:

--reply-to=sender
vs.
--reply-to=all  # Which would be the default

Also, the patch should update the documentation for "notmuch reply",
(both in notmuch.c and notmuch.1).

> I have been running a similar patch set for some time but 
> only tidied it up today. It compiles and works for me.

Thanks for sharing this.

> This is my first submission to the project so I hope that I
> have done everything right.

Perfectly. Keep up the good work.

> Signed-off-by: Mark Walters 

We don't actually require signed-off-by lines in the notmuch project. I
know the notmuchmail.org website currently points to the git project's
patch submission guidelines. We should really write our own such
guidelines, (which would be dramatically simpler than those from the git
project).

-Carl

-- 
carl.d.wo...@intel.com


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

[PATCH 0/2] Implement reply to sender

[Carl Worth]

On Thu, 26 May 2011 17:06:50 +0100, Mark Walters  
wrote:
> These patches implement a reply to sender function.
> On the command line this is done via a new format
> "--format=one" to notmuch reply.
> In emacs it is bound to the key R

I like the feature (at the emacs level). Doing this with "--format=one"
isn't correct though. This new functionality should be orthogonal to
format, (for example, one might want --format=headers-only and still
reply only to the sender).

How about:

--reply-to=sender
vs.
--reply-to=all  # Which would be the default

Also, the patch should update the documentation for "notmuch reply",
(both in notmuch.c and notmuch.1).

> I have been running a similar patch set for some time but 
> only tidied it up today. It compiles and works for me.

Thanks for sharing this.

> This is my first submission to the project so I hope that I
> have done everything right.

Perfectly. Keep up the good work.

> Signed-off-by: Mark Walters 

We don't actually require signed-off-by lines in the notmuch project. I
know the notmuchmail.org website currently points to the git project's
patch submission guidelines. We should really write our own such
guidelines, (which would be dramatically simpler than those from the git
project).

-Carl

-- 
carl.d.worth at intel.com
-- 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/20110526/ccf526fd/attachment.pgp>

Re: 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 
>  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

Re: [PATCH] test: add test-lib.el file with `visible-buffer-string' function

[Carl Worth]

On Thu, 26 May 2011 20:27:58 +0400, Dmitry Kurochkin 
 wrote:
> The patch adds test-lib.el file for Emacs tests auxiliary stuff.
> Currently, it implements two functions: `visible-buffer-string'
> and `visible-buffer-substring'.  These are similar to standard
> counterparts without "visible-" prefix but exclude invisible
> text.  The functions are not used anywhere at the moment but
> should be useful for testing hiding/showing in the Emacs
> interface.

Thanks. I generally hesitate to add dead code, but I think this will
come in handy at some point in the future, (where it might help motivate
someone to write that they might not write if this code weren't handy).

Pushed.

-Carl

-- 
carl.d.wo...@intel.com


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

[PATCH] test: add test-lib.el file with `visible-buffer-string' function

[Carl Worth]

On Thu, 26 May 2011 20:27:58 +0400, Dmitry Kurochkin  wrote:
> The patch adds test-lib.el file for Emacs tests auxiliary stuff.
> Currently, it implements two functions: `visible-buffer-string'
> and `visible-buffer-substring'.  These are similar to standard
> counterparts without "visible-" prefix but exclude invisible
> text.  The functions are not used anywhere at the moment but
> should be useful for testing hiding/showing in the Emacs
> interface.

Thanks. I generally hesitate to add dead code, but I think this will
come in handy at some point in the future, (where it might help motivate
someone to write that they might not write if this code weren't handy).

Pushed.

-Carl

-- 
carl.d.worth at intel.com
-- 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/20110526/c13997ff/attachment.pgp>

Re: [PATCH] emacs: Add a customization allowing to always prompt for the "From" address when composing a new message

[Carl Worth]

On Thu, 26 May 2011 19:22:41 +0200, Thomas Jost  wrote:
> ---
> Hi Jameson,
> 
> Here it is :) I'm sure it will be useful for many other people too, including
> myself. To be applied on top of my other patches, then you can set
> notmuch-always-prompt-for-sender to t.

Thanks, Thomas.

It's a nice patch series, and I've pushed it all out now.

-Carl

-- 
carl.d.wo...@intel.com


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

[PATCH] emacs: Add a customization allowing to always prompt for the "From" address when composing a new message

[Carl Worth]

On Thu, 26 May 2011 19:22:41 +0200, Thomas Jost  
wrote:
> ---
> Hi Jameson,
> 
> Here it is :) I'm sure it will be useful for many other people too, including
> myself. To be applied on top of my other patches, then you can set
> notmuch-always-prompt-for-sender to t.

Thanks, Thomas.

It's a nice patch series, and I've pushed it all out now.

-Carl

-- 
carl.d.worth at intel.com
-- 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/20110526/7cfc444b/attachment.pgp>

Re: one-time-iterators

[Austin Clements]

On May 26, 2011 1:20 PM, "Carl Worth"  wrote:
> > 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 proposed a solution to this problem a while ago
(id:"AANLkTi=kox8atjipkiarfvjehe6zt_jypoasmiiaw...@mail.gmail.com"),
though I haven't tried implementing it yet.

Though, Patrick, that solution doesn't address your problem.  On the
other hand, it's not clear to me what concurrent access semantics
you're actually expecting.  I suspect you don't want the remaining
iteration to reflect the changes, since your changes could equally
well have affected earlier iteration results.  But if you want a
consistent view of your query results, something's going to have to
materialize that iterator, and it might as well be you (or Xapian
would need more sophisticated concurrency control than it has).  But
this shouldn't be expensive because all you need to materialize are
the document ids; you shouldn't need to eagerly fetch the per-thread
information.  Have you tried simply calling list() on your thread
iterator to see how expensive it is?  My bet is that it's quite cheap,
both memory-wise and CPU-wise.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] emacs: Add a customization allowing to always prompt for the "From" address when composing a new message

[Jameson Graef Rollins]

On Thu, 26 May 2011 19:22:41 +0200, Thomas Jost  wrote:
> Here it is :) I'm sure it will be useful for many other people too, including
> myself. To be applied on top of my other patches, then you can set
> notmuch-always-prompt-for-sender to t.

Awesome!  Thanks, Thomas.

jamie.


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

[PATCH] emacs: Add a customization allowing to always prompt for the "From" address when composing a new message

[Jameson Graef Rollins]

On Thu, 26 May 2011 19:22:41 +0200, Thomas Jost  
wrote:
> Here it is :) I'm sure it will be useful for many other people too, including
> myself. To be applied on top of my other patches, then you can set
> notmuch-always-prompt-for-sender to t.

Awesome!  Thanks, Thomas.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110526/f20771dc/attachment.pgp>

[PATCH v2 4/4] emacs: Allow the user to choose the "From" address when replying to a message

[Thomas Jost]

When pressing C-u r, the user will be prompted for the identity to use.
---
 emacs/notmuch-mua.el  |   13 -
 emacs/notmuch-show.el |6 +++---
 emacs/notmuch.el  |6 +++---
 3 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 1b777d9..f2d86bb 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -69,7 +69,7 @@ list."
(push header message-hidden-headers)))
notmuch-mua-hidden-headers))

-(defun notmuch-mua-reply (query-string)
+(defun notmuch-mua-reply (query-string &optional sender)
   (let (headers
body
(args '("reply")))
@@ -90,6 +90,9 @@ list."
  (setq headers (mail-header-extract)
   (forward-line 1)
   (setq body (buffer-substring (point) (point-max
+;; If sender is non-nil, set the From: header to its value.
+(when sender
+  (mail-header-set 'from sender headers))
 (let
;; Overlay the composition window on that being used to read
;; the original message.
@@ -191,6 +194,14 @@ the From: address first."
(notmuch-mua-forward-message))
 (notmuch-mua-forward-message)))

+(defun notmuch-mua-new-reply (query-string &optional prompt-for-sender)
+  "Invoke the notmuch reply window."
+  (interactive "P")
+  (let ((sender
+(when prompt-for-sender
+  (notmuch-mua-prompt-for-sender
+(notmuch-mua-reply query-string sender)))
+
 (defun notmuch-mua-send-and-exit (&optional arg)
   (interactive "P")
   (message-send-and-exit arg))
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 7e493e9..1c5dfd7 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -1153,10 +1153,10 @@ any effects from previous calls to
   ;; Move to the previous message.
   (notmuch-show-previous-message)

-(defun notmuch-show-reply ()
+(defun notmuch-show-reply (&optional prompt-for-sender)
   "Reply to the current message."
-  (interactive)
-  (notmuch-mua-reply (notmuch-show-get-message-id)))
+  (interactive "P")
+  (notmuch-mua-new-reply (notmuch-show-get-message-id) prompt-for-sender))

 (defun notmuch-show-forward-message (&optional prompt-for-sender)
   "Forward the current message."
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 21e0314..3d984bc 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -442,11 +442,11 @@ Complete list of currently available key bindings:
  crypto-switch)
   (error "End of search results"

-(defun notmuch-search-reply-to-thread ()
+(defun notmuch-search-reply-to-thread (&optional prompt-for-sender)
   "Begin composing a reply to the entire current thread in a new buffer."
-  (interactive)
+  (interactive "P")
   (let ((message-id (notmuch-search-find-thread-id)))
-(notmuch-mua-reply message-id)))
+(notmuch-mua-new-reply message-id prompt-for-sender)))

 (defun notmuch-call-notmuch-process (&rest args)
   "Synchronously invoke \"notmuch\" with the given list of arguments.
-- 
1.7.5.1

[PATCH v2 3/4] emacs: Allow the user to choose the "From" address when forwarding a message

[Thomas Jost]

When pressing C-u f, the user will be prompted for the identity to use.
---
 emacs/notmuch-mua.el  |   14 ++
 emacs/notmuch-show.el |6 +++---
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 74c9fc1..1b777d9 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -177,6 +177,20 @@ the From: address first."
   (list (cons 'from (notmuch-mua-prompt-for-sender))
 (notmuch-mua-mail nil nil other-headers)))

+(defun notmuch-mua-new-forward-message (&optional prompt-for-sender)
+  "Invoke the notmuch message forwarding window.
+
+If PROMPT-FOR-SENDER is non-nil, the user will be prompted for
+the From: address first."
+  (interactive "P")
+  (if prompt-for-sender
+  (let* ((sender (notmuch-mua-prompt-for-sender))
+(address-components (mail-extract-address-components sender))
+(user-full-name (car address-components))
+(user-mail-address (cadr address-components)))
+   (notmuch-mua-forward-message))
+(notmuch-mua-forward-message)))
+
 (defun notmuch-mua-send-and-exit (&optional arg)
   (interactive "P")
   (message-send-and-exit arg))
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 48d2926..7e493e9 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -1158,11 +1158,11 @@ any effects from previous calls to
   (interactive)
   (notmuch-mua-reply (notmuch-show-get-message-id)))

-(defun notmuch-show-forward-message ()
+(defun notmuch-show-forward-message (&optional prompt-for-sender)
   "Forward the current message."
-  (interactive)
+  (interactive "P")
   (with-current-notmuch-show-message
-   (notmuch-mua-forward-message)))
+   (notmuch-mua-new-forward-message prompt-for-sender)))

 (defun notmuch-show-next-message ()
   "Show the next message."
-- 
1.7.5.1

[PATCH v2 2/4] emacs: Allow the user to choose the "From" address when composing a new message

[Thomas Jost]

When pressing C-u m, the user will be prompted for the identity to use.
---
 emacs/notmuch-hello.el |2 +-
 emacs/notmuch-mua.el   |   11 +++
 emacs/notmuch-show.el  |2 +-
 emacs/notmuch.el   |2 +-
 4 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index e58dd24..ab06d3a 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -298,7 +298,7 @@ should be. Returns a cons cell `(tags-per-line width)'."
 (define-key map "=" 'notmuch-hello-update)
 (define-key map "G" 'notmuch-hello-poll-and-update)
 (define-key map (kbd "") 'widget-backward)
-(define-key map "m" 'notmuch-mua-mail)
+(define-key map "m" 'notmuch-mua-new-mail)
 (define-key map "s" 'notmuch-hello-goto-search)
 map)
   "Keymap for \"notmuch hello\" buffers.")
diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 2baf6bd..74c9fc1 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -166,6 +166,17 @@ name and addresses configured in the notmuch configuration 
file."
 (ido-completing-read "Send mail From: " collection
 nil 'confirm nil 'notmuch-mua-sender-history (car 
collection

+(defun notmuch-mua-new-mail (&optional prompt-for-sender)
+  "Invoke the notmuch mail composition window.
+
+If PROMPT-FOR-SENDER is non-nil, the user will be prompted for
+the From: address first."
+  (interactive "P")
+  (let ((other-headers
+(when prompt-for-sender
+  (list (cons 'from (notmuch-mua-prompt-for-sender))
+(notmuch-mua-mail nil nil other-headers)))
+
 (defun notmuch-mua-send-and-exit (&optional arg)
   (interactive "P")
   (message-send-and-exit arg))
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 825988c..48d2926 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -847,7 +847,7 @@ function is used. "
(define-key map (kbd "") 'notmuch-show-previous-button)
(define-key map (kbd "TAB") 'notmuch-show-next-button)
(define-key map "s" 'notmuch-search)
-   (define-key map "m" 'notmuch-mua-mail)
+   (define-key map "m" 'notmuch-mua-new-mail)
(define-key map "f" 'notmuch-show-forward-message)
(define-key map "r" 'notmuch-show-reply)
(define-key map "|" 'notmuch-show-pipe-message)
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 1d683f8..21e0314 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -204,7 +204,7 @@ For a mouse binding, return nil."
 (define-key map "p" 'notmuch-search-previous-thread)
 (define-key map "n" 'notmuch-search-next-thread)
 (define-key map "r" 'notmuch-search-reply-to-thread)
-(define-key map "m" 'notmuch-mua-mail)
+(define-key map "m" 'notmuch-mua-new-mail)
 (define-key map "s" 'notmuch-search)
 (define-key map "o" 'notmuch-search-toggle-order)
 (define-key map "c" 'notmuch-search-stash-map)
-- 
1.7.5.1

[PATCH v2 1/4] emacs: Helpers needed for the user to be able to choose the "From" address when composing a new message

[Thomas Jost]

This adds functions and variables needed for this feature to be implemented.
Once it's done, the user will be able to use a prefix argument (e.g. pressing
C-u m instead of m) and be able to select a From address.

By default the list of names/addresses to be used during completion will be
automatically generated by the settings in the notmuch configuration file. The
user can customize the notmuch-identities variable to provide an alternate list.

This is based on a previous patch by Carl Worth
(id:"87wrhfvk6a.fsf at yoom.home.cworth.org" and follow-ups).
---
 emacs/notmuch-mua.el |   23 +++
 1 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 003b313..2baf6bd 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -143,6 +143,29 @@ list."

   (message-goto-to))

+(defcustom notmuch-identities nil
+  "Identities that can be used as the From: address when composing a new 
message.
+
+If this variable is left unset, then a list will be constructed from the
+name and addresses configured in the notmuch configuration file."
+  :group 'notmuch
+  :type '(repeat string))
+
+(defun notmuch-mua-sender-collection ()
+  (if notmuch-identities
+  notmuch-identities
+(mapcar (lambda (address)
+ (concat (notmuch-user-name) " <" address ">"))
+   (cons (notmuch-user-primary-email) (notmuch-user-other-email)
+
+(defvar notmuch-mua-sender-history nil)
+
+(defun notmuch-mua-prompt-for-sender ()
+  (interactive)
+  (let ((collection (notmuch-mua-sender-collection)))
+(ido-completing-read "Send mail From: " collection
+nil 'confirm nil 'notmuch-mua-sender-history (car 
collection
+
 (defun notmuch-mua-send-and-exit (&optional arg)
   (interactive "P")
   (message-send-and-exit arg))
-- 
1.7.5.1

[PATCH] emacs: Allow user to choose "From" address when composing a new message.

[Thomas Jost]

On Wed, 25 May 2011 15:17:05 -0700, Carl Worth  wrote:
> > I'll also send a few additional patches that make it possible to choose
> > the "From" address when forwarding a message and when replying to a
> > message.
> 
> The only real concern I have with the series is that it grabs 'R' for
> reply-with-custom-from where I've been planning to implement 'R' as
> reply-to-sender-only, (a long-missing and often-requested feature).

That would be nice indeed :)

> When I first started implementing the custom-from feature I planned to
> use a prefix argument to get the behavior (such as "C-u m" rather than
> "M" for compose-new-mail-with-custom-from). You might even see I've got
> some code written along those lines.

Good idea, this will probably seem more natural for Emacs users.

> When I went to test it though, it didn't work. That was probably some
> silly mistake on my part, (we do already have working code that changes
> behavior with a prefix argument in the case of "M-RET" for example).
> 
> If you want to update the series to move away from capital-letter
> keybindings in favor of a prefix argument, I'll be glad to accept it.

Done and tested locally, seems OK so far. This makes the code smaller
and IMHO nicer because it eliminates all the -prompt-for-sender
variants. I'll send the updated patch series very soon.

Thanks,

-- 
Thomas/Schnouki
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110526/fa7357e4/attachment.pgp>

[PATCH] emacs: Add a customization allowing to always prompt for the "From" address when composing a new message

[Thomas Jost]

---
Hi Jameson,

Here it is :) I'm sure it will be useful for many other people too, including
myself. To be applied on top of my other patches, then you can set
notmuch-always-prompt-for-sender to t.

Regards,
Thomas

 emacs/notmuch-mua.el |   11 ---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index f2d86bb..7c05a81 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -154,6 +154,11 @@ name and addresses configured in the notmuch configuration 
file."
   :group 'notmuch
   :type '(repeat string))
 
+(defcustom notmuch-always-prompt-for-sender nil
+  "Always prompt for the From: address when composing a new message."
+  :group 'notmuch
+  :type 'boolean)
+
 (defun notmuch-mua-sender-collection ()
   (if notmuch-identities
   notmuch-identities
@@ -176,7 +181,7 @@ If PROMPT-FOR-SENDER is non-nil, the user will be prompted 
for
 the From: address first."
   (interactive "P")
   (let ((other-headers
-(when prompt-for-sender
+(when (or prompt-for-sender notmuch-always-prompt-for-sender)
   (list (cons 'from (notmuch-mua-prompt-for-sender))
 (notmuch-mua-mail nil nil other-headers)))
 
@@ -186,7 +191,7 @@ the From: address first."
 If PROMPT-FOR-SENDER is non-nil, the user will be prompted for
 the From: address first."
   (interactive "P")
-  (if prompt-for-sender
+  (if (or prompt-for-sender notmuch-always-prompt-for-sender)
   (let* ((sender (notmuch-mua-prompt-for-sender))
 (address-components (mail-extract-address-components sender))
 (user-full-name (car address-components))
@@ -198,7 +203,7 @@ the From: address first."
   "Invoke the notmuch reply window."
   (interactive "P")
   (let ((sender
-(when prompt-for-sender
+(when (or prompt-for-sender notmuch-always-prompt-for-sender)
   (notmuch-mua-prompt-for-sender
 (notmuch-mua-reply query-string sender)))
 
-- 
1.7.5.2

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

Re: one-time-iterators

[Carl Worth]

On Thu, 26 May 2011 09:31:19 +0100, Patrick Totzke 
 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.

-Carl

-- 
carl.d.wo...@intel.com


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

one-time-iterators

[Carl Worth]

On Thu, 26 May 2011 09:31:19 +0100, Patrick Totzke  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.

-Carl

-- 
carl.d.worth at intel.com
-- 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/20110526/3d80b45e/attachment.pgp>

one-time-iterators

[Patrick Totzke]

Hi!

I'm playing around with one-time iterators Threads in the python bindings
in combination with changes to the database.
Particularly, I'd like to iterate over a list of threads partially,
change the tags of a single thread and afterwards continue iterating.
Of course I get "Xapian DB-changed" exceptions.
As I see it, there are two possible solutions:
First, I iterate over all the threads and cache all the info i'd like to 
extract from each one (or just the id and re-query the info on demand).
The problem here is, that this list of thread-ids might be huge and
caching it will block my code.
Secondly, I could replace the iterator i'm using with a fresh one after 
db-changes. But then I'd need some magic that discards an initial
portion of the (fresh) iteration and/or updates the pre-db-change
partial iteration.

Wow. This reads really complicated. All I want to say is:
if I change tags in my search-results view, I get Xapian errors :)
The question: How do you solve this in the emacs code?
do you store all tids of a query? 

Thanks,
/p

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110526/556bd75e/attachment.pgp>

[PATCH] test: add test-lib.el file with `visible-buffer-string' function

[Dmitry Kurochkin]

The patch adds test-lib.el file for Emacs tests auxiliary stuff.
Currently, it implements two functions: `visible-buffer-string'
and `visible-buffer-substring'.  These are similar to standard
counterparts without "visible-" prefix but exclude invisible
text.  The functions are not used anywhere at the moment but
should be useful for testing hiding/showing in the Emacs
interface.
---
 test/test-lib.el |   35 +++
 test/test-lib.sh |5 +++--
 2 files changed, 38 insertions(+), 2 deletions(-)
 create mode 100644 test/test-lib.el

diff --git a/test/test-lib.el b/test/test-lib.el
new file mode 100644
index 000..9439996
--- /dev/null
+++ b/test/test-lib.el
@@ -0,0 +1,35 @@
+;; test-lib.el --- auxiliary stuff for Notmuch Emacs tests.
+;;
+;; Copyright © Carl Worth
+;; Copyright © David Edmondson
+;;
+;; This file is part of Notmuch test suit.
+;;
+;; Notmuch is free software: you can redistribute it and/or modify it
+;; under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+;;
+;; Notmuch is distributed in the hope that it will be useful, but
+;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+;; General Public License for more details.
+;;
+;; You should have received a copy of the GNU General Public License
+;; along with Notmuch.  If not, see .
+;;
+;; Authors: Dmitry Kurochkin 
+
+(defun visible-buffer-string ()
+  "Same as `buffer-string', but excludes invisible text."
+  (visible-buffer-substring (point-min) (point-max)))
+
+(defun visible-buffer-substring (start end)
+  "Same as `buffer-substring', but excludes invisible text."
+  (let (str)
+(while (< start end)
+  (let ((next-pos (next-char-property-change start end)))
+   (when (not (invisible-p start))
+ (setq str (concat str (buffer-substring start next-pos
+   (setq start next-pos)))
+str))
diff --git a/test/test-lib.sh b/test/test-lib.sh
index 7cc43cd..9645567 100755
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -843,9 +843,9 @@ fi
 #
 # --no-site-file   Don't load the site-wide startup stuff
 #
-# --directory  Ensure that the local notmuch.el source is found
+# --directory  Ensure that the local elisp sources are found
 #
-# --load   Force loading of notmuch.el
+# --load   Force loading of notmuch.el and test-lib.el
 #
 # notmuch-test-waitFunction for tests to use to wait for process completion
 #
@@ -855,6 +855,7 @@ fi
 
 emacs \$BATCH --no-init-file --no-site-file \
--directory ../../emacs --load notmuch.el \
+   --directory .. --load test-lib.el \
--eval "(defun notmuch-test-wait ()
(while (get-buffer-process (current-buffer))
(sleep-for 0.1)))" \
-- 
1.7.5.1

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

[PATCH 1/2] Command line changes for reply-to-sender

[Mark Walters]

Adds the format "--format=one" to possible reply formats which only
replies to the sender.

More precisely the function follows these rules:
reply only to sender unless it was the user
reply only to all people on the to line unless they were all the user
reply to all people on the cc line

The most common expected case is we just reply to sender, but if we reply to
our own email then we reply to the whole to line.

Implementation details

Note we continue parsing addresses beyond the ones we reply to because
we want to make sure the from address is correct. (At the very least it
is the same as it would be if we replied to all.)

We overload the message variable in add_recipients_for_address_list so
if it is NULL we parse the address (looking for the users address)
but do not add to the message recipients list

We add the variable reply_to_all to the function chain to keep track
of whether we should reply to everyone.
---
 notmuch-reply.c |   38 +++---
 1 files changed, 27 insertions(+), 11 deletions(-)

diff --git a/notmuch-reply.c b/notmuch-reply.c
index ab15650..3df3b52 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -191,7 +191,8 @@ add_recipients_for_address_list (GMimeMessage *message,
if (ret == NULL)
ret = addr;
} else {
-   g_mime_message_add_recipient (message, type, name, addr);
+if (message) 
+ g_mime_message_add_recipient (message, type, name, addr);
}
}
 }
@@ -271,7 +272,8 @@ reply_to_header_is_redundant (notmuch_message_t *message)
 static const char *
 add_recipients_from_message (GMimeMessage *reply,
 notmuch_config_t *config,
-notmuch_message_t *message)
+notmuch_message_t *message,
+int reply_to_all)
 {
 struct {
const char *header;
@@ -311,9 +313,20 @@ add_recipients_from_message (GMimeMessage *reply,
recipients = notmuch_message_get_header (message,
 reply_to_map[i].fallback);
 
-   addr = add_recipients_for_string (reply, config,
- reply_to_map[i].recipient_type,
- recipients);
+
+   /* We add the addresses if we are replying to all or we have not yet 
found
+* a non-user address. We have to keep parsing to make sure we do find 
the 
+* correct from address for the user, but we pass a NULL message
+*/
+   if ((reply_to_all) || (g_mime_message_get_all_recipients (reply) == 
NULL))
+   addr = add_recipients_for_string (reply, config,
+ reply_to_map[i].recipient_type,
+ recipients);
+   else
+addr = add_recipients_for_string (NULL, config,
+  reply_to_map[i].recipient_type,
+  recipients);
+
if (from_addr == NULL)
from_addr = addr;
 }
@@ -453,7 +466,7 @@ guess_from_received_header (notmuch_config_t *config, 
notmuch_message_t *message
 }
 
 static int
-notmuch_reply_format_default(void *ctx, notmuch_config_t *config, 
notmuch_query_t *query)
+notmuch_reply_format_default(void *ctx, notmuch_config_t *config, 
notmuch_query_t *query, int reply_to_all)
 {
 GMimeMessage *reply;
 notmuch_messages_t *messages;
@@ -484,7 +497,7 @@ notmuch_reply_format_default(void *ctx, notmuch_config_t 
*config, notmuch_query_
g_mime_message_set_subject (reply, subject);
}
 
-   from_addr = add_recipients_from_message (reply, config, message);
+   from_addr = add_recipients_from_message (reply, config, message, 
reply_to_all);
 
if (from_addr == NULL)
from_addr = guess_from_received_header (config, message);
@@ -531,7 +544,7 @@ notmuch_reply_format_default(void *ctx, notmuch_config_t 
*config, notmuch_query_
 
 /* This format is currently tuned for a git send-email --notmuch hook */
 static int
-notmuch_reply_format_headers_only(void *ctx, notmuch_config_t *config, 
notmuch_query_t *query)
+notmuch_reply_format_headers_only(void *ctx, notmuch_config_t *config, 
notmuch_query_t *query, int reply_to_all)
 {
 GMimeMessage *reply;
 notmuch_messages_t *messages;
@@ -571,7 +584,7 @@ notmuch_reply_format_headers_only(void *ctx, 
notmuch_config_t *config, notmuch_q
g_mime_object_set_header (GMIME_OBJECT (reply),
  "References", references);
 
-   (void)add_recipients_from_message (reply, config, message);
+   (void)add_recipients_from_message (reply, config, message, 
reply_to_all);
 
reply_headers = g_mime_object_to_string (GMIME_OBJECT (reply));
printf ("%s", reply_headers);
@@ -593,7 +606,8 @@ notmuch_reply_command (v

[PATCH 2/2] Emacs changes for reply to sender

[Mark Walters]

Reply to sender is currently bound to R
---
 emacs/notmuch-mua.el  |6 --
 emacs/notmuch-show.el |6 ++
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index dc7b386..4b8590f 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -69,13 +69,15 @@ list."
(push header message-hidden-headers)))
notmuch-mua-hidden-headers))
 
-(defun notmuch-mua-reply (query-string)
+(defun notmuch-mua-reply (query-string &optional option-string)
   (let (headers body)
 ;; This make assumptions about the output of `notmuch reply', but
 ;; really only that the headers come first followed by a blank
 ;; line and then the body.
 (with-temp-buffer
-  (call-process notmuch-command nil t nil "reply" query-string)
+  (if option-string
+ (call-process notmuch-command nil t nil "reply" option-string 
query-string)
+   (call-process notmuch-command nil t nil "reply" query-string))
   (goto-char (point-min))
   (if (re-search-forward "^$" nil t)
  (save-excursion
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 9a38d9c..5dbc103 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -795,6 +795,7 @@ function is used. "
(define-key map "m" 'notmuch-mua-mail)
(define-key map "f" 'notmuch-show-forward-message)
(define-key map "r" 'notmuch-show-reply)
+   (define-key map "R" 'notmuch-show-reply-one)
(define-key map "|" 'notmuch-show-pipe-message)
(define-key map "w" 'notmuch-show-save-attachments)
(define-key map "V" 'notmuch-show-view-raw-message)
@@ -1103,6 +1104,11 @@ any effects from previous calls to
   (interactive)
   (notmuch-mua-reply (notmuch-show-get-message-id)))
 
+(defun notmuch-show-reply-one ()
+  "Reply to the current message."
+  (interactive)
+  (notmuch-mua-reply (notmuch-show-get-message-id) "--format=one"))
+
 (defun notmuch-show-forward-message ()
   "Forward the current message."
   (interactive)
-- 
1.7.2.5

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

[PATCH 0/2] Implement reply to sender

[Mark Walters]

These patches implement a reply to sender function.
On the command line this is done via a new format
"--format=one" to notmuch reply.
In emacs it is bound to the key R

I have been running a similar patch set for some time but 
only tidied it up today. It compiles and works for me.

This is my first submission to the project so I hope that I
have done everything right.

Signed-off-by: Mark Walters 

Mark Walters (2):
  Command line changes for reply-to-sender
  Emacs changes for reply to sender

 emacs/notmuch-mua.el  |6 --
 emacs/notmuch-show.el |6 ++
 notmuch-reply.c   |   38 +++---
 3 files changed, 37 insertions(+), 13 deletions(-)

-- 
1.7.2.5

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

Re: [PATCH] emacs: Allow user to choose "From" address when composing a new message.

[Jameson Graef Rollins]

On Thu, 26 May 2011 10:39:58 +0200, Thomas Jost  wrote:
> > When I first started implementing the custom-from feature I planned to
> > use a prefix argument to get the behavior (such as "C-u m" rather than
> > "M" for compose-new-mail-with-custom-from). You might even see I've got
> > some code written along those lines.
> 
> Good idea, this will probably seem more natural for Emacs users.

The reason I really want to see this feature is because I always forget
to change my from address depending on the context of my email.  Given
that's my issue, I will also always forget to use a different command to
compose/reply.  In other words, I think the real way to enable this
feature should be via a customization variable.  Either that, or I'll
just modify my custom keybindings to always prompt when I just press the
regular compose/reply keys.

Thanks for work on this feature, Thomas.

jamie.


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

[PATCH] emacs: Allow user to choose "From" address when composing a new message.

[Jameson Graef Rollins]

On Thu, 26 May 2011 10:39:58 +0200, Thomas Jost  
wrote:
> > When I first started implementing the custom-from feature I planned to
> > use a prefix argument to get the behavior (such as "C-u m" rather than
> > "M" for compose-new-mail-with-custom-from). You might even see I've got
> > some code written along those lines.
> 
> Good idea, this will probably seem more natural for Emacs users.

The reason I really want to see this feature is because I always forget
to change my from address depending on the context of my email.  Given
that's my issue, I will also always forget to use a different command to
compose/reply.  In other words, I think the real way to enable this
feature should be via a customization variable.  Either that, or I'll
just modify my custom keybindings to always prompt when I just press the
regular compose/reply keys.

Thanks for work on this feature, Thomas.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110526/9bfd3f62/attachment.pgp>

Re: [PATCH 3/5] Fix hiding a message while some citations are shown in notmuch-show view.

[Dmitry Kurochkin]

On Wed, 25 May 2011 18:02:49 -0700, Carl Worth  wrote:
> On Thu, 26 May 2011 03:10:11 +0400, Dmitry Kurochkin 
>  wrote:
> > On Wed, 25 May 2011 15:46:40 -0700, Carl Worth  wrote:
> > Well, emacs trunk is not broken :)  The bug is in lisp code, so you can
> > fix it in .emacs by redefining `isearch-range-invisible' function.  I do
> > that now.
> 
> Oh, in that case we can fix this is notmuch emacs lisp by just defining
> and using a fixed function. Is the broken function something we're
> calling directly? Or is it being called indirectly? (being called by
> other emacs lisp code that we are calling)?
> 

It is called indirectly.  What is the best way to fix it?  I imagine
that we can replace `isearch-range-invisible' function with another one,
which would call the fixed function if some special variable is set, or
if we are searching in a notmuch-show view.  Otherwise it would call the
original function.

> If we can incorporate the fix, that would be great.
> 
> > Please consider pushing other patches from the series.  They do not fix
> > any bug, but do simplify the code.  The last patch uses list for
> > invisible overlay property as well.  But it does not break isearch
> > because we do not search in hidden messages.
> 
> Hmmm... we should probably do that. I'd like isearch in notmuch to
> search anything that is hidden.
> 

That is easy to fix.  I can do that once we are done with this stuff.

> > BTW would be nice to have a set of known-to-fail tests, i.e. bugs that
> > are not fixed yet.  If we had it, the above test could be implemented
> > and committed before we have the fix pushed.
> 
> We do! Use test_expect_equal_failure (yes, the name is horrible!)
> instead of test_expect_equal and you should get what you want.
> 

I should look at it, thanks.

Regards,
  Dmitry

> -Carl
> 
> -- 
> carl.d.wo...@intel.com
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH 3/5] Fix hiding a message while some citations are shown in notmuch-show view.

[Dmitry Kurochkin]

On Wed, 25 May 2011 15:46:40 -0700, Carl Worth  wrote:
> On Thu, 26 May 2011 02:34:28 +0400, Dmitry Kurochkin  gmail.com> wrote:
> > I am not sure how it is best to test this.  The common `printc' method
> > for emacs tests does not work, because it prints invisible parts as
> > well.  We need either to find a way to print only visible text on the
> > console, or test it inside emacs somehow.  Any suggestions?
> 
> Unfortunately, I don't have a good plan here. I delayed implementing any
> automated testing at all of the emacs interface precisely because of
> this problem. It's seems to me that surely emacs must have some built-in
> mechanism for copying the visible portion of a block of text, but I've
> not been able to find it.
> 

Me too.

> We could do something cheesy (and slow) by marching through the buffer
> character-by-character in elisp and testing for visibility, but the
> emacs tests are already the slowest part of "make test"[*] so that would
> be obnoxious.
> 

Indeed.

> > Note that this is exactly the patch that hits the isearch emacs bug.  Do
> > I understand correctly that you are ready to push the series despite of
> > it (given that we have a test)?
> 
> Breaking isearch would be really unfortunate. That's a really nice
> feature of the emacs frontend currently.
> 
> So I would notice that breakage, (while I've apparently never before
> noticed the breakage of having visible citations in a hidden message).
> 
> So no, I'm not saying I'm ready to push the series while emacs is broken.
> 

Well, emacs trunk is not broken :)  The bug is in lisp code, so you can
fix it in .emacs by redefining `isearch-range-invisible' function.  I do
that now.

I do not think I will make myself work on the test until it is likely to
be pushed.  I will try to not to forget about it, so sometime later I
may be back to it :)

Please consider pushing other patches from the series.  They do not fix
any bug, but do simplify the code.  The last patch uses list for
invisible overlay property as well.  But it does not break isearch
because we do not search in hidden messages.

BTW would be nice to have a set of known-to-fail tests, i.e. bugs that
are not fixed yet.  If we had it, the above test could be implemented
and committed before we have the fix pushed.

> -Carl
> 
> [*] Maybe the performance of the emacs testing could be significantly
> improved by sharing a single invocation of emacs? Perhaps this wouldn't
> even be hard by just using emacsclient?
> 

This is possible as long as tests do not affect each other.  Would be a
nice improvement.

Regards,
  Dmitry

[PATCH 3/5] Fix hiding a message while some citations are shown in notmuch-show view.

[Dmitry Kurochkin]

On Wed, 25 May 2011 15:23:47 -0700, Carl Worth  wrote:
> On Thu, 26 May 2011 02:10:14 +0400, Dmitry Kurochkin  gmail.com> wrote:
> > Before the change, message and citation invisibility overlays
> > conflicted: if some citation is made visible and then the whole
> > message is hidden, that citation remained visible.
> 
> That sounds like quite a bug. I'd love to see this series also add a
> test case for that.
> 

I am not sure how it is best to test this.  The common `printc' method
for emacs tests does not work, because it prints invisible parts as
well.  We need either to find a way to print only visible text on the
console, or test it inside emacs somehow.  Any suggestions?

Note that this is exactly the patch that hits the isearch emacs bug.  Do
I understand correctly that you are ready to push the series despite of
it (given that we have a test)?

Regards,
  Dmitry

> -Carl
> 
> -- 
> carl.d.worth at intel.com
Non-text part: application/pgp-signature

[PATCH 5/5] Simplify message and headers visibility code in notmuch-show view.

[Dmitry Kurochkin]

Before the change, headers and message visibility functions took
extra care to correctly set `buffer-invisibility-spec'.  This was
needed because headers overlay `invisible' property had only
headers' invisibility spec.  So visibility of headers was
determined only by the headers invisibility spec.  The patch sets
headers overlay `invisible' property a list with both the headers
and the message invisibility spec.  This makes headers invisible
if either of them is added to the `buffer-invisibility-spec' and
allows to simplify the code.
---
 emacs/notmuch-show.el |   18 +-
 1 files changed, 5 insertions(+), 13 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index e1846bc..2f7154e 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -733,8 +733,9 @@ current buffer, if possible."
 ;; message.
 (put-text-property message-start message-end :notmuch-message-extent (cons 
message-start message-end))

-(let ((headers-overlay (make-overlay headers-start headers-end)))
-  (overlay-put headers-overlay 'invisible headers-invis-spec)
+(let ((headers-overlay (make-overlay headers-start headers-end))
+  (invis-specs (list headers-invis-spec message-invis-spec)))
+  (overlay-put headers-overlay 'invisible invis-specs)
   (overlay-put headers-overlay 'priority 10))
 (overlay-put (make-overlay body-start body-end) 'invisible 
message-invis-spec)

@@ -974,20 +975,11 @@ All currently available key bindings:
   (add-to-invisibility-spec spec

 (defun notmuch-show-message-visible (props visible-p)
-  (if visible-p
-  ;; When making the message visible, the headers may or not be
-  ;; visible. So we check that property separately.
-  (let ((headers-visible (plist-get props :headers-visible)))
-   (notmuch-show-element-visible props headers-visible :headers-invis-spec)
-   (notmuch-show-element-visible props t :message-invis-spec))
-(notmuch-show-element-visible props nil :headers-invis-spec)
-(notmuch-show-element-visible props nil :message-invis-spec))
-
+  (notmuch-show-element-visible props visible-p :message-invis-spec)
   (notmuch-show-set-prop :message-visible visible-p props))

 (defun notmuch-show-headers-visible (props visible-p)
-  (if (plist-get props :message-visible)
-  (notmuch-show-element-visible props visible-p :headers-invis-spec))
+  (notmuch-show-element-visible props visible-p :headers-invis-spec)
   (notmuch-show-set-prop :headers-visible visible-p props))

 ;; Functions for setting and getting attributes of the current
-- 
1.7.5.1

[PATCH 4/5] Set higher priority for headers and hidden citation overlays.

[Dmitry Kurochkin]

Before the patch, message, headers and hidden citation overlays
had zero priority.  All these overlay have `invisible' property.
Emacs documentation says that we should not make assumptions
about which overlay will prevail when they have the same priority
[1].  It happens to work as we need, but we should not rely on
undocumented behavior.

[1] http://www.gnu.org/s/emacs/manual/html_node/elisp/Overlay-Properties.html
---
 emacs/notmuch-show.el |4 +++-
 emacs/notmuch-wash.el |1 +
 2 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 34c0b79..e1846bc 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -733,7 +733,9 @@ current buffer, if possible."
 ;; message.
 (put-text-property message-start message-end :notmuch-message-extent (cons 
message-start message-end))

-(overlay-put (make-overlay headers-start headers-end) 'invisible 
headers-invis-spec)
+(let ((headers-overlay (make-overlay headers-start headers-end)))
+  (overlay-put headers-overlay 'invisible headers-invis-spec)
+  (overlay-put headers-overlay 'priority 10))
 (overlay-put (make-overlay body-start body-end) 'invisible 
message-invis-spec)

 ;; Save the properties for this message. Currently this saves the
diff --git a/emacs/notmuch-wash.el b/emacs/notmuch-wash.el
index bd521ba..992fa8f 100644
--- a/emacs/notmuch-wash.el
+++ b/emacs/notmuch-wash.el
@@ -139,6 +139,7 @@ insert before the button, probably for indentation."
 (add-to-invisibility-spec invis-spec)
 (overlay-put overlay 'invisible (list invis-spec message-invis-spec))
 (overlay-put overlay 'isearch-open-invisible 
#'notmuch-wash-region-isearch-show)
+(overlay-put overlay 'priority 10)
 (overlay-put overlay 'type type)
 (goto-char (1+ end))
 (save-excursion
-- 
1.7.5.1

[PATCH 3/5] Fix hiding a message while some citations are shown in notmuch-show view.

[Dmitry Kurochkin]

Before the change, message and citation invisibility overlays
conflicted: if some citation is made visible and then the whole
message is hidden, that citation remained visible.  This happened
because the citation's overlay has an invisible property which
takes priority over the message overlay.  The message
invisibility spec does not affect citation visibility, it is
determined solely by the citation overlay invisibility spec.
Hence, if citation is made visible, it is not hidden by message
invisibility spec.

The patch changes citation overlay invisibility property to be a
list which contains both the citation and the message
invisibility specs.  This makes the citation invisible if either
of them is added to the `buffer-invisibility-spec'.  Note that
all citation visibility states are "restored" when the message
hidden and shown again.
---
 emacs/notmuch-wash.el |   12 +++-
 1 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/emacs/notmuch-wash.el b/emacs/notmuch-wash.el
index 7d87e85..bd521ba 100644
--- a/emacs/notmuch-wash.el
+++ b/emacs/notmuch-wash.el
@@ -107,7 +107,8 @@ collapse the remaining lines into a button.")
   :supertype 'notmuch-wash-button-invisibility-toggle-type)

 (defun notmuch-wash-region-isearch-show (overlay)
-  (remove-from-invisibility-spec (overlay-get overlay 'invisible)))
+  (dolist (invis-spec (overlay-get overlay 'invisible))
+(remove-from-invisibility-spec invis-spec)))

 (defun notmuch-wash-button-label (overlay)
   (let* ((type (overlay-get overlay 'type))
@@ -118,7 +119,7 @@ collapse the remaining lines into a button.")
 (lines-count (count-lines (overlay-start overlay) (overlay-end 
overlay
 (format label-format lines-count)))

-(defun notmuch-wash-region-to-button (beg end type prefix)
+(defun notmuch-wash-region-to-button (msg beg end type prefix)
   "Auxilary function to do the actual making of overlays and buttons

 BEG and END are buffer locations. TYPE should a string, either
@@ -131,11 +132,12 @@ insert before the button, probably for indentation."
   ;; since the newly created symbol has no plist.

   (let ((overlay (make-overlay beg end))
+   (message-invis-spec (plist-get msg :message-invis-spec))
(invis-spec (make-symbol (concat "notmuch-" type "-region")))
(button-type (intern-soft (concat "notmuch-wash-button-"
  type "-toggle-type"
 (add-to-invisibility-spec invis-spec)
-(overlay-put overlay 'invisible invis-spec)
+(overlay-put overlay 'invisible (list invis-spec message-invis-spec))
 (overlay-put overlay 'isearch-open-invisible 
#'notmuch-wash-region-isearch-show)
 (overlay-put overlay 'type type)
 (goto-char (1+ end))
@@ -166,7 +168,7 @@ insert before the button, probably for indentation."
  (goto-char cite-end)
  (forward-line (- notmuch-wash-citation-lines-suffix))
  (notmuch-wash-region-to-button
-  hidden-start (point-marker)
+  msg hidden-start (point-marker)
   "citation" "\n")
   (if (and (not (eobp))
   (re-search-forward notmuch-wash-signature-regexp nil t))
@@ -180,7 +182,7 @@ insert before the button, probably for indentation."
  (set-marker sig-end-marker (point-max))
  (overlay-put (make-overlay sig-start-marker sig-end-marker) 'face 
'message-cited-text)
  (notmuch-wash-region-to-button
-  sig-start-marker sig-end-marker
+  msg sig-start-marker sig-end-marker
   "signature" "\n"))

 ;;
-- 
1.7.5.1

[PATCH 2/5] Set message invisibility spec properties before inserting the body.

[Dmitry Kurochkin]

This would allow body-inserting code (in particular, wash
button-inserting code) to use message invisibility specs.
---
 emacs/notmuch-show.el |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 786debf..34c0b79 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -693,6 +693,9 @@ current buffer, if possible."

 (setq content-start (point-marker))

+(plist-put msg :headers-invis-spec headers-invis-spec)
+(plist-put msg :message-invis-spec message-invis-spec)
+
 ;; Set `headers-start' to point after the 'Subject:' header to be
 ;; compatible with the existing implementation. This just sets it
 ;; to after the first header.
@@ -730,10 +733,7 @@ current buffer, if possible."
 ;; message.
 (put-text-property message-start message-end :notmuch-message-extent (cons 
message-start message-end))

-(plist-put msg :headers-invis-spec headers-invis-spec)
 (overlay-put (make-overlay headers-start headers-end) 'invisible 
headers-invis-spec)
-
-(plist-put msg :message-invis-spec message-invis-spec)
 (overlay-put (make-overlay body-start body-end) 'invisible 
message-invis-spec)

 ;; Save the properties for this message. Currently this saves the
-- 
1.7.5.1

[PATCH 1/5] Pass message to the `notmuch-show-insert-text/plain-hook' hook.

[Dmitry Kurochkin]

Before the change, the `notmuch-show-insert-text/plain-hook' was
given only the `depth' argument.  The patch adds another one -
the message.  Currently, the new message argument is not used by
any on the hooks.  But it will be used later to get access to
message invisibility specs when wash buttons are inserted.
---
 emacs/notmuch-show.el |2 +-
 emacs/notmuch-wash.el |   10 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index bd348e1..786debf 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -531,7 +531,7 @@ current buffer, if possible."
 (save-excursion
   (save-restriction
(narrow-to-region start (point-max))
-   (run-hook-with-args 'notmuch-show-insert-text/plain-hook depth
+   (run-hook-with-args 'notmuch-show-insert-text/plain-hook msg depth
   t)

 (defun notmuch-show-insert-part-text/x-vcalendar (msg part content-type nth 
depth declared-type)
diff --git a/emacs/notmuch-wash.el b/emacs/notmuch-wash.el
index 115c3bb..7d87e85 100644
--- a/emacs/notmuch-wash.el
+++ b/emacs/notmuch-wash.el
@@ -147,7 +147,7 @@ insert before the button, probably for indentation."
 'overlay overlay
 :type button-type

-(defun notmuch-wash-excerpt-citations (depth)
+(defun notmuch-wash-excerpt-citations (msg depth)
   "Excerpt citations and up to one signature."
   (goto-char (point-min))
   (beginning-of-line)
@@ -185,7 +185,7 @@ insert before the button, probably for indentation."

 ;;

-(defun notmuch-wash-elide-blank-lines (depth)
+(defun notmuch-wash-elide-blank-lines (msg depth)
   "Elide leading, trailing and successive blank lines."

   ;; Algorithm derived from `article-strip-multiple-blank-lines' in
@@ -213,7 +213,7 @@ insert before the button, probably for indentation."

 ;;

-(defun notmuch-wash-tidy-citations (depth)
+(defun notmuch-wash-tidy-citations (msg depth)
   "Improve the display of cited regions of a message.

 Perform several transformations on the message body:
@@ -244,7 +244,7 @@ Perform several transformations on the message body:

 ;;

-(defun notmuch-wash-wrap-long-lines (depth)
+(defun notmuch-wash-wrap-long-lines (msg depth)
   "Wrap any long lines in the message to the width of the window.

 When doing so, maintaining citation leaders in the wrapped text."
@@ -263,7 +263,7 @@ When doing so, maintaining citation leaders in the wrapped 
text."

 (defvar diff-file-header-re) ; From `diff-mode.el'.

-(defun notmuch-wash-convert-inline-patch-to-part (depth)
+(defun notmuch-wash-convert-inline-patch-to-part (msg depth)
   "Convert an inline patch into a fake 'text/x-diff' attachment.

 Given that this function guesses whether a buffer includes a
-- 
1.7.5.1

[PATCH] Fix hiding a message while some citations are visible

[Dmitry Kurochkin]

This patch series does some fixes and improvements for hiding and
showing messages in notmuch-show.  However it comes with a
regression: isearch is broken for hidden overlays when
`invisible' property is a list.  I have opened emacs bug #8721
[1] and sent a patch.  It has been committed to emacs trunk
r104356.

I do not know if this should be pushed or wait until emacs with
the fix is released.

Regards,
  Dmitry

[1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8721

[PATCH v2 4/4] emacs: Allow the user to choose the "From" address when replying to a message

[Thomas Jost]

When pressing C-u r, the user will be prompted for the identity to use.
---
 emacs/notmuch-mua.el  |   13 -
 emacs/notmuch-show.el |6 +++---
 emacs/notmuch.el  |6 +++---
 3 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 1b777d9..f2d86bb 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -69,7 +69,7 @@ list."
(push header message-hidden-headers)))
notmuch-mua-hidden-headers))
 
-(defun notmuch-mua-reply (query-string)
+(defun notmuch-mua-reply (query-string &optional sender)
   (let (headers
body
(args '("reply")))
@@ -90,6 +90,9 @@ list."
  (setq headers (mail-header-extract)
   (forward-line 1)
   (setq body (buffer-substring (point) (point-max
+;; If sender is non-nil, set the From: header to its value.
+(when sender
+  (mail-header-set 'from sender headers))
 (let
;; Overlay the composition window on that being used to read
;; the original message.
@@ -191,6 +194,14 @@ the From: address first."
(notmuch-mua-forward-message))
 (notmuch-mua-forward-message)))
 
+(defun notmuch-mua-new-reply (query-string &optional prompt-for-sender)
+  "Invoke the notmuch reply window."
+  (interactive "P")
+  (let ((sender
+(when prompt-for-sender
+  (notmuch-mua-prompt-for-sender
+(notmuch-mua-reply query-string sender)))
+
 (defun notmuch-mua-send-and-exit (&optional arg)
   (interactive "P")
   (message-send-and-exit arg))
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 7e493e9..1c5dfd7 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -1153,10 +1153,10 @@ any effects from previous calls to
   ;; Move to the previous message.
   (notmuch-show-previous-message)
 
-(defun notmuch-show-reply ()
+(defun notmuch-show-reply (&optional prompt-for-sender)
   "Reply to the current message."
-  (interactive)
-  (notmuch-mua-reply (notmuch-show-get-message-id)))
+  (interactive "P")
+  (notmuch-mua-new-reply (notmuch-show-get-message-id) prompt-for-sender))
 
 (defun notmuch-show-forward-message (&optional prompt-for-sender)
   "Forward the current message."
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 21e0314..3d984bc 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -442,11 +442,11 @@ Complete list of currently available key bindings:
  crypto-switch)
   (error "End of search results"
 
-(defun notmuch-search-reply-to-thread ()
+(defun notmuch-search-reply-to-thread (&optional prompt-for-sender)
   "Begin composing a reply to the entire current thread in a new buffer."
-  (interactive)
+  (interactive "P")
   (let ((message-id (notmuch-search-find-thread-id)))
-(notmuch-mua-reply message-id)))
+(notmuch-mua-new-reply message-id prompt-for-sender)))
 
 (defun notmuch-call-notmuch-process (&rest args)
   "Synchronously invoke \"notmuch\" with the given list of arguments.
-- 
1.7.5.1

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

[PATCH v2 3/4] emacs: Allow the user to choose the "From" address when forwarding a message

[Thomas Jost]

When pressing C-u f, the user will be prompted for the identity to use.
---
 emacs/notmuch-mua.el  |   14 ++
 emacs/notmuch-show.el |6 +++---
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 74c9fc1..1b777d9 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -177,6 +177,20 @@ the From: address first."
   (list (cons 'from (notmuch-mua-prompt-for-sender))
 (notmuch-mua-mail nil nil other-headers)))
 
+(defun notmuch-mua-new-forward-message (&optional prompt-for-sender)
+  "Invoke the notmuch message forwarding window.
+
+If PROMPT-FOR-SENDER is non-nil, the user will be prompted for
+the From: address first."
+  (interactive "P")
+  (if prompt-for-sender
+  (let* ((sender (notmuch-mua-prompt-for-sender))
+(address-components (mail-extract-address-components sender))
+(user-full-name (car address-components))
+(user-mail-address (cadr address-components)))
+   (notmuch-mua-forward-message))
+(notmuch-mua-forward-message)))
+
 (defun notmuch-mua-send-and-exit (&optional arg)
   (interactive "P")
   (message-send-and-exit arg))
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 48d2926..7e493e9 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -1158,11 +1158,11 @@ any effects from previous calls to
   (interactive)
   (notmuch-mua-reply (notmuch-show-get-message-id)))
 
-(defun notmuch-show-forward-message ()
+(defun notmuch-show-forward-message (&optional prompt-for-sender)
   "Forward the current message."
-  (interactive)
+  (interactive "P")
   (with-current-notmuch-show-message
-   (notmuch-mua-forward-message)))
+   (notmuch-mua-new-forward-message prompt-for-sender)))
 
 (defun notmuch-show-next-message ()
   "Show the next message."
-- 
1.7.5.1

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

[PATCH v2 2/4] emacs: Allow the user to choose the "From" address when composing a new message

[Thomas Jost]

When pressing C-u m, the user will be prompted for the identity to use.
---
 emacs/notmuch-hello.el |2 +-
 emacs/notmuch-mua.el   |   11 +++
 emacs/notmuch-show.el  |2 +-
 emacs/notmuch.el   |2 +-
 4 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index e58dd24..ab06d3a 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -298,7 +298,7 @@ should be. Returns a cons cell `(tags-per-line width)'."
 (define-key map "=" 'notmuch-hello-update)
 (define-key map "G" 'notmuch-hello-poll-and-update)
 (define-key map (kbd "") 'widget-backward)
-(define-key map "m" 'notmuch-mua-mail)
+(define-key map "m" 'notmuch-mua-new-mail)
 (define-key map "s" 'notmuch-hello-goto-search)
 map)
   "Keymap for \"notmuch hello\" buffers.")
diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 2baf6bd..74c9fc1 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -166,6 +166,17 @@ name and addresses configured in the notmuch configuration 
file."
 (ido-completing-read "Send mail From: " collection
 nil 'confirm nil 'notmuch-mua-sender-history (car 
collection
 
+(defun notmuch-mua-new-mail (&optional prompt-for-sender)
+  "Invoke the notmuch mail composition window.
+
+If PROMPT-FOR-SENDER is non-nil, the user will be prompted for
+the From: address first."
+  (interactive "P")
+  (let ((other-headers
+(when prompt-for-sender
+  (list (cons 'from (notmuch-mua-prompt-for-sender))
+(notmuch-mua-mail nil nil other-headers)))
+
 (defun notmuch-mua-send-and-exit (&optional arg)
   (interactive "P")
   (message-send-and-exit arg))
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 825988c..48d2926 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -847,7 +847,7 @@ function is used. "
(define-key map (kbd "") 'notmuch-show-previous-button)
(define-key map (kbd "TAB") 'notmuch-show-next-button)
(define-key map "s" 'notmuch-search)
-   (define-key map "m" 'notmuch-mua-mail)
+   (define-key map "m" 'notmuch-mua-new-mail)
(define-key map "f" 'notmuch-show-forward-message)
(define-key map "r" 'notmuch-show-reply)
(define-key map "|" 'notmuch-show-pipe-message)
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 1d683f8..21e0314 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -204,7 +204,7 @@ For a mouse binding, return nil."
 (define-key map "p" 'notmuch-search-previous-thread)
 (define-key map "n" 'notmuch-search-next-thread)
 (define-key map "r" 'notmuch-search-reply-to-thread)
-(define-key map "m" 'notmuch-mua-mail)
+(define-key map "m" 'notmuch-mua-new-mail)
 (define-key map "s" 'notmuch-search)
 (define-key map "o" 'notmuch-search-toggle-order)
 (define-key map "c" 'notmuch-search-stash-map)
-- 
1.7.5.1

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

[PATCH v2 1/4] emacs: Helpers needed for the user to be able to choose the "From" address when composing a new message

[Thomas Jost]

This adds functions and variables needed for this feature to be implemented.
Once it's done, the user will be able to use a prefix argument (e.g. pressing
C-u m instead of m) and be able to select a From address.

By default the list of names/addresses to be used during completion will be
automatically generated by the settings in the notmuch configuration file. The
user can customize the notmuch-identities variable to provide an alternate list.

This is based on a previous patch by Carl Worth
(id:"87wrhfvk6a@yoom.home.cworth.org" and follow-ups).
---
 emacs/notmuch-mua.el |   23 +++
 1 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 003b313..2baf6bd 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -143,6 +143,29 @@ list."
 
   (message-goto-to))
 
+(defcustom notmuch-identities nil
+  "Identities that can be used as the From: address when composing a new 
message.
+
+If this variable is left unset, then a list will be constructed from the
+name and addresses configured in the notmuch configuration file."
+  :group 'notmuch
+  :type '(repeat string))
+
+(defun notmuch-mua-sender-collection ()
+  (if notmuch-identities
+  notmuch-identities
+(mapcar (lambda (address)
+ (concat (notmuch-user-name) " <" address ">"))
+   (cons (notmuch-user-primary-email) (notmuch-user-other-email)
+
+(defvar notmuch-mua-sender-history nil)
+
+(defun notmuch-mua-prompt-for-sender ()
+  (interactive)
+  (let ((collection (notmuch-mua-sender-collection)))
+(ido-completing-read "Send mail From: " collection
+nil 'confirm nil 'notmuch-mua-sender-history (car 
collection
+
 (defun notmuch-mua-send-and-exit (&optional arg)
   (interactive "P")
   (message-send-and-exit arg))
-- 
1.7.5.1

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

Re: [PATCH] emacs: Allow user to choose "From" address when composing a new message.

[Thomas Jost]

On Wed, 25 May 2011 15:17:05 -0700, Carl Worth  wrote:
> > I'll also send a few additional patches that make it possible to choose
> > the "From" address when forwarding a message and when replying to a
> > message.
> 
> The only real concern I have with the series is that it grabs 'R' for
> reply-with-custom-from where I've been planning to implement 'R' as
> reply-to-sender-only, (a long-missing and often-requested feature).

That would be nice indeed :)

> When I first started implementing the custom-from feature I planned to
> use a prefix argument to get the behavior (such as "C-u m" rather than
> "M" for compose-new-mail-with-custom-from). You might even see I've got
> some code written along those lines.

Good idea, this will probably seem more natural for Emacs users.

> When I went to test it though, it didn't work. That was probably some
> silly mistake on my part, (we do already have working code that changes
> behavior with a prefix argument in the case of "M-RET" for example).
> 
> If you want to update the series to move away from capital-letter
> keybindings in favor of a prefix argument, I'll be glad to accept it.

Done and tested locally, seems OK so far. This makes the code smaller
and IMHO nicer because it eliminates all the -prompt-for-sender
variants. I'll send the updated patch series very soon.

Thanks,

-- 
Thomas/Schnouki


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

one-time-iterators

[Patrick Totzke]

Hi!

I'm playing around with one-time iterators Threads in the python bindings
in combination with changes to the database.
Particularly, I'd like to iterate over a list of threads partially,
change the tags of a single thread and afterwards continue iterating.
Of course I get "Xapian DB-changed" exceptions.
As I see it, there are two possible solutions:
First, I iterate over all the threads and cache all the info i'd like to 
extract from each one (or just the id and re-query the info on demand).
The problem here is, that this list of thread-ids might be huge and
caching it will block my code.
Secondly, I could replace the iterator i'm using with a fresh one after 
db-changes. But then I'd need some magic that discards an initial
portion of the (fresh) iteration and/or updates the pre-db-change
partial iteration.

Wow. This reads really complicated. All I want to say is:
if I change tags in my search-results view, I get Xapian errors :)
The question: How do you solve this in the emacs code?
do you store all tids of a query? 

Thanks,
/p



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

[PATCH] emacs: Make the queries used in the all-tags section

[Daniel Schoepe]

On Wed, 25 May 2011 18:42:30 -0400, Austin Clements  wrote:
> 'Doh.  That's what I get for not reading the surrounding code.  I
> misunderstood what your patch was going for and assumed it was what
> *I* wanted notmuch to do, which is to show me useful counts (e.g.,
> unread count), but not to change the underlying query.  ]:--8)

I thought about that too, but figured it should be rather rare that
someone wants only a portion of some messages _counted_, but all
displayed when clicking on the search next to the count.

I'm somewhat indifferent, since I rarely use those links
directly, so any more opinions on this are very much appreciated.

> So, to me, it seems like this turns the all tags section into another
> saved searches section, just with a slight twist, and makes me wonder
> if there's a better way to reconcile these.

Well, it already was sort of a non-configurable saved searches section
before, so I didn't really turn it into one. :)

Since the main difference between those sections is the clear visual
distinction, it might be an option to provide the user with functions to
easily declare new sections for the hello screen, where this sort of
thing is configurable. (One possible use that comes to mind would be to
group tags into different categories.)
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110526/1e633f8f/attachment.pgp>