From: cworth@cworth.org (Carl Worth)
Subject: [sup-talk] Thoughts on simplifying thread-view-mode keybindings
Date: Wed, 09 Sep 2009 10:24:13 -0700 [thread overview]
Message-ID: <1252516237-sup-9414@yoom.home.cworth.org> (raw)
I only just barely got my proposal for new 'a' and 'd' keybindings
into master, and now I'm rethinking them to some extent.
Take a look at the existing keybindings for navigating away from the
current thread:
.a : Archive this thread and kill buffer
.d : Delete this thread and kill buffer
.s : Mark this thread as spam and kill buffer
.N : Mark this thread as unread and kill buffer
,a : Archive this thread, kill buffer, and view next
,d : Delete this thread, kill buffer, and view next
,s : Mark this thread as spam, kill buffer, and view next
,N : Mark this thread as unread, kill buffer, and view next
,n : Kill buffer, and view next
]a : Archive this thread, kill buffer, and view previous
]d : Delete this thread, kill buffer, and view previous
]s : Mark this thread as spam, kill buffer, and view previous
]N : Mark this thread as unread, kill buffer, and view previous
]n : Kill buffer, and view previous
Each of these keybindings involve two keys, and each command involves
two actions. But the order of the keybindings and actions are reversed.
Imagine, for a moment, what would happen if the keybinding order was
"fixed" to match the order of the commands, (that is, things like "a,"
for archive, then view next). With that change, we would no longer
need dual-key bindings as the single-key actions could be easily
combined with the same effect.
That is, we could have just:
a : Archive this thread
d : Delete this thread
s : Mark this thread as spam
N : Mark this thread as unread
., x : Kill this buffer
, : View next thread
] : View previous thread
That's definitely a simpler amount of documentation to have to grasp,
and shouldn't be any less work to actually use, (other than the pain
of having to retrain muscle memory to do things like "a," instead of
",a").
The next tweak I'd make is to choose keybdindings for 'next' and
'previous' that more obviously go together. (Such as '[' and ']', but
then I think I'd also expect '[' to mean previous and ']' to mean next
which might wreak havoc on muscle memory).
Finally, I'd personally still want a single-key keybinding to do my
most frequent combination, (such as archive-and-view-next as with the
current 'a' that just landed in master), but maybe that makes more
sense to happen only in a hook.
What do you all think?
Me, I'm pretty new to sup, so the muscle-memory thing isn't *too* big
an issue. Is sup still young enough as a tool to be able to accept
interface changes like this?
-Carl
reply other threads:[~2009-09-09 17:24 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=1252516237-sup-9414@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