On Mon, 09 Jan 2012 08:41:15 +, Jani Nikula wrote:
> On Sun, 8 Jan 2012 20:12:59 -0500, Austin Clements
> wrote:
> > Quoth Aaron Ecay on Jan 08 at 7:56 pm:
> > > On Thu, 05 Jan 2012 22:32:16 +0200, Jani Nikula
> > > wrote:
> > >
> > > [...]
> > >
> > > > In the show view it only modifie
> There's been quite a bit of discussion on fixing this properly. See,
> for example
> id:"CAH-f9WsPj=1Eu=g3sOePJgCTBFs6HrLdLq18xMEnJ8aZ00yCEg at mail.gmail.com".
> The gist is that we need to include message IDs (or document IDs) in
> the search output and use these in tagging operations, rather
On Mon, 09 Jan 2012 12:38:58 +0200, Tomi Ollila wrote:
> > The downside is that there's still a race condition: you could get new
> > messages between checking the number of messages in the thread and
> > tagging. The window for error would be much smaller than now, but it's
> > still there. (You
On Sun, 8 Jan 2012 20:12:59 -0500, Austin Clements wrote:
> Quoth Aaron Ecay on Jan 08 at 7:56 pm:
> > On Thu, 05 Jan 2012 22:32:16 +0200, Jani Nikula wrote:
> >
> > [...]
> >
> > > In the show view it only modifies the messages that are currently
> > > visible. This is to make sure you don't
On Sun, 8 Jan 2012 20:12:59 -0500, Austin Clements wrote:
> ... so we need to switch Emacs over to using the JSON search format
> first.
Is anyone working on this? I made an attempt ages ago[1], but have not kept
it working.
Footnotes:
[1] id:"1291114825-3513-1-git-send-email-dme at dme.org"
-
> There's been quite a bit of discussion on fixing this properly. See,
> for example
> id:"CAH-f9WsPj=1Eu=g3soepjgctbfs6hrldlq18xmenj8az00y...@mail.gmail.com".
> The gist is that we need to include message IDs (or document IDs) in
> the search output and use these in tagging operations, rather th
On Mon, 09 Jan 2012 12:38:58 +0200, Tomi Ollila wrote:
> > The downside is that there's still a race condition: you could get new
> > messages between checking the number of messages in the thread and
> > tagging. The window for error would be much smaller than now, but it's
> > still there. (You
On Mon, 09 Jan 2012 08:41:15 +, Jani Nikula wrote:
> On Sun, 8 Jan 2012 20:12:59 -0500, Austin Clements wrote:
> > Quoth Aaron Ecay on Jan 08 at 7:56 pm:
> > > On Thu, 05 Jan 2012 22:32:16 +0200, Jani Nikula wrote:
> > >
> > > [...]
> > >
> > > > In the show view it only modifies the mess
On Sun, 8 Jan 2012 20:12:59 -0500, Austin Clements wrote:
> Quoth Aaron Ecay on Jan 08 at 7:56 pm:
> > On Thu, 05 Jan 2012 22:32:16 +0200, Jani Nikula wrote:
> >
> > [...]
> >
> > > In the show view it only modifies the messages that are currently
> > > visible. This is to make sure you don't
On Sun, 8 Jan 2012 20:12:59 -0500, Austin Clements wrote:
> ... so we need to switch Emacs over to using the JSON search format
> first.
Is anyone working on this? I made an attempt ages ago[1], but have not kept
it working.
Footnotes:
[1] id:"1291114825-3513-1-git-send-email-...@dme.org"
pg
Quoth Aaron Ecay on Jan 08 at 7:56 pm:
> On Thu, 05 Jan 2012 22:32:16 +0200, Jani Nikula wrote:
>
> [...]
>
> > In the show view it only modifies the messages that are currently
> > visible. This is to make sure you don't accidentally archive things that
> > have arrived after refreshing the bu
On Thu, 05 Jan 2012 22:32:16 +0200, Jani Nikula wrote:
[...]
> In the show view it only modifies the messages that are currently
> visible. This is to make sure you don't accidentally archive things that
> have arrived after refreshing the buffer. I think this is safest.
Hmm. Perhaps it would
Quoth Aaron Ecay on Jan 08 at 7:56 pm:
> On Thu, 05 Jan 2012 22:32:16 +0200, Jani Nikula wrote:
>
> [...]
>
> > In the show view it only modifies the messages that are currently
> > visible. This is to make sure you don't accidentally archive things that
> > have arrived after refreshing the bu
On Thu, 05 Jan 2012 22:32:16 +0200, Jani Nikula wrote:
[...]
> In the show view it only modifies the messages that are currently
> visible. This is to make sure you don't accidentally archive things that
> have arrived after refreshing the buffer. I think this is safest.
Hmm. Perhaps it would
On Thu, 05 Jan 2012 22:58:30 +0200, Jani Nikula wrote:
> On Thu, 05 Jan 2012 12:38:18 -0800, Jameson Graef Rollins finestructure.net> wrote:
> > On Thu, 05 Jan 2012 22:32:16 +0200, Jani Nikula wrote:
> > > In the search view it does exactly this.
> >
> > I worry about race conditions in this ca
On Thu, 05 Jan 2012 22:58:30 +0200, Jani Nikula wrote:
> On Thu, 05 Jan 2012 12:38:18 -0800, Jameson Graef Rollins
> wrote:
> > On Thu, 05 Jan 2012 22:32:16 +0200, Jani Nikula wrote:
> > > In the search view it does exactly this.
> >
> > I worry about race conditions in this case, though. I f
On Thu, 05 Jan 2012 12:38:18 -0800, Jameson Graef Rollins wrote:
> On Thu, 05 Jan 2012 22:32:16 +0200, Jani Nikula wrote:
> > In the search view it does exactly this.
>
> I worry about race conditions in this case, though. I frequently
> archive threads after I've read everything, but I still w
On Thu, 05 Jan 2012 15:10:33 -0500, Aaron Ecay wrote:
> On Tue, 3 Jan 2012 20:29:06 +0200, Jani Nikula wrote:
> > Optimize thread archiving by combining all the -inbox tagging operations to
> > a single "notmuch tag" call.
>
> Perhaps I?m missing something, but is there anything preventing emac
On Tue, 3 Jan 2012 20:29:06 +0200, Jani Nikula wrote:
> Optimize thread archiving by combining all the -inbox tagging operations to
> a single "notmuch tag" call.
Perhaps I?m missing something, but is there anything preventing emacs
from just doing the following?
notmuch tag -inbox thread:000wh
On Thu, 05 Jan 2012 12:38:18 -0800, Jameson Graef Rollins
wrote:
> On Thu, 05 Jan 2012 22:32:16 +0200, Jani Nikula wrote:
> > In the search view it does exactly this.
>
> I worry about race conditions in this case, though. I frequently
> archive threads after I've read everything, but I still
On Thu, 05 Jan 2012 22:32:16 +0200, Jani Nikula wrote:
> In the search view it does exactly this.
I worry about race conditions in this case, though. I frequently
archive threads after I've read everything, but I still want to know if
new message to that thread come in. If I attempt to archive
On Thu, 05 Jan 2012 22:32:16 +0200, Jani Nikula wrote:
> In the search view it does exactly this.
I worry about race conditions in this case, though. I frequently
archive threads after I've read everything, but I still want to know if
new message to that thread come in. If I attempt to archive
On Thu, 05 Jan 2012 15:10:33 -0500, Aaron Ecay wrote:
> On Tue, 3 Jan 2012 20:29:06 +0200, Jani Nikula wrote:
> > Optimize thread archiving by combining all the -inbox tagging operations to
> > a single "notmuch tag" call.
>
> Perhaps I’m missing something, but is there anything preventing emac
On Tue, 3 Jan 2012 20:29:06 +0200, Jani Nikula wrote:
> Optimize thread archiving by combining all the -inbox tagging operations to
> a single "notmuch tag" call.
Perhaps I’m missing something, but is there anything preventing emacs
from just doing the following?
notmuch tag -inbox thread:000wh
On Tue, 3 Jan 2012 20:29:06 +0200, Jani Nikula wrote:
> Optimize thread archiving by combining all the -inbox tagging operations to
> a single "notmuch tag" call. Also skip redisplay of tag changes in current
> buffer, as it is immediately killed by the archiving functions.
>
> For threads in th
On Tue, 3 Jan 2012 20:29:06 +0200, Jani Nikula wrote:
> Optimize thread archiving by combining all the -inbox tagging operations to
> a single "notmuch tag" call. Also skip redisplay of tag changes in current
> buffer, as it is immediately killed by the archiving functions.
>
> For threads in th
This seems like a good idea.
On Tue, 3 Jan 2012 20:29:06 +0200, Jani Nikula wrote:
> On the downside, IIRC Xapian does not perform very well if the query
> (in this case a lot of message-ids OR'd together) is very big. It is
> unknown to me at which point this approach would become slower than
>
This seems like a good idea.
On Tue, 3 Jan 2012 20:29:06 +0200, Jani Nikula wrote:
> On the downside, IIRC Xapian does not perform very well if the query
> (in this case a lot of message-ids OR'd together) is very big. It is
> unknown to me at which point this approach would become slower than
>
Optimize thread archiving by combining all the -inbox tagging operations to
a single "notmuch tag" call. Also skip redisplay of tag changes in current
buffer, as it is immediately killed by the archiving functions.
For threads in the order of tens or a hundred inbox tagged messages, this
gives a n
Optimize thread archiving by combining all the -inbox tagging operations to
a single "notmuch tag" call. Also skip redisplay of tag changes in current
buffer, as it is immediately killed by the archiving functions.
For threads in the order of tens or a hundred inbox tagged messages, this
gives a n
30 matches
Mail list logo