From mboxrd@z Thu Jan 1 00:00:00 1970 From: cworth@cworth.org (Carl Worth) Date: Tue, 18 Aug 2009 18:58:55 -0700 Subject: [sup-talk] What's your sup workflow (and a spew of ideas) In-Reply-To: <1250634897-sup-4631@zyrg.net> References: <1250629282-sup-8521@yoom> <1250634897-sup-4631@zyrg.net> Message-ID: <1250646478-sup-4064@yoom> 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: