From: cworth@cworth.org (Carl Worth)
Subject: [sup-talk] [PATCH] Allow thread index view to sort oldest first
Date: Fri, 25 Sep 2009 14:08:23 -0700 [thread overview]
Message-ID: <1253911610-sup-2052@yoom.home.cworth.org> (raw)
Keith and I both want to read our email in chronological order,
(reading oldest messages first), so we believe it makes sense to
present the inbox mode in this order, (with the oldest messages at the
top).
This is distinct from the order for global searches where having the
newest messages first does seem obviously correct.
The below patches are a first cut at implementing this. They provide a
new configuration option, (:inbox_newest_first), which can be used to
control the default sorting for the inbox. Keith's original patch
doesn't change sup's behavior unless the user manually configures this
option to false. My second patch changes the default. Obviously, it
would be easy to accept Keith's version without changing the default
for sup.
One nice thing about the inmplentation is that any refined searches
inherit the mode of the parent search, which makes it easy to maintain
oldest-message-first for "reading" and newest-message-first for
"searching".
Also note that there's a new command 'o' to toggle the search order
for a current view. This is a feature that we talked about earlier as
a way to avoid the need for the distinction between the ',' and ']'
commands in thread-view-mode. If the user can control the sort of the
search view, then it would be more natural to have commands that
simply advance to the "next" message, (since the user can choose in
advance what "next" means).
A couple of caveats with respect to the patch as it exists so far:
1. When doing oldest-first searching, it wasn't obvious if it's even
possible to query for only the N oldest messages (to lazily load
new threads while navigating as sup currently does). So the patch
currently loads all threads when in oldest-first mode.
In my use so far this has worked well since I generally have a
small number of messages in my inbox (and even fewer in my refined
views of my inbox) and those are the only places where I use
oldest-first sorting. For global searches, I do have an effectively
infinite number of messages, but there I do use newest-first
searching which still has the lazy loading.
2. Currently sup uses the date of the newest message in a thread as
the key for sorting that message. This is correct for newest-first
sorting. But when doing the new oldest-first sorting, the patch
really should be augmented to instead use the date of the oldest
message in a thread that matches the current search criteria.
We haven't looked yet into how hard this would be to fix. (And we'd
of course be glad for any help or pointers.)
-Carl
PS. We're still total ruby newbies, so please point out any silly
mistakes we're missing with respect to ruby idioms.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Allow-thread-index-view-to-sort-oldest-first.patch
Type: application/octet-stream
Size: 7849 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090925/8fd3d30c/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Change-the-default-sort-for-inbox-mode-to-be-oldest-.patch
Type: application/octet-stream
Size: 777 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090925/8fd3d30c/attachment-0001.obj>
-------------- 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/20090925/8fd3d30c/attachment.bin>
next reply other threads:[~2009-09-25 21:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-25 21:08 Carl Worth [this message]
2009-10-01 17:04 ` William Morgan
2009-10-01 17:43 ` Carl Worth
2009-10-12 12:48 ` William Morgan
2009-10-12 23:02 ` Carl Worth
2009-10-13 20:51 ` Olly Betts
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1253911610-sup-2052@yoom.home.cworth.org \
--to=cworth@cworth.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox