* [sup-talk] Why inbox-mode instead of default search?
@ 2009-09-27 17:04 William Erik Baxter
2009-09-27 17:46 ` William Morgan
0 siblings, 1 reply; 8+ messages in thread
From: William Erik Baxter @ 2009-09-27 17:04 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [sup-talk] Why inbox-mode instead of default search?
2009-09-27 17:04 [sup-talk] Why inbox-mode instead of default search? William Erik Baxter
@ 2009-09-27 17:46 ` William Morgan
2009-09-27 18:50 ` William Erik Baxter
0 siblings, 1 reply; 8+ messages in thread
From: William Morgan @ 2009-09-27 17:46 UTC (permalink / raw)
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
> search-results-mode and not in inbox-mode.
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>
^ permalink raw reply [flat|nested] 8+ messages in thread
* [sup-talk] Why inbox-mode instead of default search?
2009-09-27 17:46 ` William Morgan
@ 2009-09-27 18:50 ` William Erik Baxter
2009-09-30 15:16 ` William Morgan
0 siblings, 1 reply; 8+ messages in thread
From: William Erik Baxter @ 2009-09-27 18:50 UTC (permalink / raw)
Excerpts from William Morgan's message of Sun Sep 27 13:46:00 -0400 2009:
> 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.
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.
> 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.
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [sup-talk] Why inbox-mode instead of default search?
2009-09-27 18:50 ` William Erik Baxter
@ 2009-09-30 15:16 ` William Morgan
2009-09-30 16:12 ` Carl Worth
0 siblings, 1 reply; 8+ messages in thread
From: William Morgan @ 2009-09-30 15:16 UTC (permalink / raw)
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).
> 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.
I agree.
--
William <wmorgan-sup at masanjin.net>
^ permalink raw reply [flat|nested] 8+ messages in thread
* [sup-talk] Why inbox-mode instead of default search?
2009-09-30 15:16 ` William Morgan
@ 2009-09-30 16:12 ` Carl Worth
2009-09-30 17:47 ` Rich Lane
0 siblings, 1 reply; 8+ messages in thread
From: Carl Worth @ 2009-09-30 16:12 UTC (permalink / raw)
Excerpts from William Morgan's message of Wed Sep 30 08:16:35 -0700 2009:
> How does the notion of killing a thread that makes sense except in the
> 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.
> 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).
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.
> > 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.
>
> I agree.
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>
^ permalink raw reply [flat|nested] 8+ messages in thread
* [sup-talk] Why inbox-mode instead of default search?
2009-09-30 16:12 ` Carl Worth
@ 2009-09-30 17:47 ` Rich Lane
2009-09-30 18:04 ` William Morgan
2009-09-30 19:12 ` Carl Worth
0 siblings, 2 replies; 8+ messages in thread
From: Rich Lane @ 2009-09-30 17:47 UTC (permalink / raw)
Excerpts from Carl Worth's message of Wed Sep 30 12:12:35 -0400 2009:
> Or said another way, you would get exactly what you want if there was
> 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [sup-talk] Why inbox-mode instead of default search?
2009-09-30 17:47 ` Rich Lane
@ 2009-09-30 18:04 ` William Morgan
2009-09-30 19:12 ` Carl Worth
1 sibling, 0 replies; 8+ messages in thread
From: William Morgan @ 2009-09-30 18:04 UTC (permalink / raw)
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>
^ permalink raw reply [flat|nested] 8+ messages in thread
* [sup-talk] Why inbox-mode instead of default search?
2009-09-30 17:47 ` Rich Lane
2009-09-30 18:04 ` William Morgan
@ 2009-09-30 19:12 ` Carl Worth
1 sibling, 0 replies; 8+ messages in thread
From: Carl Worth @ 2009-09-30 19:12 UTC (permalink / raw)
Excerpts from Rich Lane's message of Wed Sep 30 10:47:53 -0700 2009:
> Excerpts from Carl Worth's message of Wed Sep 30 12:12:35 -0400 2009:
> > Or said another way, you would get exactly what you want if there was
> > 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.
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>
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2009-09-30 19:12 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-09-27 17:04 [sup-talk] Why inbox-mode instead of default search? William Erik Baxter
2009-09-27 17:46 ` William Morgan
2009-09-27 18:50 ` William Erik Baxter
2009-09-30 15:16 ` William Morgan
2009-09-30 16:12 ` Carl Worth
2009-09-30 17:47 ` Rich Lane
2009-09-30 18:04 ` William Morgan
2009-09-30 19:12 ` Carl Worth
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox