On Fri, Nov 09 2012, Mark Walters wrote:
>
> This patch series implements the above mentioned solution and seems to
> work except for one problem.
>
> Since emacs now tags each message in a thread in the search buffer it
> is easy to ask it to tag a lot of messages. This could be done
>
Mark Walters writes:
> I can think of several possible solutions (e.g., batch it in my new
> stuff, put some batching in notmuch-tag, all notmuch tag to read a
> query from stdin). But before any larger more intrusive change do
> people like the general approach? Does anyone have a good way to
This makes emacs use the new --output=with-ids in search mode and use
this for tagging. This fixes the race condition in tagging from
search mode so mark the tests fixed.
---
emacs/notmuch.el | 22 --
test/emacs |2 --
2 files changed, 20 insertions(+), 4
This adds a --output=with-ids option which gives similar output to the
normal search summary output but with a list of message ids
too. Currently this is not implemented for text format.
---
notmuch-search.c | 40 ++--
1 files changed, 38 insertions(+), 2
When tagging from search view in emacs there is a race condition: it
tags all messages in the thread even ones which arrived after the
search was made. This can cause dataloss (if, for example, a thread is
archived it could archive messages the user has never seen).
Mark this test known broken.
For a long time [1] there have been two related races in tagging from
the search buffer.
The first is that when tagging (including archiving) a thread message
which arrived after the buffer was created may also be tagged. This is
because the tagging is done based on the thread-id not on the
Quoth Mark Walters on Nov 01 at 7:26 pm:
> If the user pressed return on the end result status line it gave a
> blank message. Modify the function notmuch-pick-get-message-id to
> return nil rather than an empty message-id in this case to fix this.
> ---
> contrib/notmuch-pick/notmuch-pick.el |
On Fri, Nov 09 2012, David Bremner wrote:
> Mark Walters writes:
>
>> - (concat "id:\"" (notmuch-pick-get-prop :id) "\""))
>> + (let ((id (notmuch-pick-get-prop :id)))
>> +(when id
>> + (concat "id:\"" id "\""
>
> I don't know how other people feel, but I'd rather have an `if' in
Hi Ondrej,
Quoting Ondrej Jombik (2012-11-09 02:58:09)
> I am trying to move from mairix to some better solution. mairix has been
> working really well for me, but it had some limitations.
>
> I decided to give a try to notmuch, but I has been suprised with
> estimated indexing time:
>
>
Tomi Ollila writes:
> Does (when COND BODY) connotate to the thought that the return value
> is generally not used ? That expands to (if COND (progn BODY)) so both
> returns exactly same values.
Err, sorry. Too much scheme. I meant a two branch if
(if COND BODY nil)
I am trying to move from mairix to some better solution. mairix has been
working really well for me, but it had some limitations.
I decided to give a try to notmuch, but I has been suprised with
estimated indexing time:
Processed 4157 of 822462 files (10h 3m 42s remaining).
At the
On Fri, Nov 09 2012, David Bremner da...@tethera.net wrote:
Mark Walters markwalters1...@gmail.com writes:
- (concat id:\ (notmuch-pick-get-prop :id) \))
+ (let ((id (notmuch-pick-get-prop :id)))
+(when id
+ (concat id:\ id \
I don't know how other people feel, but I'd
Hi Ondrej,
Quoting Ondrej Jombik (2012-11-09 02:58:09)
I am trying to move from mairix to some better solution. mairix has been
working really well for me, but it had some limitations.
I decided to give a try to notmuch, but I has been suprised with
estimated indexing time:
Tomi Ollila tomi.oll...@iki.fi writes:
Does (when COND BODY) connotate to the thought that the return value
is generally not used ? That expands to (if COND (progn BODY)) so both
returns exactly same values.
Err, sorry. Too much scheme. I meant a two branch if
(if COND BODY nil)
Quoth Mark Walters on Nov 01 at 7:26 pm:
If the user pressed return on the end result status line it gave a
blank message. Modify the function notmuch-pick-get-message-id to
return nil rather than an empty message-id in this case to fix this.
---
contrib/notmuch-pick/notmuch-pick.el |4
When tagging from search view in emacs there is a race condition: it
tags all messages in the thread even ones which arrived after the
search was made. This can cause dataloss (if, for example, a thread is
archived it could archive messages the user has never seen).
Mark this test known broken.
For a long time [1] there have been two related races in tagging from
the search buffer.
The first is that when tagging (including archiving) a thread message
which arrived after the buffer was created may also be tagged. This is
because the tagging is done based on the thread-id not on the
This makes emacs use the new --output=with-ids in search mode and use
this for tagging. This fixes the race condition in tagging from
search mode so mark the tests fixed.
---
emacs/notmuch.el | 22 --
test/emacs |2 --
2 files changed, 20 insertions(+), 4
On Fri, Nov 09 2012, Mark Walters markwalters1...@gmail.com wrote:
This patch series implements the above mentioned solution and seems to
work except for one problem.
Since emacs now tags each message in a thread in the search buffer it
is easy to ask it to tag a lot of messages. This could
Mark Walters markwalters1...@gmail.com writes:
I can think of several possible solutions (e.g., batch it in my new
stuff, put some batching in notmuch-tag, all notmuch tag to read a
query from stdin). But before any larger more intrusive change do
people like the general approach? Does anyone
Quoth Mark Walters on Nov 09 at 6:58 pm:
For a long time [1] there have been two related races in tagging from
the search buffer.
The first is that when tagging (including archiving) a thread message
which arrived after the buffer was created may also be tagged. This is
because the tagging
21 matches
Mail list logo
