From: cworth@cworth.org (Carl Worth)
Subject: [sup-talk] What's your sup workflow (and a spew of ideas)
Date: Tue, 18 Aug 2009 14:02:05 -0700 [thread overview]
Message-ID: <1250629282-sup-8521@yoom> (raw)
I'm now a few days into using sup, and it's clearly helped me to be
more productive at processing mail, (inbox is down to 0 from *lots* of
messages), so thanks!
However, I still don't feel like I'm experiencing the zen of sup
yet. So I'm interested in hearing from others:
What is your typical workflow with sup? That is:
What different modes of task do you find yourself doing with sup?
Precisely what keystrokes do you use for those tasks?
Where, if anywhere, does sup get in your way rather than help?
What follows is my (rather long) answer to those questions, and more
or less a todo list of things I'd like to help improve in sup.
My desired workflow
===================
I think there's a basic two-level approach I take to processing new
email. Fortunately, these two modes correspond well with sup's
inbox-mode and thread-view-mode. Here's what I'd like to do:
Identify "unimportant" threads (no need to read)
------------------------------------------------
This is a quick scan of the thread titles in my inbox. The goal here
is to identify as quickly as possible threads that I will never need
to read at all, (so that they can be immediately removed from my
inbox). Ideally, I will make a decision in one or two seconds, and
issue a single character command to indicate the decision.
Dealing with remaining "important" threads
------------------------------------------
After having eliminated as many threads as possible during the scan of
the inbox, I now switch to a mode where I'm actually looking at mail
messages. The goal here is to identify whether I need to do anything,
and how much time that will take. There are three possible outcomes:
* No action needed
* Quick action, (less than two minutes)
* Longer action required (to assign to some project)
(Any similarity to a method proposed by David Allen in Getting Things
Done is not accidental, and he deserves credit as such.)
Regardless of the three results, I will be quickly archiving the
thread so that it's gone from my inbox. That will be either immediate
archiving, archiving after a quick action (such as a reply), or
archiving after tagging the thread with a label for the appropriate
project.
How sup could support my workflow better
========================================
So sup obviously fits in quite well with the above model---which is
why I immediately fell in love with it. So first of all I have to
again say thank you. And I apologize that I will go into more detail
on the things I'd like to change in sup as opposed to the things that
already work so well. This isn't a criticism of the tool, just an
expression of my desire to improve it.
I'll phrase the list below as feature requests. Some of these things
may already exist in sup, and I just missed them. In such cases, I'll
be glad to hear pointers to the things I missed. Otherwise, I plan to
work on developing patches for these, and I'll be glad for any help.
I'll give each feature a name in [square-brackets] for easy reference in followup messages.
inbox-mode
-----------
* [black-on-white-color-scheme]
We've talked in another thread about adding support for a
black-text-on-white-background color scheme to sup-config. Before I
can write a patch for that, does somebody have an example
black-on-white color scheme that works well? I've been trying to
come up with one but I've been unable to find how to change some
colors, specifically:
+ [change-color-of-thread-selector]
The selector for the current thread in thread-mode appears as
black-foreground-on-cyan right now. I haven't been able to find
the setting to make that a more easy-to-read background color, and
this is the only line in the view that isn't bold when unread,
(which is not ideal since it's the only line I'm trying to read
and process).
+ [change-color-of-tag-markers]
The tag markers are yellow, which is hard to see on white. I also
couldn't find the setting to change this.
* [import-read-messages-as-archived-from-initial-sup-config-based-sync]
When I very first started using sup, (running sup-config which setup
sources and ran sup-sync) I was surprised to find my inbox with
thousands of unread messages in it. Now that I'm using sup more I
love that sup treats inbox and unread as separate labels, (far too
many email programs fail to separate those notions). But for that
initial import, I think it would have been much more useful to have
only given the inbox tag to unread messages.
* [sort-priority-labels-before-date]
The default sorting for the inbox is reverse-chronological which is
a reasonable-enough default, (and works fine for me when I keep my
inbox small). But when I get behind and my inbox gets large, (say
after a few days away from email), I do have some tags that I would
like to be sorted to the top, regardless of date. How about support
for a configurable list of "priority" tags that would provide a
primary sort before the date-based sort?
* [save-all-state-changes-immediately]
The 'a' and 'd' commands do almost exactly what I expect, (by
immediately making the current thread disappear and advancing the
selector to the next thread). That's perfect for fast
processing. One thing missing here is that they don't actually save
this state, (requiring me to hit '$' at some point). Perhaps that
safety feature was more important before undo was implemented, but
now that it exists, would immediate state saving make sense?
The two bad side effects I've experienced due to lack of immediate
saving are: 1. Seeing confusingly inconsistent results after
processing a bunch of my inbox and then doing a search based on
label:unread or label:inbox (Why am I seeing all these messages
again?). 2. Losing a bunch of processing state due to crashes. (The
crashes have been due to the mbox-processing bug which has since
been fixed, but being immune to state loss for any future crashes
would be beneficial.)
search-results-mode
-------------------
* [provide-commands-to-refine-the-current-search]
I mentioned above wanting to sort priority labels before
date. Similarly, when processing a very large email I sometimes want
to process related messages together, (to reduce mental context
switches). So I want variants of both "\, F: Search all messages"
and "L: list labels" search commands that refine the current search
rather than doing a new global search. That is, the new commands
would simply append new search terms to the current search rather
than starting a new search.
* [allow-for-inbox-mode-magic-elsewhere]
Another way to reword this one would be to "eliminate any magic of
inbox mode". My question is, "What makes inbox-mode different than
search-results-mode and how can I get the behavior of inbox-mode in
my searches?".
Without commands to refine the current search as described above,
I've been trying to achieve results like "inbox refined to
label:foo" with a search as follows:
label:inbox -label:killed label:foo
This gives me the set of threads that I want, but now my standard
processing commands no longer work. For example, the 'a' key still
removes the inbox label, but it doesn't make the tag then disappear
immediately.
One approach to fix this would be that when adding the commands to
refine the inbox search, the new search results would also be in
inbox-mode with all necessary magic.
A more general fix would be to process the current thread after any
changes, (such as the addition or removal of a label), and removing
it from the current search results if it no longer meets those
criteria.
* [fix-handling-of-kill-thread-outside-inbox]
The handling of the "&: kill thread" command when applied outside of
the inbox, (such as in search-results-mode), is currently very
confusing. What it currently seems to do is to add the killed label
and make the thread disappear from the current view. But then,
running "@: Refresh view" will make it reappear, (whereupon one can
make it disappear again with &, ad infinitum). The removal of the
thread from the current view seems to be magic associated with the
kill-thread command, (leading to inconsistent behavior). I would
again suggest to instead implement the general fix described above,
(always reprocessing a thread after label changes to see if it still
meets the current search). That way, trying to kill a thread without
-label:killed in the current search would simply add the "killed"
label and the user would learn to add the necessary search terms,
(or to do searches based on refining the searches of existing views
to inherit this term).
thread-view-mode
----------------
* [override-arrow-keys-to-jump-to-next-actionable-line]
In thread-view-mode the up and down arrows currently advance a
selector by one line at a time, (inherited from line-cursor-mode),
all the way into message bodies. As far as I can tell, this is not a
useful behavior. I propose that the down arrow key should instead
advance the selector to the next line which would cause a context
change for the various operations that can be performed based on the
selector, (or scroll to the next page if there are no such lines on
the current or next page).
* [be-less-overzealous-in-moving-text-to-the-left-column]
I tend to use sup in a very wide terminal, (200+ columns). And I'm
glad to see that the inbox-mode takes advantage of this by showing a
preview of the message body (that's a nice touch!) where many
console-based clients just cut things off at 80 columns.
However, in thread-view-mode, sup always pushes the current message
all the way over to the left-hand column. This does mean that the
"current" message is visible, but I have a tendency to read much
more than the current message, (even before advancing), and
subsequent messages are often scrolled such that the first several
columns of text are scrolled off to the left. Meanwhile, I have
acres of terminal real-estate to the right that sup isn't using.
I would propose that messages only be scrolled to the left if
necessary to avoid the 80th column of the message body not being
visible, (assuming the terminal is at least 80 columns wide).
compose-mode
------------
* [repeated-postponing-shouldnt-make-additional-drafts]
I find that while composing a message I often want to go look at
some other messages for reference. This is currently quite awkward
with sup. It would be easier if sup could be run multiple times. It
would also be easier if sup could somehow fire off an editor as an
external process, while still allowing for sup to be operated.
As it stands, instead, I have to save and quit from my editor,
postpone the message within sup, and then later come back to edit it
again, and find where I was in the editor. It's an expensive context
switch with a lot of keystrokes and lost state, (such as where point
was inside emacs, my kill ring, etc.). I'm currently finding myself
sometimes just drafting messages in emacs sessions unrelated to sup,
and then doing "M-x insert-file" once sup has launched emacs for
me. (This does relate a bit to the point I made in a previous thread
where I would love to find a way to keep all the mail-composition
tasks very separate from sup, but not lose things like replied-to
bits.)
Anyway, the current misfeature I'm hitting is that if I do postpone
a draft, then return to edit it more, then postpone it again,
etc. eventually when I send the message I'll have several
partially-composed drafts in various states that I need to go and
manually clean up. It seems like most email programs avoid this
problem by removing the draft as soon as its selected for editing
again, and I propose that sup do the same.
Anyway, I've probably run into several other little things that I
didn't capture in this email, but I'll hopefully remember them
later. If anyone has feedback on any of the above, (and actually read
this far!), then I'll appreciate getting it.
Otherwise, like I said, I hope to start trying to implement some of
these ideas, and when I do, I'll of course come back with separate new
threads for each.
-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/43f15a25/attachment.bin>
next reply other threads:[~2009-08-18 21:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-18 21:02 Carl Worth [this message]
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
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=1250629282-sup-8521@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