Re: Race condition for '*' command
On Sun, 26 Jun 2011 10:00:41 +0100, Robin Green gree...@greenrd.org wrote:
On Sat, 25 Jun 2011 16:57:50 -0700, Jameson Graef Rollins
jroll...@finestructure.net wrote:
On Sat, 25 Jun 2011 23:18:52 +0100, Robin Green gree...@greenrd.org wrote:
A race condition in the '*' command was noted when it was first
proposed. It looks to me like it still exists - has anything been done
about it?
Hi, Robin. Can you explain what you mean by the '*' command?
Sorry - forgot to say I'm talking about the notmuch emacs mode. In that
mode '*' applies tags to all messages matching the current search query,
which means that (here's the race condition) new results that have
appeared since the last refresh will also be tagged.
This issue appears to stem from the fact that `notmuch-search-operate-all'
runs (apply 'notmuch-tag notmuch-search-query-string action-split), in which
`notmuch-search-query-string' points to a moving target.
Could be solved by doing it with `notmuch-search', `mark-whole-buffer'
and `notmuch-search-{add,remove}-tag-region' instead, but I'm sure
there's a better way (of which I'm as of yet unaware).
--
Robin
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Peace
--
Pieter
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: Race condition for '*' command
On Tue, 28 Jun 2011 08:49:06 +0200, Pieter Praet pie...@praet.org wrote:
On Sun, 26 Jun 2011 10:00:41 +0100, Robin Green gree...@greenrd.org wrote:
On Sat, 25 Jun 2011 16:57:50 -0700, Jameson Graef Rollins
jroll...@finestructure.net wrote:
On Sat, 25 Jun 2011 23:18:52 +0100, Robin Green gree...@greenrd.org
wrote:
A race condition in the '*' command was noted when it was first
proposed. It looks to me like it still exists - has anything been done
about it?
Hi, Robin. Can you explain what you mean by the '*' command?
Sorry - forgot to say I'm talking about the notmuch emacs mode. In that
mode '*' applies tags to all messages matching the current search query,
which means that (here's the race condition) new results that have
appeared since the last refresh will also be tagged.
This issue appears to stem from the fact that `notmuch-search-operate-all'
runs (apply 'notmuch-tag notmuch-search-query-string action-split), in which
`notmuch-search-query-string' points to a moving target.
Could be solved by doing it with `notmuch-search', `mark-whole-buffer'
and `notmuch-search-{add,remove}-tag-region' instead, but I'm sure
there's a better way (of which I'm as of yet unaware).
I don't think there's a better way, the results which the user is
viewing is the only visual reference for what the action they intend to
apply will use as the object of said action. I can imagine some people
wanting to have a way to apply an action to a live query string, but I
distinguish between these people and normal humans reading their email.
I expect that when a normal human is reading their email, they do not
intend to apply actions to messages as yet unseen.
I can see some people using the '*' notmuch emacs command as a very
interactive notmuch-poll.sh script. But I imagine the principle of
least surprise would be to have '*' only apply to visible messages, and
if the buffer is old, the buffer is the only record of what is being
viewed.
-Mark
--
Robin
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Peace
--
Pieter
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: Race condition for '*' command
On Tue, 28 Jun 2011 11:36:10 -0600, Mark Anderson ma.sk...@gmail.com wrote:
On Tue, 28 Jun 2011 08:49:06 +0200, Pieter Praet pie...@praet.org wrote:
On Sun, 26 Jun 2011 10:00:41 +0100, Robin Green gree...@greenrd.org wrote:
On Sat, 25 Jun 2011 16:57:50 -0700, Jameson Graef Rollins
jroll...@finestructure.net wrote:
On Sat, 25 Jun 2011 23:18:52 +0100, Robin Green gree...@greenrd.org
wrote:
A race condition in the '*' command was noted when it was first
proposed. It looks to me like it still exists - has anything been done
about it?
Not much. I did add this note to notmuch/TODO at the time:
Fix '*' to work by simply calling '+' or '-' on a region
consisting of the entire buffer
Could be solved by doing it with `notmuch-search', `mark-whole-buffer'
and `notmuch-search-{add,remove}-tag-region' instead, but I'm sure
there's a better way (of which I'm as of yet unaware).
That's a more concrete description of the same idea.
I did some experiments at one point and determined that doing this would
make '*' far too painful to be usable with large search-result buffers,
(which is precisely when I am most likely to use it).
But even if we were willing to accept the performance penalty, (or if we
fixed notmuch-search-*-tag-region to accumulate the thread IDs and make
a single invocation of notmuch to avoid the performance penalty). Even
then, there would still be race conditions here, (though more subtle
than the current race).
At that point we would only be acting on threads that matched the
original search, but we could be acting on more messages than were
originally presented to the user.
For example, a thread might have been displayed as having only one post,
but the * -inbox operation would remove the inbox tag from any replies
received in the interim.
I'd love to find some clean solutions here, as I would love notmuch to
offer an interface that is free of these race conditions, (which are
scary since they can prevent a user from seeing some mail).
Personally, I'm avoiding all races right now by only running notmuch
new manually, (and not otherwise interacting with notmuch while
notmuch new is running). This does avoid the races, but is fairly
awkward, (I have to manually run this (or use the annoyingly blocking
'G'[*] binding), so I would prefer the ability to have new mail
incorporated automatically as it arrives.
Independent of this particular race condition, having something like
fetchmail automatically invoke notmuch new also has the potential to
break your mail client with Xapian Database-modified exceptions.
So we do need some more direct support for this mode of operation.
In the meantime, I've at least updated the TODO note a bit:
Fix '*' to work by simply calling '+' or '-' on a region
consisting of the entire buffer, (this would avoid one race
condition---while still leaving other race conditions---but
could also potentially make '*' a very expensive operation).
-Carl
[*] notmuch-search-poll-and-refresh-view
--
carl.d.wo...@intel.com
pgpD2u5aqQbMs.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: Race condition for '*' command
On Sat, 25 Jun 2011 16:57:50 -0700, Jameson Graef Rollins jroll...@finestructure.net wrote: On Sat, 25 Jun 2011 23:18:52 +0100, Robin Green gree...@greenrd.org wrote: A race condition in the '*' command was noted when it was first proposed. It looks to me like it still exists - has anything been done about it? Hi, Robin. Can you explain what you mean by the '*' command? Sorry - forgot to say I'm talking about the notmuch emacs mode. In that mode '*' applies tags to all messages matching the current search query, which means that (here's the race condition) new results that have appeared since the last refresh will also be tagged. -- Robin ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Race condition for '*' command
On Sat, 25 Jun 2011 23:18:52 +0100, Robin Green gree...@greenrd.org wrote: A race condition in the '*' command was noted when it was first proposed. It looks to me like it still exists - has anything been done about it? Hi, Robin. Can you explain what you mean by the '*' command? Are you referring to '*' as a search term? It's not a command, but it's the only place I know of where notmuch uses the '*' character. Can you explain in a little more detail what exactly your issue is? jamie. pgpYWw8fuh4wA.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
