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
> individua
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 ta
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 ge
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 deletions
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 dele
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
indivi
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 ge
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
> individua
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 |
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 deletions
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 dele
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
indivi
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.
--
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
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 |
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:
>
> Pr
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)
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 beggining
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:
>
> Pr
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
22 matches
Mail list logo