Subject: [sup-talk] Why inbox-mode instead of default search?

From: [email-masked] (William Erik Baxter)
Date: Sun, 27 Sep 2009 13:04:39 -0400

Why does sup have a separate mode for viewing the inbox rather than simply
applying a default search (possibly configurable) and displaying the results
with search-results-mode?  Like a number of other posters to the list, I wanted
to refine my inbox search.  But the requisite key binding exists only in
search-results-mode and not in inbox-mode.

Using inbox as an ordinary label with search-results-mode instead of inbox-mode
offers several advantages over the separate inbox-mode: less code, less
separate modality, ability to refine the inbox search.  It introduces the
possibility of closing the inbox window, readily addressed with a key binding
to perform the default search.  What are the disadvantages?  One loses the
difference in the archiving behavior between the two modes.  The inbox label
would appear in the label editors.  The program may need new code to handle a
new no-windows case.  Perhaps efficiency considerations enter here. 

Thanks, W.

---

From: [email-masked] (William Morgan)
Date: Sun, 27 Sep 2009 10:46:00 -0700

Reformatted excerpts from William Erik Baxter's message of 2009-09-27:
> Why does sup have a separate mode for viewing the inbox rather than
> simply applying a default search (possibly configurable) and
> displaying the results with search-results-mode?

Because there are two special actions that are specific to inboxes:
archiving and killing.

> Like a number of other posters to the list, I wanted to refine my
> inbox search.  But the requisite key binding exists only in

It would be easy enough to add a "|" command to inbox mode that would
spawn a search buffer with label:inbox and the rest of your search
terms.

-- 
William <wmorgan-sup at masanjin.net>

---

From: [email-masked] (William Erik Baxter)
Date: Sun, 27 Sep 2009 14:50:08 -0400

> Because there are two special actions that are specific to inboxes:

Both modes support archive and kill in some form.  So I don't understand how
this argues for splitting as opposed to consolidating the two modes.  The need
for preallocated, special-purpose labels like inbox and killed seems clear
enough.  However, minimizing the amount of magical behavior they exhibit also
seems beneficial, if only for the sake of consistency.  Treating the inbox as
something other than an ordinary label search is magical.

> spawn a search buffer with label:inbox and the rest of your search

A patch to add this command to inbox-mode appears in the August sup-talk
archive.  I would like to see this feature become part of the base system.

Cheers, W.

---

From: [email-masked] (William Morgan)
Date: Wed, 30 Sep 2009 08:16:35 -0700

Reformatted excerpts from William Erik Baxter's message of 2009-09-27:
> Both modes support archive and kill in some form.  So I don't
> understand how this argues for splitting as opposed to consolidating
> the two modes.

How does the notion of killing a thread that makes sense except in the
context of having an special inbox mode?

> The need for preallocated, special-purpose labels like
> inbox and killed seems clear enough.  However, minimizing the amount
> of magical behavior they exhibit also seems beneficial, if only for
> the sake of consistency.  Treating the inbox as something other than
> an ordinary label search is magical.

The inbox is magical, because you do different things with your inbox
than you do with non-inbox buffers: you classify threads into a) I'm
done with this thread for now, but let me know if someone replies
(archive); b) I'm done with this thread for now and don't let me know if
someone replies (kill); c) I'll deal with this later (ignore).

> archive.  I would like to see this feature become part of the base system.

I agree.

---

From: [email-masked] (Carl Worth)
Date: Wed, 30 Sep 2009 09:12:35 -0700

> context of having an special inbox mode?

The kill-thread notion can be handled in multiple ways without a
special inbox mode.

One way would be to simply not apply the inbox label to new messages
belonging to killed threads.

A better way would be to expand the search capability to something like:

  Search for all threads containing messages matching <include-condition>
  AND exclude all threads containing messages matching <exclude-condition>

I'd be happy to have that kind of functionality for arbitrary labels
that would function like killed for specific searches.

> someone replies (kill); c) I'll deal with this later (ignore).

It's definitely true that reading new mail is a different activity
than searching old mail, (note my recent patch that provides different
sort orders for these two operations).

But there are at least two problems with the current inbox mode
implemented separately from the search mode:

1. Some functionality appears in only one or the other of the modes.

   Refine search is the easy-to-notice one that we've talked
   about. But really, any keybindings performing distinct actions in
   these two modes is just confusing. The two modes are far too
   similar to have independent lists of possible actions and
   bindings. This should be unified.

2. There are some things that are currently implemented as "magic" in
   inbox mode that should really be made available to all searches.

   Things like the archive operation making a message disappear from
   the inbox. Instead, any operation making a message no longer
   satisfy the current search should cause it to disappear from the
   current view.

> > archive.  I would like to see this feature become part of the base system.

One shortcoming of that patch is that refined versions of the inbox
come up in search-results-mode, not inbox-mode. So you don't actually
get what you want yet, (such as archiving no longer works the same in
a refined inbox as it does in the raw inbox).

Or said another way, you would get exactly what you want if there was
nothing magic about inbox.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090930/1641d2ef/attachment.bin>

---

From: [email-masked] (Rich Lane)
Date: Wed, 30 Sep 2009 13:47:53 -0400

> nothing magic about inbox.

I've been working on a patch to do this. You can see the current state
at http://github.com/rlane/sup/tree/personal/. It's still buggy and
needs to be cleaned up a lot before I submit it. The basic idea is that
ThreadSet becomes tightly coupled to the Index and stays in sync with
it. This lets us use the index to determine whether a message is
relevant to a query, which was the main cause of magic previously. It
also makes ThreadIndexMode much simpler in general resulting in a net
code reduction.

---

From: [email-masked] (William Morgan)
Date: Wed, 30 Sep 2009 11:04:52 -0700

Reformatted excerpts from Rich Lane's message of 2009-09-30:
> This lets us use the index to determine whether a message is relevant
> to a query, which was the main cause of magic previously. It also
> makes ThreadIndexMode much simpler in general resulting in a net code
> reduction.

Now you're talking my language. :)
-- 
William <wmorgan-sup at masanjin.net>

---

From: [email-masked] (Carl Worth)
Date: Wed, 30 Sep 2009 12:12:45 -0700

Excerpts from Rich Lane's message of Wed Sep 30 10:47:53 -0700 2009:
> needs to be cleaned up a lot before I submit it.

Very nice stuff, Rich!

It's great to see this coming along so far already.

Please let me know if there are specific bugs or issues you'd like
help fixing, and I'll be glad to try out where I can. Or even if there
are just specific things you'd like tested---I'm not too afraid of
running half-baked sup branches. :-)

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