[sup-talk] On making inbox-mode and search-results-mode more similar

* [sup-talk] On making inbox-mode and search-results-mode more similar
@ 2009-08-26 22:24 Carl Worth
  2009-08-26 22:52 ` Carl Worth
                   ` (3 more replies)
  0 siblings, 4 replies; 9+ messages in thread
From: Carl Worth @ 2009-08-26 22:24 UTC (permalink / raw)


[Argh! I ended up getting really verbose again with this one. Thanks
to anyone patient enough to wade through all of this. There is a patch
here for one issue at least. See below.]

I spent about 4 days away from email which gave me my first case of a
large inbox after switching to sup. And there are definitely a few
things I'd like to convince sup to do to make it easier for me to deal
with this.

Most important, with a large inbox, my mail falls into different
"classes", some of which are more important than others, and I'd like
to deal with the most important things first. I also often want to
deal with a single "class" of mail as a whole to avoid mental context
switches.

Fortunately, I've got sup labels capturing these classes quite
well. I've got some future ideas for having a prioritized (partial
order) list of labels so that inbox-mode will present messages
according to that priority. But for now, it would be good enough to be
able to easily filter my inbox down to just a single class of messages
at a time.

To this end, I started using the patch below, which adds a
refine_search keybinding to inbox-mode much like the same function in
search-result-mode. This is useful already and might be considered for
inclusion as is, (another feature I'd like for both modes is "restrict
to label" which would act like refine-search but save me from having
to type "label:" much like the 'L' command avoids having to type
"label:" compared to the 'F' command).

Beyond this patch as is, though, I'd like to talk a bit about how to
better achieve what I want. There's obviously some code duplication in
this patch which is not ideal. It would be better if InboxMode could
be a derived class from SearchResultsMode. Not only would this reduce
code-duplication, but there are features currently in InboxMode that I
think belong in all searches.

For example, if I use the refine_search command below to get a view of
my inbox restricted to a particular label, it no longer acts like my
inbox does. One of the most noticeable cases is the archive
command[*].  In both inbox-mode and search-result-mode this command
removes the "inbox" label from a thread, but in inbox-mode the thread
is immediately removed from the results, while in search-results-mode
the thread remains in the results.

One annoying side effect of this is that when I'm reading and
archiving many threads in some class, then I happen to reply to one
thread, that thread gets bumped to the top of my search so when I
navigate to the "next" thread I start cycling through threads that I
just got finished reading and archiving. To fix this I end up having
to notice I'm seeing repeated messages, remember why, then save my
current changes and refresh the search. And I have to do this after
every reply.

[Note: Even if archiving messages made them immediately disappear from
my search results, there could still be problems with "next" causing
me to re-cycle through messages I had already read but decided to
leave in my inbox. I think this is just another general race-condition
bug. I think the fix would be for the transition from
search-results-mode to thread-view-mode to somehow snapshot the
current search results so that future modifications due to newly
arriving messages don't modify the meaning of "next thread" within
thread-view-mode.]

So what I want is for anytime a message is changed such that it no
longer meets the current search criteria, it is immediately removed
from the search results. I think that means simply implementing the
is_relevant? method for SearcResultsMode where there is currently just
the following comment:

  ## a proper is_relevant? method requires some way of asking ferret
  ## if an in-memory object satisfies a query. i'm not sure how to do
  ## that yet. in the worst case i can make an in-memory index, add
  ## the message, and search against it to see if i have > 0 results,
  ## but that seems pretty insane.

That single-message index and search sounds exactly like what I want,
and not insane at all. Has someone attempted this and found a
performance issue? (In which case, I would think we just need to fix
that performance bug.) Or is it simply a matter of nobody having tried
to code this up yet? (In which case, I'll try, and I'll be glad for
any pointers that anyone can give me on how to go about creating an
in-memory index and searching on it.)

Thanks,

-Carl

[*] I'll ignore for now the fact that 'a' is a toggle of the inbox
label in SearchResultsMode and a one-way removal of the label in
InboxMode. I haven't found any need to ever put a thread _back_ into
the inbox, (except perhaps in the case of accidental archiving, and
there an immediate undo works fine). So I would imagine the use is
rare enough to not need a single-character command. The command I
would find natural for putting a thread back into the inbox would be
to simply add the inbox label to the thread. Oddly this is currently
not allowed as "inbox" is a reserved label. I don't


From d37eca31aaddee80f05357d6a4ed896f39bbad16 Mon Sep 17 00:00:00 2001
From: Carl Worth <cworth at cworth.org>
Date: Wed, 26 Aug 2009 10:17:20 -0700
Subject: [PATCH] Add a refine_search command to InboxMode

This is just a copy of SearchResultsMode's refine_search command.
A much cleaner, but more involved, approach would be to rework
InboxMode to derive from SearchResultsMode in the first place.
---
 lib/sup/modes/inbox-mode.rb |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/lib/sup/modes/inbox-mode.rb b/lib/sup/modes/inbox-mode.rb
index ba095da..c8072cd 100644
--- a/lib/sup/modes/inbox-mode.rb
+++ b/lib/sup/modes/inbox-mode.rb
@@ -7,6 +7,7 @@ class InboxMode < ThreadIndexMode
     ## overwrite toggle_archived with archive
     k.add :archive, "Archive thread (remove from inbox)", 'a'
     k.add :read_and_archive, "Archive thread (remove from inbox) and mark read", 'A'
+    k.add :refine_search, "Refine search", '|'
   end
 
   def initialize
@@ -17,6 +18,12 @@ class InboxMode < ThreadIndexMode
 
   def is_relevant? m; (m.labels & [:spam, :deleted, :killed, :inbox]) == Set.new([:inbox]) end
 
+  def refine_search
+    text = BufferManager.ask :search, "refine query: ", "label:inbox -label:spam -label:deleted -label:killed "
+    return unless text && text !~ /^\s*$/
+    SearchResultsMode.spawn_from_query text
+  end
+
   ## label-list-mode wants to be able to raise us if the user selects
   ## the "inbox" label, so we need to keep our singletonness around
   def self.instance; @@instance; end
-- 
1.6.3.3

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090826/0ec68a3f/attachment.bin>


^ permalink raw reply	[flat|nested] 9+ messages in thread