`x` and `shift+x` broken in `0.5.13`

[vbn]

in 0.5.11, the command x meant select current line, then keep hitting it to select the next line, and shift+x meant to select the current line and keep hitting it to extend the selection to subsequent lines.

with 0.5.13 the command x selects the line, but doesn't move to the next line after hitting x again. shift+x doesn't do anything. this breaks my workflow quite a bit, since it seems i like using both the commands quite a lot. i also couldn't find any dance command that would emulate this behavior.

is this change expected or a bug?

for now, i have rolled back to 0.5.11 so i am not blocked.

[losnappas]

iirc this is expected, kakoune works that way now too.

You can restore old behavior of x with this keybind (mostly):

  {
    "key": "x",
    "command": "dance.run",
    "when": "editorTextFocus && dance.mode == 'normal'",
    "args": {
      "commands": [
        "dance.select.right.extend",
        "dance.selections.expandToLines"
      ]
    }
  },

[71]

Hey there,

This is working as intended, since that keybinding changed in Kakoune a while ago. I didn't like the change to x either at first but this comment convinced me to switch to it.

If you prefer the old behavior, you can restore it by adding the following keybinding to VS Code:

  {
    "key": "X",
    "when": "editorTextFocus && dance.mode == 'normal'",
    "command": "dance.select.line.below",
  },
  {
    "key": "Shift+X",
    "when": "editorTextFocus && dance.mode == 'normal'",
    "command": "dance.select.line.below.extend",
  },
  {
    "key": "Alt+X",
    "when": "editorTextFocus && dance.mode == 'normal'",
    "command": "dance.selections.expandToLines"
  },
  {
    "key": "Shift+Alt+X",
    "when": "editorTextFocus && dance.mode == 'normal'",
    "command": "dance.selections.trimLines"
  },

(@losnappas thanks for answering!)

[vbn]

thanks @71 and @losnappas . i have updated my keybindings to restore the old x and shift+x behavior. also, restored the space behavior to remove all secondary selections. so i'm back up to speed with my muscle memory shortcuts.

i appreciate the link to the comment arguing for the kakoune way. however, i respectfully disagree with breaking existing users though, especially after being used to these shortcuts for 3-4 years now. a notice after the extension update would also help in the future to deal with breaking changes.

closing the bug now.

[71]

@vbn I agree, changing the keybindings all of a sudden wasn't great. They had been this way in the prerelease for a long time so I wrongly assumed that nothing significant changed during the update. Unfortunately there is no great way to configure Dance keybindings yet, so I'm not sure how I could have provided a backwards compatible update to the keybindings though.

Perhaps in the future I could add additional conditions to keybindings provided by Dance (e.g. "when": "dance.builtinKeybindingsVersion > 4" where builtinKeybindingsVersion can be configured (so new users get the most recent keybindings, and previous users get the old ones), but for now that seems overkill especially since Dance is still pre 1.0.

In the future I will at least try to communicate that such changes will arise when publishing a new version, and how to roll them back.

[vbn]

thanks @71. i agree that the version conditions would be an overkill, just some sort of "default keybindings changed" notification on upgrade would be enough 👍

[71]

FYI, following this suggestion I added a CHANGELOG file following changes to commands in the last version. It isn't yet surfaced in VS Code, but at least there's a way to see what changed recently now.