Skip to content
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

x and shift+x broken in 0.5.13 #319

Closed
vbn opened this issue Nov 1, 2023 · 6 comments
Closed

x and shift+x broken in 0.5.13 #319

vbn opened this issue Nov 1, 2023 · 6 comments

Comments

@vbn
Copy link

vbn commented Nov 1, 2023

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
Copy link

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
Copy link
Owner

71 commented Nov 3, 2023

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
Copy link
Author

vbn commented Nov 3, 2023

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.

@vbn vbn closed this as completed Nov 3, 2023
@71
Copy link
Owner

71 commented Nov 10, 2023

@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
Copy link
Author

vbn commented Nov 10, 2023

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
Copy link
Owner

71 commented Dec 1, 2023

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.

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

No branches or pull requests

3 participants