Modes all the way

[samholmes]

I want to start a conversation about "modes vs chords".

A chord is a keybinding of multiple keys at the same time, like C-a or A-b. Chords are constrained to physics because you only have so many keys and so many fingers to use to make a chord.

Modes are not constrained by physics because you can navigate in and out of an infinite amount of modes. People consider chords to be simpler to remember, but I argue this is a naive understanding. It becomes clear this is wrong when you realize that modes are in fact what ever computer user uses today. When a user opens their web browser, their computer changes modes; it is not in web browser mode. When the user opens a context menu, the mode has changed for their computer. Users are navigating modes as their computer state changes without realizing this is the underlying design principle.

There is a narrative to be made that modes win over chords. But why then do users "prefer" chords for keybindings over "modes"? The answer to this is sort of complex, but in summary: they don't. Users prefer modes without realizing it because they use modes all the time, but the modes don't feel like modes because they're so seamless and not obstructing their experience. It's when users are required to keep track of modes that they voice their disdain. I think this is the simple answer to this question: users like modes that require little to no cognitive burden and settle for the cognitive burden of chords when modes have cognitive burden.

Now I have set the stage for my argument: use modes wherever possible with the least cognitive burden. What do I mean by lowering cognitive burden? Well, if a user has to track that they're in a mode with no visual indication or aid, then this is cognitive burden. A user doesn't have to track that they're in web browser mode because their window manager will indicate to them that the browser is in focus visually.

Helix has lowered cognitive burden for modal editing UX similar to Vim whether it is realized or not. I'm writing this to make it abundantly clear. For example: most modes have a menu, even the command mode has visual indication of the various commands that are being prepared. This makes us realize that a motion is simply a path through a modal state machine (e.g. miw normal -> match mode -> inner select mode -> select inner word).

Now we can see that menus could theoretically be applied for every mode; but what would that experience look like? Perhaps if we had every key press printed in a status bar at the bottom then the user wouldn't need to remember that they pressed a particular key (lowering cognitive burden FTW). Then the menu that we see for some modes right now would look a lot like the context menu we have for command mode (this is an auto-complete UX). Woah, so as we perform "motions" we'd really just be navigating through various modes. Imagine a user types mi, then what they'd see printed in the status bar could be something like MATCH: mi, then once they press ESC key, NORMAL: mi<esc>. Then as they press more keys the print keeps printing characters in the status bar; NORMAL: mi<esc>%shello world<enter>. Keys that don't do anything in a mode could be shown and indicated in a different color; user no longer requires opening a manual to understand if they can bind a key without overwriting some default (discoverability). This UX design really pushes for lowering cognitive burden and leads to discoverability of modes and even how keys are written for configuration.

Now, back to the discussion of "chords". I think with a UX like this, the cognitive burden being lower, this opens the door for even more modes and complex/lengthy motions, therefore replacing the need for chords. Chords like C-u and C-d could be replaced with a scroll mode perhaps with a key like z, the user can see they're in this mode in the status bar SCROLL: z, and as they navigate up and down (SCROLL: zuudu) and then exit back to normal mode (NORMAL: zuudu<esc>).

The user may not want a context menu all the time, so it would be reasonable to be able to hide/show it with ? (showing it by default). This state change is a setting change (which are sorta akin to env vars) and their state apply to all modes, which is nice.

What's more, with such a UX in place, now users can quickly learn the tool and extend in with new keybindings in various modes and even new modes entirely which could be exported and shared between users much like Vim plugins are shared today.

Shipping helix with a Deno runtime and using TypeScript/JavaScript as it's plugin scripting language would allow for a secure way to share customizations as modules hosted and distributed on the web via URLs! This sort of plugin system or extensibility is kinda like the choice for Lua as the scripting language for Neovim, but it's better because TS/JS is a better scripting language and Deno is a better runtime then node (written in rust, compatible with most web APIs, URL imports, sandbox security model, etc).

What do you think?

PS: Originally a long-winded message on Matrix; I moved it to GitHub as it was suggested to be more appropriate.

[auronandace]

I quite like the idea of showing the keystrokes in the statusbar. I can think of a few issues though:

1 - Where on the status bar should it be shown?
2 - How much space should it be permitted to take up?

Sounds good if you can toggle it on and off. I can see it being useful to know what you just pressed. It would seem excessive if you just let it contain absolutely everything though.

As regards the Deno idea that sounds like something for a separate thread. No idea how fleshed out the current ideas are on plugins. It is a topic that seems to come up frequently on Matrix.

[gabydd]

In terms of plugins if you look a bit up in the matrix there is some more context, as for keystrokes in the statusline they are already rendered on the right side of the prompt under the statusline (is this what you are looking for)

[samholmes]

@gabydd The keystrokes aren't rendered on the right side of the prompt in the statusline...

@auronandace I think a good place for the rendering of "motion data" (as I'll refer to it) is in the status line where the buffer name is currently, right next to the mode indicator. In this image, it'd replace the part that says "package.json":

Instead, we can place the buffer name to the right size near the line/column numbers. That right side area could be a customizable "tray" of course.

The reason for the left side is because its colocated with the mode NOR, INS, etc. And that makes sense to see the mode change as you type your motion. It's also nice to transition from a motion statusline to a command statusline after pressing : for example. The UX seems cohesive by locating the motion data here.

I think the length of the motion could be limited to a certain number of characters and overflow would truncate the leading characters first (first in, first out), this way you can always see the most recent characters. I think apart of the design could clear the motion data after the motion "completes" which should be more rigorously defined, but an intuition to that idea is that miw is a completed motion whereas mr" is not complete yet.

On the idea to not show all characters, I understand. But it is nice to learn what the escape key looks like printed as a motion for configuration files. Though, I do see the value behind not showing these characters especially when entering insert mode or pressing escape key to "cancel" a motion. Perhaps a verbose mode could be enabled/disabled in order to get the full motion data information. I feel like each keybinding could define itself as either verbose or not in order to make it visible (verbose is false by default). Verbose set to "true" on a keybinding would hide it from the motion data rendering unless verbosity is enabled.

One idea is to have backspace character actually delete a character from the motion (while in non-verbose mode) and effectively undoing a keystroke. This is insanely useful for complex motions where you'd otherwise have to press escape key and start over from the start of the motion. This would be a beautiful design.

[cd-a]

Would it be possible to please format your initial post a bit? It's hard to read as a single paragraph.

[samholmes]

Ok. Hope that helps.