Behavior choice: Helix keymap #338

Strackeror · 2024-07-02T12:07:10Z

Hey there !

So I've been maintaining a personal use fork of dance with helix keybindings for a while now, but I've been seeing some of the keybinds making their way into the original codebase (with plans for more in #323), so I thought I'd just go ahead and try to remake it in a way that could fit into the main project.

So, here is a draft for a 'behavior' choice, where a user could choose which base keymap to use from a single setting. This is currently just the basic normal and select mode keymaps, without any of the helix menus, but it's a good starting point to show how it would look like in practice.

Currently the handling in the commands file is pretty naive, with a lot of duplication for the select mode. And I'm not sure on the backward compatibility when adding a new condition to a lot of keybindings like that, so I'm very open to discussion.

71 · 2024-07-07T02:58:47Z

Hey there, and thanks for the PR! I haven't looked at everything, but I overall agree with the idea!

I don't want to let the perfect be the enemy of the good, but one desire that I had when thinking about letting users switch between Kakoune/Dance/Helix keybindings is supporting multiple keymaps (e.g. non-QWERTY, macOS). Given the large number of keybindings in Dance I would have preferred to change the user's keybindings.json file automatically or to distribute alternative keybindings as extensions, though nothing beats the "behavior" as introduced by your PR in terms of convenience, so for now I'm perfectly fine with keeping things as-is.

Anyway, it is still good to have a "library" of Helix-specific keybindings; even if the way these keybindings are chosen changes in the future, such a change would be easy to automate following this change. But for now I think I would prefer marking the "behavior" setting as "experimental".

I'm also wondering if there might be an overlap between custom modes and behaviors (e.g. maybe instead of behaviors, we could have helix/normal and kakoune/normal modes).

And I'm not sure on the backward compatibility when adding a new condition to a lot of keybindings like that, so I'm very open to discussion.

This is a good point, I will think about it as well.

Strackeror · 2024-07-08T08:09:42Z

I... actually didn't think of generating a new extension with just keybinding and settings. I'll explore that idea, it feels like it'd be a better way to organize and avoid bloating the package.json further.

I'm not a fan of editing keybindings.json, mostly because I like to keep the vscode config files somewhat simple, it can very easily become a mess to manage with settings sync, profiles, the different configuration levels... It's a big reason I kept maintaining an actual fork of dance instead of just config files :)

The more I think about it, the more I think just having 'namespaced' helix modes and keeping the current kakoune modes as default is probably the least likely to break anything, and also the most simple to handle. Makes it a bit harder to show it as 'experimental' though, since you'd just change the default mode.

Strackeror · 2024-07-10T12:31:02Z

Okay, so, turns out making a basic extension with a bunch of keybinds and setting overrides was pretty easy !

It seems to work pretty well, with a couple caveats :

The extension contribute setting for overriding default configurations can't merge or do anything complex, which leads to some duplication between the package builders. I didn't think it was worth factoring that duplication yet, but my mind could easily be changed.
To avoid having to ignore all the keybinds in the base extension, I went ahead with the namespaced modes idea. It's currently very basic and just some basic string replacement when switching modes and generating keybinds, so that could probably be improved, but i'm not sure on the exact way yet.

Apart from that, I like it a lot better as a starting point. It's a bit barebones and missing some helix behaviors, but it's probably a better idea to defer those to separate PRs.

Remove category field from package.json

71

Thanks a lot! Sorry again for the delay.

I haven't looked at everything though I did skim over the files (and left a few comments, though they're primarily nits / code style).

Seeing the helix: select commands inline like that while knowing that they won't "bloat" the extension is pretty cool!

I think I'm mostly worried about code duplication; I think that I'd like to get to a point where Dance is Dance "Core" + Dance "Kakoune" (or Dance "Helix"), so we would benefit from reusing the same code/assets/package.json build machinery for all extensions.

.vscode/launch.json

71 · 2024-07-18T13:44:54Z

package.build.ts

@@ -22,7 +22,7 @@ const builtinModesAreDeprecatedMessage =
  "Built-in modes are deprecated. Use `#dance.modes#` instead.";

 const modeNamePattern = {
-  pattern: /^[a-zA-Z]\w*$/.source,
+  pattern: /^[a-zA-Z]\w*\/?\w*$/.source,


Suggested change

pattern: /^[a-zA-Z]\w*\/?\w*$/.source,

pattern: /^[a-zA-Z]\w*(\/\w+)$/.source,

Wait, doesn't that regex force having a slash somewhere ? I think a ? is missing after the group maybe ?

package.build.ts

71 · 2024-07-18T13:46:13Z

meta.ts

@@ -655,6 +653,36 @@ function getKeybindings(module: Omit<Builder.ParsedModule, "keybindings">) {
  ].sort((a, b) => a.command.localeCompare(b.command));
 }

+export function generateIgnoredKeybinds(


nit: spelling

Suggested change

export function generateIgnoredKeybinds(

export function generateIgnoredKeybindings(

Could you also add a documentation string? By looking at the source code I can fairly easily know what it does, but the name itself isn't enough to understand what is returned.

meta.ts

extensions/helix/package.build.ts

71 · 2024-07-18T14:13:32Z

extensions/helix/package.build.ts

+        "": {
+          hiddenSelectionsIndicatorsDecoration: {
+            after: {
+              color: "$list.warningForeground",
+            },
+            backgroundColor: "$inputValidation.warningBackground",
+            borderColor: "$inputValidation.warningBorder",
+            borderStyle: "solid",
+            borderWidth: "1px",
+            isWholeLine: true,
+          },
+        },
+        "input": {
+          cursorStyle: "underline-thin",
+        },


If these two entries are omitted does Dance stop working normally?

From quick testing, it doesn't, I just copy pasted the base settings because I wasn't sure what to with those.

Strackeror · 2024-07-18T18:50:56Z

Thanks a lot! Sorry again for the delay.

I haven't looked at everything though I did skim over the files (and left a few comments, though they're primarily nits / code style).

Seeing the helix: select commands inline like that while knowing that they won't "bloat" the extension is pretty cool!

I think I'm mostly worried about code duplication; I think that I'd like to get to a point where Dance is Dance "Core" + Dance "Kakoune" (or Dance "Helix"), so we would benefit from reusing the same code/assets/package.json build machinery for all extensions.

Yah, no worries, there's no hurry, and this thing's become a sizeable PR 😅.

I'll have to think about how to deduplicate the package generating code, I'm not sure exactly which part would benefit from abstracting yet.
I'm frankly not sure what a 'Core' dance would include. Right now in the keybind definitions, "core" more of a catchall for helix+kakoune. Using it like that would result in this very weird and incomplete intersection of the two, and I don't think that's the ideal way to go.

71 · 2024-07-20T05:02:22Z

I'll have to think about how to deduplicate the package generating code

If you'd like I can take care of this; we could submit your PR soon (either to master or to some other branch, releasing the Helix extension as "pre-release" only or waiting to release it) and I'll look into deduplicating some of the stuff.

I'm frankly not sure what a 'Core' dance would include

For me, it would include all the Dance commands and API, but none of the keybindings. That way you would install the "Kakoune keybindings" or "Helix keybindings", both of which would depend on "Dance Core", and you would only get the keybindings you need.

With this model, I guess we would create a new extension "Dance Core", and migrate the current extension to be "Dance with Kakoune keybindings".

Right now in the keybind definitions, "core" more of a catchall for helix+kakoune.

"Dance Core" (the extension) would be different from core keybindings; core keybindings are more "common" or "shared" keybindings which would be included in both extensions.

Strackeror · 2024-07-20T10:45:34Z

If you'd like I can take care of this; we could submit your PR soon (either to master or to some other branch, releasing the Helix extension as "pre-release" only or waiting to release it) and I'll look into deduplicating some of the stuff.

I'd be okay with that, if that works for you ! It'll also allow me to submit the couple other helix-related PRs I'm working on :)

"Dance Core" (the extension) would be different from core keybindings; core keybindings are more "common" or "shared" keybindings which would be included in both extensions.

Ah I see, that makes a lot more sense when thinking of it this way. Might make sense to rename the 'core' category to avoid confusion in that case, but that's a small issue.

71

Sorry, I again did not much time to review until now.

I tried it out and it's nice! I opened a PR in Strackeror#1 to work on reusing some of the logic.

71 · 2024-08-16T14:29:38Z

src/commands/misc.ts

- * | Add the digit 9 to the counter | `9` (core: normal), `NumPad9` (core: normal) | `[".updateCount", { addDigits: 9 }]` |
+ * | Title                          | Keybinding                                                                                   | Command                              |
+ * | ------------------------------ | -------------------------------------------------------------------------------------------- | ------------------------------------ |
+ * | Add the digit 0 to the counter | `0` (core: normal), `NumPad0` (core: normal), `0` (helix: select), `NumPad0` (helix: select) | `[".updateCount", { addDigits: 0 }]` |


Does (core: normal, helix: select) not work? I don't remember if I implemented this, but I can see several keybindings in your PR (and even from before your PR) which could benefit from such a syntax.

As of right now it doesn't (I would have felt like quite an idiot if it did !). But it actually sounds like a good idea, so I'll see if I can implement that, it would help make things less verbose !

Well, I did it. It's separated by ; instead of , because otherwise the regex would conflict with the one for tags, but it seems to work quite well

src/api/modes.ts

package.build.ts

It's not consistent, but vscode sometimes gives me errors about the semver for the helix package not being valid, and indeed it seems leading zeroes are not valid semver, so switching to a tag to mark the prerelease

akdor1154 · 2024-11-05T02:30:23Z

hey guys, where's this sitting? any way an excited bystander can help get this over the line? :)

daedroza · 2025-02-11T16:09:33Z

Any updates to this?

71 · 2025-02-22T07:45:37Z

package.build.ts

@@ -22,7 +22,7 @@ const builtinModesAreDeprecatedMessage =
  "Built-in modes are deprecated. Use `#dance.modes#` instead.";

 const modeNamePattern = {
-  pattern: /^[a-zA-Z]\w*$/.source,
+  pattern: /^[a-zA-Z]\w*(\/\w+)?$/.source,


You were absolutely right, I had this in mind.

71 · 2025-02-22T07:53:27Z

Hey all. I'm sincerely sorry for the delay; I had some minor anxiety looking at GitHub notifications for the past ~6 months, but am going to try to get this submitted soon.

Before I merge this PR, can someone please help with the following:

Review the PR, preferably someone with experience with Helix, and who has submitted code to Dance before. Not asking to be nitpicky, "Works, LGTM" would be enough.
Write instructions on how to use the Helix extension. I'm mostly worried about conflicts between Dance "Main" and Dance "Helix" defaults. Similarly, "Works without any additional configuration" would be enough.

71 · 2025-02-22T07:54:25Z

src/api/modes.ts

@@ -62,3 +61,22 @@ export async function toMode(modeName: string, count?: number) {
      }));
  }, 0);
 }
+
+/**
+ * Returns the {@link Mode} with the given name, prioritizing one that's within the name "namespace"


optional nit: my bad, my suggestion had a typo

Suggested change

* Returns the {@link Mode} with the given name, prioritizing one that's within the name "namespace"

* Returns the {@link Mode} with the given name, prioritizing one that's within the same "namespace"

jwhitaker-gridcog

Review the PR, preferably someone with experience with Helix, and who has submitted code to Dance before

I don't strictly match either of those criteria: my only PR is small and still in review, and I'm a Helix novice, who wants to use Dance with this PR to learn Helix.

I'm not familiar enough with Helix to be able to point out any glaring differences in behaviour here. However, I have been running this branch as my daily driver at work for a long time now, and it's been reliable and useful, and I have no issues with any of its defaults.

It is somewhat incomplete in terms of all the commands that are available, however I personally am not bothered by that; I wouldn't want to attempt to achieve perfection before merging this, I'd much rather have the basics in place and settled. It's easy enough to add (and contribute!) any glaring omissions (btw - i have 80% of a match menu :) ).

jwhitaker-gridcog · 2025-02-22T15:41:54Z

package.build.ts

+
+    "package-helix:pre": `cd extensions/helix && yarn run package:pre`,
+    "publish-helix:pre": `cd extensions/helix && yarn run publish:pre`,


When I run these, I get an error - "can't find extension/assets/dance.png". I believe vsce is whinging about assets being a symlink.
I'm confused why you guys aren't hitting this though - are you developing on Windows by any chance? I'm on Linux. Am I just building it wrong?

I'm looking into if bumping to @vscode/vsce 3.2.2 gets it working for me - they've added a --follow-symlinks option, however this is very recent (newer than this PR).

following up, yes bumping vsce and adding --follow-symlinks in a few places gets things building. However I'm confused why it's evidently just me being hit by this?

I hit the same issue (macOS). Using @vscode/[email protected] with --follow-symlinks as suggested fixed it, thanks! Opened Strackeror#2 to fix.

71 · 2025-02-23T08:00:10Z

I'll try to daily-drive this for a few days.

My keybindings with "when": "editorTextFocus && dance.mode == 'normal'" don't work when I'm in helix/normal. This is somewhat expected, but I wonder if it would be worth having something like dance.mode == '*/normal' or something in the future. Maybe the default Dance modes are in dance/normal, and we add a new setting dance.defaultModeNamespace (set to helix in the Helix extension)? Doesn't need to be fixed in this PR though.

Strackeror · 2025-02-23T10:18:46Z

Oh boy, been a while since there's been some activity in here :)
When clauses have a match operator, so you could technically already go for dance.mode =~ /^(.+\/)?normal$/ or something of the sort.
It doesn't feel super clean though, maybe we could add some other when clause variables for separate namespace and modes ?

It is somewhat incomplete in terms of all the commands that are available, however I personally am not bothered by that; I wouldn't want to attempt to achieve perfection before merging this, I'd much rather have the basics in place and settled. It's easy enough to add (and contribute!) any glaring omissions (btw - i have 80% of a match menu :) ).

This branch is definitely meant as a first step for other helix integrations down the line. I have a much more complete reproduction of helix behavior down in my spacemenu branch, including space, match, goto and bracket menus, and much more complete treesitter integrations. The plan is to progressively clean up and PR some of those into the main repo :)

kabouzeid · 2025-02-23T14:40:17Z

gg doesn't go to start of file and gi should be gs (both fixed here: Strackeror#3)

mm shouldn't start a selection but only jump. also it should go to the enclosing pair, not the next pair to the right.

mim and mam or missing completely.

kabouzeid · 2025-02-23T14:43:26Z

Would it make sense to include the space, window, ] and debug menus as well, or is it out of scope? I currently have them in my personal config.

71 · 2025-02-23T17:00:40Z

Agreed, "chasing perfection" is the main reason why I couldn't open GH notifications for several months, so even if it's incomplete I'd be happy to merge the PR. Just want to make sure it's a good basis for future changes.

@kabouzeid These will likely be useful (thanks for the input!), but won't block this PR from being submitted first.

kabouzeid · 2025-02-23T17:19:43Z

I'm not sure how much sense it makes to have the Helix "helper" extension. As it stands, the main extension defines the keybindings, while the helper extension only adds the modes and menus. I don’t see an easy way to move the keybindings to the helper extension as well.

Given that the two can't be cleanly separated, it might make more sense to keep everything in the main extension rather than adding complexity.

The user can still easily enable Helix mode with a single config option: dance.defaultMode: 'helix/normal'.

kabouzeid · 2025-03-01T12:02:18Z

Also just noticed, currently the registers for yank, delete etc are set to the system clipboard. Should be the * register.

71 · 2025-03-04T10:14:53Z

@kabouzeid I agree, ideally they would also be part of the same extension but I'm worried about scaling: the Dance extension registers ~300 keybindings, and adding an Helix mode (then later different keybindings for macOS, then different keybindings for different keyboard layouts like AZERTY) could easily bump this to >500 keybindings. These bloat views like "Keyboard Shortcuts", and I haven't benchmarked anything but it's possible VS Code is not happy to evaluate the "when" clause for hundreds of keybindings when the mode is changed.

That said I'm open to ideas which would allow us to keep a single extension without significant drawbacks (or benchmarks which prove the drawbacks mentioned above aren't that bad).

cloudhan · 2025-03-04T15:49:06Z

How about stop worrying about the imperfection and just merge it, make a preview release and see how it goes. It is not a mission critical piece of software that once pushed to a planet, which is a hundred million miles away from the Earth, cannot be reverted. VSCode made it quite easy to switch between versions.

71 · 2025-03-06T10:21:19Z

@cloudhan Unfortunately the extension doesn't currently build. I proposed a solution in Strackeror#2 but as pointed out by the author of this PR, it would be better to have different files rather than symlinks. I will tackle it when I get some time, but it may not happen for a while (so, PRs welcome).

Edit: I submitted Strackeror#4 to fix this.

cloudhan · 2025-03-08T04:22:35Z

@71 On Windows 11, the only problem I encountered is error: unknown option '--follow-symlinks' and remove all those flags builds the extension flawlessly.

EDIT: not yet, seem vsce is dispatch in a wrong folder, aka, not from dir where package.json is located, but from the project root.

cloudhan · 2025-03-08T06:04:47Z

Here is some build artifact on Windows
dance-0.5.15-pre1.vsix.zip
dance-helix-keybindings-0.5.15-pre1.vsix.zip
extract and install if someone want to test it out.

src/commands/edit.ts

And: - Update LICENSE to ~2025. - Add purple Dance logo for Helix.

71 · 2025-03-13T09:02:56Z

Thank you all again for bearing with me here, especially @Strackeror! Sorry again for the delay. We now have a strong base to build on, so future changes should be far simpler to merge.

bezbac · 2025-03-13T09:23:04Z

I've been using Dance with a custom helix-like set of keybindings for more than a year now, and I just wanted to thank everybody involved in getting this PR merged! The quality of this extension is exceptionally high, and by integrating helix bindings, I hope it will see additional adoption.

Thanks maintaining it. Really amazing work! 🫶

akdor1154 · 2025-03-13T09:28:26Z

Awesome stuff guys, thanks heaps :)

kabouzeid · 2025-03-13T14:22:09Z

Awesome, thanks! Let's refine and add the missing functionality with focused PRs that can be merged quickly :)

Strackeror · 2025-03-14T12:29:34Z

Ayyy, it's done ! Glad this is getting out there, more improvements coming soon :)

Strackeror force-pushed the choose-behavior branch from 41851a8 to cc565bc Compare July 3, 2024 23:04

Behavior choice: Basic helix keymap

a5c3e7d

Strackeror force-pushed the choose-behavior branch from cc565bc to a5c3e7d Compare July 3, 2024 23:07

Strackeror force-pushed the choose-behavior branch 2 times, most recently from 6c0c8bd to 1916ec6 Compare July 10, 2024 12:22

Strackeror marked this pull request as ready for review July 10, 2024 12:40

Behavior choice: Helix keymap as an extension

7baaa30

Strackeror force-pushed the choose-behavior branch from 1916ec6 to 7baaa30 Compare July 10, 2024 12:43

Strackeror added 4 commits July 15, 2024 15:43

Fix shift+c in helix modes

7e1a759

Remove category field from package.json

Fix missing editorTextFocus condition

8babb7f

Add % binding to helix

1b71b25

Fix binding: Shift+R

91bc9d6

71 reviewed Jul 18, 2024

View reviewed changes

Strackeror force-pushed the choose-behavior branch from 415cac9 to 438baf3 Compare July 18, 2024 16:50

PR Fixes

10e50a9

Strackeror force-pushed the choose-behavior branch from 438baf3 to 10e50a9 Compare July 18, 2024 16:53

Strackeror added 2 commits July 31, 2024 13:37

Fix typos and title, add toggle indices

a1f82a7

Add numpad bindings to select mode

38be042

71 reviewed Aug 16, 2024

View reviewed changes

Strackeror and others added 4 commits August 17, 2024 17:37

PR Fixes

0887662

Improve keybind parsing for less verbose definitions

47c2737

use symlinks

77882fd

Fix invalid pre-release version string

e908946

It's not consistent, but vscode sometimes gives me errors about the semver for the helix package not being valid, and indeed it seems leading zeroes are not valid semver, so switching to a tag to mark the prerelease

71 reviewed Feb 22, 2025

View reviewed changes

71 mentioned this pull request Feb 22, 2025

Custom formatting of display name #359

Open

jwhitaker-gridcog approved these changes Feb 22, 2025

View reviewed changes

fix go to menu items

943ffc1

cloudhan mentioned this pull request Mar 8, 2025

Unify build version of helix extension #363

Closed

71 approved these changes Mar 11, 2025

View reviewed changes

src/commands/edit.ts Outdated Show resolved Hide resolved

src/commands/edit.ts Outdated Show resolved Hide resolved

Strackeror force-pushed the choose-behavior branch from 04a891c to 257713d Compare March 11, 2025 13:04

Strackeror and others added 2 commits March 11, 2025 14:08

Keymap: Add switch back to normal mode on some keybinds

f09050a

remove symlinks

257713d

And: - Update LICENSE to ~2025. - Add purple Dance logo for Helix.

71 merged commit 036cdfd into 71:master Mar 13, 2025
2 checks passed

	pattern: /^[a-zA-Z]\w\/?\w$/.source,
	pattern: /^[a-zA-Z]\w*(\/\w+)$/.source,

	export function generateIgnoredKeybinds(
	export function generateIgnoredKeybindings(

	* Returns the {@link Mode} with the given name, prioritizing one that's within the name "namespace"
	* Returns the {@link Mode} with the given name, prioritizing one that's within the same "namespace"


		"package-helix:pre": `cd extensions/helix && yarn run package:pre`,
		"publish-helix:pre": `cd extensions/helix && yarn run publish:pre`,

Behavior choice: Helix keymap #338

Behavior choice: Helix keymap #338

Conversation

Strackeror commented Jul 2, 2024 • edited Loading

71 commented Jul 7, 2024

Strackeror commented Jul 8, 2024 • edited Loading

Strackeror commented Jul 10, 2024 • edited Loading

71 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Strackeror Jul 18, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Strackeror commented Jul 18, 2024

71 commented Jul 20, 2024 • edited Loading

Strackeror commented Jul 20, 2024

71 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

akdor1154 commented Nov 5, 2024

daedroza commented Feb 11, 2025

Choose a reason for hiding this comment

71 commented Feb 22, 2025

Choose a reason for hiding this comment

jwhitaker-gridcog left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

71 Feb 23, 2025 • edited Loading

Choose a reason for hiding this comment

71 commented Feb 23, 2025

Strackeror commented Feb 23, 2025 • edited Loading

kabouzeid commented Feb 23, 2025

kabouzeid commented Feb 23, 2025 • edited Loading

71 commented Feb 23, 2025

kabouzeid commented Feb 23, 2025

kabouzeid commented Mar 1, 2025

71 commented Mar 4, 2025 • edited Loading

cloudhan commented Mar 4, 2025

71 commented Mar 6, 2025 • edited Loading

cloudhan commented Mar 8, 2025 • edited Loading

cloudhan commented Mar 8, 2025

71 commented Mar 13, 2025

bezbac commented Mar 13, 2025

akdor1154 commented Mar 13, 2025

kabouzeid commented Mar 13, 2025

Strackeror commented Mar 14, 2025

Strackeror commented Jul 2, 2024 •

edited

Loading

Strackeror commented Jul 8, 2024 •

edited

Loading

Strackeror commented Jul 10, 2024 •

edited

Loading

Strackeror Jul 18, 2024 •

edited

Loading

71 commented Jul 20, 2024 •

edited

Loading

71 Feb 23, 2025 •

edited

Loading

Strackeror commented Feb 23, 2025 •

edited

Loading

kabouzeid commented Feb 23, 2025 •

edited

Loading

71 commented Mar 4, 2025 •

edited

Loading

71 commented Mar 6, 2025 •

edited

Loading

cloudhan commented Mar 8, 2025 •

edited

Loading