* [sup-talk] [PATCH] (Double/guarded) keypress to show all threads @ 2008-01-11 17:20 Marcus Williams 2008-01-13 5:30 ` William Morgan 0 siblings, 1 reply; 11+ messages in thread From: Marcus Williams @ 2008-01-11 17:20 UTC (permalink / raw) Hi - This patch adds a multi key combination to expand the thread index view to all available threads. Note that this could return _a lot_ of threads, which is why I've used a double keypress '!!' as a guard to accidental usage. Its useful in conjunction with the tag all and apply to all commands though. So you may search for some term, by default you will get a limited number of threads back. Hitting ! twice allows you to expand the search to all available results. It will be slow if you've got a large number of search results. Marcus -------------- next part -------------- A non-text attachment was scrubbed... Name: load-all-threads Type: application/octet-stream Size: 2164 bytes Desc: not available Url : http://rubyforge.org/pipermail/sup-talk/attachments/20080111/65f63fe8/attachment-0001.obj ^ permalink raw reply [flat|nested] 11+ messages in thread
* [sup-talk] [PATCH] (Double/guarded) keypress to show all threads 2008-01-11 17:20 [sup-talk] [PATCH] (Double/guarded) keypress to show all threads Marcus Williams @ 2008-01-13 5:30 ` William Morgan 2008-01-13 15:57 ` Nicolas Pouillard 2008-01-13 18:16 ` Marcus Williams 0 siblings, 2 replies; 11+ messages in thread From: William Morgan @ 2008-01-13 5:30 UTC (permalink / raw) Excerpts from Marcus Williams's message of Fri Jan 11 09:20:58 -0800 2008: > This patch adds a multi key combination to expand the thread index > view to all available threads. Note that this could return _a lot_ of > threads, which is why I've used a double keypress '!!' as a guard to > accidental usage. Its useful in conjunction with the tag all and apply > to all commands though. This does make me a little nervous. Is the use case always that you want to apply a command to all threads for a given search? If so, I wonder if it would be better to explicitly model that, without the intermediate process of loading all the threads. If we're going to have a potentially long-running activity like this available from the UI, then I'd prefer to do it in a manner that gives the user an indication of how long until completion, the ability to abort, etc. How does gmail handle this type of thing? Or is everything so fast with gmail that it doesn't matter? -- William <wmorgan-sup at masanjin.net> ^ permalink raw reply [flat|nested] 11+ messages in thread
* [sup-talk] [PATCH] (Double/guarded) keypress to show all threads 2008-01-13 5:30 ` William Morgan @ 2008-01-13 15:57 ` Nicolas Pouillard 2008-01-13 18:16 ` Marcus Williams 1 sibling, 0 replies; 11+ messages in thread From: Nicolas Pouillard @ 2008-01-13 15:57 UTC (permalink / raw) Excerpts from William Morgan's message of Sun Jan 13 06:30:16 +0100 2008: > Excerpts from Marcus Williams's message of Fri Jan 11 09:20:58 -0800 2008: > > This patch adds a multi key combination to expand the thread index > > view to all available threads. Note that this could return _a lot_ of > > threads, which is why I've used a double keypress '!!' as a guard to > > accidental usage. Its useful in conjunction with the tag all and apply > > to all commands though. > > This does make me a little nervous. Is the use case always that you want > to apply a command to all threads for a given search? If so, I wonder if > it would be better to explicitly model that, without the intermediate > process of loading all the threads. > > If we're going to have a potentially long-running activity like this > available from the UI, then I'd prefer to do it in a manner that gives > the user an indication of how long until completion, the ability to > abort, etc. > > How does gmail handle this type of thing? Or is everything so fast with > gmail that it doesn't matter? By default it occurs only seen threads (25,50,100 messages depending on configuration), but you have also a check box to apply on all the search results. Then that's indeed so fast that there's no need for a progress bar. However that's fast because operations are chosen to apply fast (add or remove labels, basically). -- Nicolas Pouillard aka Ertai ^ permalink raw reply [flat|nested] 11+ messages in thread
* [sup-talk] [PATCH] (Double/guarded) keypress to show all threads 2008-01-13 5:30 ` William Morgan 2008-01-13 15:57 ` Nicolas Pouillard @ 2008-01-13 18:16 ` Marcus Williams 2008-01-14 1:06 ` William Morgan 1 sibling, 1 reply; 11+ messages in thread From: Marcus Williams @ 2008-01-13 18:16 UTC (permalink / raw) On 13.1.2008, William Morgan wrote: > This does make me a little nervous. Is the use case always that you want > to apply a command to all threads for a given search? If so, I wonder if > it would be better to explicitly model that, without the intermediate > process of loading all the threads. I dont use it when I know the search will generate a lot of threads :) What I'm working on is getting it to stop searching if the user presses a key (so you get a progress of 'Found ??? threads (press ESC to stop)' or something, but no luck yet :( I guess it doesnt actually have to return the threads a la gmail (gmail lets you select all threads in search without actually displaying them but its _fast_). I tried doing this but since the majority of searches I do end up being with labels I think you actually need to thread them in order to be of any use (because not all labels are on every message in thread). I can resubmit once I figure out the interrupt. Marcus ^ permalink raw reply [flat|nested] 11+ messages in thread
* [sup-talk] [PATCH] (Double/guarded) keypress to show all threads 2008-01-13 18:16 ` Marcus Williams @ 2008-01-14 1:06 ` William Morgan 2008-01-14 10:54 ` Marcus Williams 0 siblings, 1 reply; 11+ messages in thread From: William Morgan @ 2008-01-14 1:06 UTC (permalink / raw) Excerpts from Marcus Williams's message of Sun Jan 13 10:16:12 -0800 2008: > What I'm working on is getting it to stop searching if the user > presses a key (so you get a progress of 'Found ??? threads (press ESC > to stop)' or something, but no luck yet :( Excellent, that would be great. I don't think it will be too hard: in ThreadIndexMode#load_n_threads, in the block that's passed to @ts.load_n_threads, just check to see if a boolean instance variable is true, and break if so (and reset it). That block is called after each thread is loaded, so the ThreadSet will still be in a consistent state. Then add a keypress to set that flag to true, if @load_thread is true. > I guess it doesnt actually have to return the threads a la gmail > (gmail lets you select all threads in search without actually > displaying them but its _fast_). The general slowness of this type of operation in Sup is a real problem, IMO. I think we can go a long way by caching threading information, though of course that's at the expense of disk space. -- William <wmorgan-sup at masanjin.net> ^ permalink raw reply [flat|nested] 11+ messages in thread
* [sup-talk] [PATCH] (Double/guarded) keypress to show all threads 2008-01-14 1:06 ` William Morgan @ 2008-01-14 10:54 ` Marcus Williams 2008-01-15 4:49 ` William Morgan 0 siblings, 1 reply; 11+ messages in thread From: Marcus Williams @ 2008-01-14 10:54 UTC (permalink / raw) On 14.1.2008, William Morgan wrote: > The general slowness of this type of operation in Sup is a real > problem, IMO. I think we can go a long way by caching threading > information, though of course that's at the expense of disk space. Disk space is cheap :) So if this gets us a speed up I think its worth it. If people are worried about that sort of thing it could be a configurable option. Marcus ^ permalink raw reply [flat|nested] 11+ messages in thread
* [sup-talk] [PATCH] (Double/guarded) keypress to show all threads 2008-01-14 10:54 ` Marcus Williams @ 2008-01-15 4:49 ` William Morgan 2008-01-15 12:29 ` [sup-talk] [PATCH] Search all threads with option to cancel Marcus Williams 0 siblings, 1 reply; 11+ messages in thread From: William Morgan @ 2008-01-15 4:49 UTC (permalink / raw) Excerpts from Marcus Williams's message of Mon Jan 14 02:54:26 -0800 2008: > Disk space is cheap :) So if this gets us a speed up I think its worth > it. If people are worried about that sort of thing it could be a > configurable option. I agree. I don't think it will be terribly hard to do, either, but I should probably do some real profiling before just diving in. -- William <wmorgan-sup at masanjin.net> ^ permalink raw reply [flat|nested] 11+ messages in thread
* [sup-talk] [PATCH] Search all threads with option to cancel 2008-01-15 4:49 ` William Morgan @ 2008-01-15 12:29 ` Marcus Williams 2008-01-16 4:30 ` William Morgan 0 siblings, 1 reply; 11+ messages in thread From: Marcus Williams @ 2008-01-15 12:29 UTC (permalink / raw) This adds the ability to extend your search to display all threads (which may take a _long_ time) instead of the standard maximum (usually screen height). It is accessed via a multi-key action !C in thread index modes. To cancel the search the user can press another multi-key action !S --- lib/sup/modes/thread-index-mode.rb | 40 +++++++++++++++++++++++++++++++---- lib/sup/thread.rb | 2 +- 2 files changed, 36 insertions(+), 6 deletions(-) diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb index 0d90be4..f86a5a4 100644 --- a/lib/sup/modes/thread-index-mode.rb +++ b/lib/sup/modes/thread-index-mode.rb @@ -16,6 +16,10 @@ EOS register_keymap do |k| k.add :load_threads, "Load #{LOAD_MORE_THREAD_NUM} more threads", 'M' + k.add_multi "Search all threads - (C)onfirm, or (S)top current search :", '!' do |kk| + kk.add :load_all_threads, "Load all threads (may list a _lot_ of threads)", 'C' + kk.add :break_search, "Stop current search", 'S' + end k.add :reload, "Refresh view", '@' k.add :toggle_archived, "Toggle archived status", 'a' k.add :toggle_starred, "Star or unstar all messages in thread", '*' @@ -49,6 +53,8 @@ EOS @load_thread_opts = load_thread_opts @hidden_labels = hidden_labels + LabelManager::HIDDEN_RESERVED_LABELS @date_width = DATE_WIDTH + + @interrupt_search = false initialize_threads # defines @ts and @ts_mutex update # defines @text and @lines @@ -444,15 +450,20 @@ EOS ## TODO: figure out @ts_mutex in this method def load_n_threads n=LOAD_MORE_THREAD_NUM, opts={} @mbid = BufferManager.say "Searching for threads..." + + ts_to_load = n + ts_to_load = ts_to_load + @ts.size unless n == -1 # -1 means all threads + orig_size = @ts.size last_update = Time.now - @ts.load_n_threads(@ts.size + n, opts) do |i| + @ts.load_n_threads(ts_to_load, opts) do |i| if (Time.now - last_update) >= 0.25 - BufferManager.say "Loaded #{i.pluralize 'thread'}...", @mbid + BufferManager.say "Loaded #{i.pluralize 'thread'} (use !S to cancel search)...", @mbid update BufferManager.draw_screen last_update = Time.now end + break if @interrupt_search end @ts.threads.each { |th| th.labels.each { |l| LabelManager << l } } @@ -472,13 +483,32 @@ EOS end end - def load_threads opts={} - n = opts[:num] || ThreadIndexMode::LOAD_MORE_THREAD_NUM + def break_search + @interrupt_search = true + end + def load_all_threads + load_threads :num => -1 + end + + def load_threads opts={} + if opts[:num].nil? + n = ThreadIndexMode::LOAD_MORE_THREAD_NUM + else + n = opts[:num] + end + myopts = @load_thread_opts.merge({ :when_done => (lambda do |num| opts[:when_done].call(num) if opts[:when_done] + + cancelled = "" + if @interrupt_search + cancelled = " (search cancelled by user)" + @interrupt_search = false + end + if num > 0 - BufferManager.flash "Found #{num.pluralize 'thread'}." + BufferManager.flash "Found #{num.pluralize 'thread'}#{cancelled}." else BufferManager.flash "No matches." end diff --git a/lib/sup/thread.rb b/lib/sup/thread.rb index 83f0db7..5b0a300 100644 --- a/lib/sup/thread.rb +++ b/lib/sup/thread.rb @@ -324,7 +324,7 @@ class ThreadSet ## load in (at most) num number of threads from the index def load_n_threads num, opts={} @index.each_id_by_date opts do |mid, builder| - break if size >= num + break if size >= num unless num == -1 next if contains_id? mid m = builder.call -- 1.5.3.7 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [sup-talk] [PATCH] Search all threads with option to cancel 2008-01-15 12:29 ` [sup-talk] [PATCH] Search all threads with option to cancel Marcus Williams @ 2008-01-16 4:30 ` William Morgan 2008-01-16 10:47 ` Marcus Williams 0 siblings, 1 reply; 11+ messages in thread From: William Morgan @ 2008-01-16 4:30 UTC (permalink / raw) Reformatted excerpts from Marcus Williams's message of 2008-01-15: > This adds the ability to extend your search to display all threads > (which may take a _long_ time) instead of the standard maximum > (usually screen height). It is accessed via a multi-key action !C in > thread index modes. To cancel the search the user can press another > multi-key action !S. I think you should split this into two patches, the first of which adds the ability to stop any current thread-loading operation, and the second of which gives you the "load everything now" button. I'd like to evaluate each one independently. I think I'd like the stop loading button to be ^G, which is the general cancel command everywhere in Sup. The load everything now button can be a scary multi-key sequence like "!!". Comments welcome. -- William <wmorgan-sup at masanjin.net> ^ permalink raw reply [flat|nested] 11+ messages in thread
* [sup-talk] [PATCH] Search all threads with option to cancel 2008-01-16 4:30 ` William Morgan @ 2008-01-16 10:47 ` Marcus Williams 2008-01-16 21:09 ` William Morgan 0 siblings, 1 reply; 11+ messages in thread From: Marcus Williams @ 2008-01-16 10:47 UTC (permalink / raw) On 16.1.2008, William Morgan wrote: > I think you should split this into two patches, the first of which adds > the ability to stop any current thread-loading operation, and the second > of which gives you the "load everything now" button. I'd like to > evaluate each one independently. At the moment isnt the only thread-loading operation the load_n_threads method in thread-index-view? All the possibly long running operations that run threads that I can think of end up going through this as far as I can see. So do you want a patch for interrupting the load threads method, and then a patch to add the potentially long running load_all_threads? > I think I'd like the stop loading button to be ^G, which is the general > cancel command everywhere in Sup. The load everything now button can be > a scary multi-key sequence like "!!". > Ok, easily done - I didnt use ^G originally because I thought you couldnt overload a key action in a mode and I though ^G was added elsewhere. Marcus ^ permalink raw reply [flat|nested] 11+ messages in thread
* [sup-talk] [PATCH] Search all threads with option to cancel 2008-01-16 10:47 ` Marcus Williams @ 2008-01-16 21:09 ` William Morgan 0 siblings, 0 replies; 11+ messages in thread From: William Morgan @ 2008-01-16 21:09 UTC (permalink / raw) Reformatted excerpts from Marcus Williams's message of 2008-01-16: > At the moment isnt the only thread-loading operation the > load_n_threads method in thread-index-view? All the possibly long > running operations that run threads that I can think of end up going > through this as far as I can see. Yes. > So do you want a patch for interrupting the load threads method, and > then a patch to add the potentially long running load_all_threads? Precisely. > Ok, easily done - I didnt use ^G originally because I thought you > couldnt overload a key action in a mode and I though ^G was added > elsewhere. In general that is more or less true, but ^G is only caught by the top-level event handler (which we override every time we define a mode-specific keyboard command), and by the text entry stuff, which does its own keyboard handling routine. So I think you should be fine. -- William <wmorgan-sup at masanjin.net> ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2008-01-16 21:09 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-01-11 17:20 [sup-talk] [PATCH] (Double/guarded) keypress to show all threads Marcus Williams 2008-01-13 5:30 ` William Morgan 2008-01-13 15:57 ` Nicolas Pouillard 2008-01-13 18:16 ` Marcus Williams 2008-01-14 1:06 ` William Morgan 2008-01-14 10:54 ` Marcus Williams 2008-01-15 4:49 ` William Morgan 2008-01-15 12:29 ` [sup-talk] [PATCH] Search all threads with option to cancel Marcus Williams 2008-01-16 4:30 ` William Morgan 2008-01-16 10:47 ` Marcus Williams 2008-01-16 21:09 ` William Morgan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox