From: cworth@cworth.org (Carl Worth)
Subject: [sup-talk] What's your sup workflow (and a spew of ideas)
Date: Tue, 18 Aug 2009 18:58:55 -0700 [thread overview]
Message-ID: <1250646478-sup-4064@yoom> (raw)
In-Reply-To: <1250634897-sup-4631@zyrg.net>
Excerpts from Rich Lane's message of Tue Aug 18 16:02:01 -0700 2009:
> provide-commands-to-refine-the-current-search:
>
> '|' exists for search-results-mode (and it should be implemented for
> label-results-mode if it doesn't exist there).
Ah, thanks for pointing this out. I totally missed it somehow.
This doesn't exist for inbox-mode, which is where I think I would like
it the most. And conceptually, the inbox is just a search, right? It
seems to me that inbox-mode should be at most a very slight tweak of
search-results-mode. I'll go digging in the code to see how far away
that would be.
For what it's worth, | doesn't exist for search-results mode.
And also, the shortcuts to refine the search by adding a label would
be nice too, (so one wouldn't need to type "label:"). So now I at
least know what already exists.
> sort-priority-labels-before-date:
>
> This isn't entirely easy for large numbers of messages. We've optimized
> the index (especially Xapian) for reverse chronological order. You could
> either do the sorting entirely in the UI, but just on the subset of
> results currently loaded, or you could create a new mode that merges and
> prioritizes the results of multiple queries.
I think the former would be fine. The UI encourages only a small number of
results to be loaded already, so just sorting there should work find I
thin.
> allow-for-limiting-to-interesting-labels:
>
> I have a hack for this. I reopen Redwood::Mode in the startup hook, then
> add a keybinding to spawn a SearchResultsMode for a set of interesting
> labels. Same for starred messages. A better solution would be good.
While waiting for a better solution, would you mind sharing your code
for this? I'm quite new to ruby, so even if what you described should
be trivial for me to replicate, it's not yet. :-)
Maybe a page on the wiki?
> save-all-state-changes-immediately,
> allow-for-inbox-mode-magic-elsewhere,
> fix-handling-of-kill-thread-outside-inbox:
>
> These are related - saving label changes immediately means we can use
> the index to decide which threads are relevant. The new index api
> methods unblock this, and now that they're in next I plan to implement
> this soon.
Excellent. It did seem that things were moving this direction, and I'm
glad to hear that they are.
> be-less-overzealous-in-moving-text-to-the-left-column,
> dont-perturb-selected-thread-when-new-mail-arrives:
>
> +1 to these.
Great. And those don't sound too complicated, so maybe I'll try
cutting my teeth on those first.
Meanwhile, I thought of another race condition. If new mail arrives
for the current thread when in thread-view-mode, does it get added to
the view? It might seem nice for it to show up, but it might also lead
to it getting accidentally archived away if I "knew" that there were
only 4 messages, say, when I entered the thread view, then I hit ".a"
and archived away 5 messages.
It seems a silly thing, but it's the kind of thing that makes me start
distrusting ".a" and instead using "x", double-checking, then "a"
which is obviously less efficient. (Oh, and there's another place
where the current selector needs to not be perturbed. After I hit "x"
from thread-view-mode I find that a different thread can be selected
than the one I was just viewing if new mail arrived.)
-Carl
-------------- 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/20090818/ab65d341/attachment.bin>
next prev parent reply other threads:[~2009-08-19 1:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-18 21:02 Carl Worth
2009-08-18 21:46 ` Carl Worth
2009-08-18 22:07 ` Andrei Thorp
2009-08-18 22:16 ` Carl Worth
2009-08-18 23:02 ` Rich Lane
2009-08-19 1:58 ` Carl Worth [this message]
2009-08-19 3:02 ` Rich Lane
2009-08-19 14:03 ` Andrei Thorp
2009-08-19 23:21 ` Carl Worth
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=1250646478-sup-4064@yoom \
--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