Skip to content

[DRAFT] Keyboard mode experiments #1964

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 16 commits into from
Closed

Conversation

Kn0rk
Copy link

@Kn0rk Kn0rk commented Oct 22, 2023

Set up

There is a fixedKeymap.ts file. So you can change keybindings there. I am using dvorak-programmer keyboard so mapping is probably pretty weird for you.

I don’t think it needs anything special to run other than setting up the environment to run the extension. It took a few adjustments (see commit) but it seems to work now on my work machine.

Architecture changes

A few notes on the changes I did.

It was a bit confusing how constructMergedKeymap works and is quite limiting. For every function we want to assign we need to define another setting group(e.g. cursorless.experimental.keyboard.modal.keybindings.scopes). I think we need an implementation that more freely allows us to map any “command” (green, ex, everyScope, scrollToCenter, …) to a specific handler function.

My Handler functions basically set a Target, set a Modifier or excecute an cursorless action.

The functions that are assigned in constructMergedKeymap should(?) be able to request constrained keystrokes. Like the everyScope handler will request a keystroke that is constrained to SimpleScopeType. (See Keybindings or change what layer is sampled next?)

I might not understand cursorless well enough yet. But adding modifiers to explicit targets helped me a lot to understand how cursorless works. Just adding things to that was a bit too magical initially. So not sure if tracking targets is actually necessary.

Keyboard bindings

I spend some time with the current keyboard bindings and the surrounding implementation. One roadblock is that we have much fewer keys than we can have voice commands. As such we need to rely on binding key sequences to increase the number of available commands we can input.

So for example we might bind as follows:

g: green
y: everyScope
v g: character

So if we want to select every character we would have to type y v g. However we know that the everyScope requires a scope. So by pressing y we know that the next key press has to select a scope.

To set that up with simple keybindings we get an explosion of bindings:

y g: everyScope + character
y z: everyScope + token
…
x g: next + character
x z: next + token

If we instead have multiple layers of keybindings we can assign every key multiple commands. Then each command could request the next key be a certain type. The everyScope would require a SimpleScopeType(?) as the next key.

Layer 0:
 g: green
 y: everyScope

Layer 1:
 g: character

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant