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.

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.

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.

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.

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.

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.

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

@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.

@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.

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.

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.

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! 🫶

Awesome stuff guys, thanks heaps :)

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

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

hey all, is there any documentation showing how to use these? I'm on pre-release and can't seem to find any settings for enabling helix mode

Hi @lukepighetti, the Helix keybindings haven't been released to the VSCode Marketplace yet, so your best bet is to build from source assuming you have NodeJS installed:

git clone https://github.com/71/dance
cd dance/extensions/helix
npm i
npm i -g yarn  # for vsce
npm run package

This produces a VSIX file, which automatically enables Helix keybindings once installed in VSCode.

I've built a copy from the master branch at commit 4e3d259 if you'd like the extension without building it yourself: dance-helix-keybindings-0.1.0.vsix.zip
Just rename the extension back to .vsix, then you can press Ctrl+Shift+P -> Extensions: Install from VSIX... to use it.

WHOA

Insane work guys. Thank you for making this possible

Hey all,

First, appreciate you packaging the extension @ongyx. Although in general, .vsix files can be pretty dangerous (as VS Code extensions can do pretty much anything on your computer)¹, so I'd advise anyone that uses it to open it up first (it's a .zip file with a different extension) and review the code (there shouldn't be much outside of package.json).

Secondly, I'm trying to publish the extension to the store but have hit a few issues while making sure it works. Notably, after loading the Helix extension the normal Dance modes disappeared, but that doesn't happen all the time. That is, helix/normal exists, but normal doesn't. Another problem is that the command palette only displays Dance commands on normal mode, not on helix/normal (edit: fixed in f3117fd).

Edit: It looks like it is intended for configurationDefaults (used by the Helix extension to add Helix modes to Dance) to overwrite, not contribute modes: microsoft/vscode#168498. I'm not sure why Dance sometimes receives configurations that are merged instead (verified via the debugger and vscode.workspace.getConfiguration). I think we have several ways to fix this:

1. Instead of contributing modes via dance.modes, we use a JS API where we can properly contribute modes instead of overriding them. The downside being that now the Helix extension doesn't simply have a package.json file, it also has some script.
2. We completely overwrite the insert and normal modes instead of adding alternatives called helix/normal and helix/insert. I think this would also remove some confusion over which mode is currently loaded, which mode needs to be configured in the settings, and which mode keybindings apply to, so this might actually be better this way.
   • But thinking about it, if we use the same mode names then the default keybindings given by Dance will be the same, so we'll need a way of disabling them somehow.
3. We modify the Helix extension so that it contributes both default Dance modes and its own modes. That's an easy fix, but feels hacky, especially if we consider future versions of Dance and Helix that have slightly different default keybindings.
4. We manually load the default modes in Dance and merge them with the ones given to us by VS Code. This should similarly be easy to do, but similarly feels hacky to me.
5. We split Dance into Dance Core and Dance; Dance Core doesn't have builtin keybindings or modes, just commands needed for them.

Yup, that's why I included the build instructions above, it's unfortunate that VSIX builds aren't reproducible or I would've included a file hash. I was going to mention the overriding part, but you beat me to it :)

As for the solutions you described, option 2 is ideal because you can just de-activate the Helix extension to get the Dance keybinds back. It already works with the current build (the default mode changes too), but the user has to do this manually as the VSCode API doesn't have a way to de-activate extensions programmatically yet.

Alternatively (adding on to the overwrite idea):

• Change all instances of vscode.workspace.getConfiguration(extensionName) to load the Helix extension's configuration depending on a user setting (dance.keybind?)
• Add a custom where clause context of the same name, and modify the existing keybind clauses for both to include something like ... && dance.keybind == 'dance' / ... && dance.keybind == 'helix'
  This allows the Dance and Helix keybindings to coexist when the Helix extension is installed, otherwise the two would conflict.

Is this usable? I can't get it to switch between helix/* modes

It should work once you've installed the VSIX extension, it automatically overrides your default Dance mode.

I'm also having issues - when pressing i I get mode "insert" does not exist - is the helix extension not supposed to change the default i binding to switch to mode helix/insert? Same for c, o and so on.

I could've sworn this was the case a couple weeks ago when I tried it & it worked properly

I don't have any custom keybindings for those keys. The only dance-related bindings i have are around the surround feature

I see that same error, @merlindru. It was working earlier this week.

@merlinaudio @tshort Extremely late response, but please see #338 (comment). TL;DR: unlike what I expected, VS Code doesn't merge contributed settings, and instead seems to pick one of them arbitrarily.

For now, I'll try to fix it quickly by doing the merge manually in Dance, but I'm also working on having separate extensions for Kakoune and Helix based on one "core" extension in #391.

Edit: this should be fixed by #392. Could someone test and report if it works?

is there any reason why this isn't available on the VSCode extension marketplace, or did I miss something?

@lukepighetti The bug I described in #338 (comment) was too big to submit to the marketplace IMO. Once I submit the fix I'll upload it there.

After a long time, the extension is now available in the marketplace!

yay! where's the best place to leave feedback for this? and how do we enable the helix bindings?

where's the best place to leave feedback for this?

In the Dance repo, in issues or discussions.

and how do we enable the helix bindings?

Install the Helix keymap and it should set the default mode to helix/normal, and you'll be set.