sup talk - Sep 2009 - Thoughts on simplifying thread-view-mode keybindings

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