On Sat, 10 Apr 2010 15:56:48 +0200, Xavier Maillard <xma@gnu.org> wrote: > On Tue, 6 Apr 2010 13:51:01 -0600, Mark Anderson <MarkR.Anderson@amd.com> wrote: > > > > I think that '*' is definitely an awesome command, but I wonder if we > > shouldn't have another command for the notmuch-search buffer which means > > 'tag all the threads that I can see in this buffer'. > > This is exactly what my initial post asked for. '*' is not > totally satisfying for me due to the "limitations" you > exposed. Though It is a good and acceptable workaround for me. > As said, I just have to pay attention to redo my search query > before pressing the '*' key. The other bug with "*" is that it doesn't give any visual feedback, (the tag addition/deletion doesn't show up). We could fix all[*] the bugs of "*" by changing it to simply call the new region-based tagging function. The only concern I have with that is that it might be significantly slower, (it will execute N "notmuch tag" commands to tag the N threads in the current buffer, rather than just one "notmuch tag" command with the same search). But the command-line based "notmuch tag +/-<tag> <search>" will always still be available for true "bulk" tagging, so maybe having "*" in emacs be implemented the slower way would be fine. I think the biggest concern I have with the performance is that if it *is* too slow, then the user might interrupt it with emacs, and with the current implementation that would lead to inconsistent display. That's not specific to "*" though---that's a bug with the current region-based implementation---it's just that "*" might make it much easier to hit. -Carl [*] Most all the bugs, at least. Even just a simple 'a' (or '+' or '-') on a single thread is already doing something subtly different than it should. It's tagging all messages in the thread, but that might be more messages than existed when the thread-summary was created. So you might see: [1/1] A. Bozo Boring topic... and decide to archive the thread, and never realize that what you archived away was several messages that would have been displayed as: [3/3] A Bozo, B Wizard, C Wizard Boring topic... [**] if you had only refreshed first. So we really should fix that bug and only manipulate messages that were actually present when the search was performed. Note that 'a' inside of the show view does not have this bug---it does only affect messages displayed. I'm not currently afflicted by this bug only because I'm running "notmuch new" manually, before mail-reading sessions as opposed to inside a cron-job or similar. [**] This is similar to the "thread pattern" idea described by Joey Hess here: http://kitenet.net/~joey/blog/entry/thread_patterns/ Our current one-line presentation of threads does a really lousy job of letting the user see thread patterns like this. We should perhaps come up with something better. One "something better" I have in mind would be the ability to write searches that could identify and tag threads according to these patterns. Our current search syntax isn't powerful enough to express these kinds of relations about messages within threads, but I would be very interested in coming up with something that does. The parts that Xapian can't easily support here probably wouldn't have to be fast either---they could operate on the results of threads, which are generally "small". At least, I hope nobody has threads with hundreds of thousands of messages in them.