-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Add normalModeKeyBindings and visualModeKeyBindings, remove otherModesKeyBindings #2726
Conversation
Travis tests have failedHey @chibicode, Node.js: 8npm test --silent
|
Travis tests have failedHey @chibicode, Node.js: 8npm test --silent
|
Hey @chibicode, TravisCI finished with status |
Ok, tests are now passing. @jpoon |
With the introduction of I think we should rename OtherModes to |
I haven't changed what |
@jpoon I came across this trying to search how to bind stuff in normal mode. Thanks for confirming for me that OtherModes is the same thing as normal mode. I was confused what that was for. (trying to remap ^ and $ to shift+h and shift+l I'm hoping that is possible) Edit: For anyone that comes across this later trying to do the same I figured out how to do it by adding this to my config. Also be sure to restart after making the change. I almost gave up and then thought to restart and that fixed it.
|
@chibicode i'm starting to think we should rename Also posed the question to our Slack: https://vscodevim.slack.com/archives/C0ENQMTUM/p1529045308000348 |
@jpoon Per discussion on Slack, I've updated this so that the config now only supports |
README.md
Outdated
```json | ||
"vim.visualModeKeyBindingsNonRecursive": [ | ||
{ | ||
"after": [], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you remove all the empty arguments? They aren't necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome. One minor comment on updating the README to simplify the example remappings and we should be good to merge.
Thanks @chibicode! |
I believe this just got updated? This broke essentially all my (vim) keybindings. It took me some time to figure out the changelog (well, VS Code did say vim.otherModesKeyBindingsNonRecursive is an unknown config setting now). I don't have any mappings that apply only to normal mode or visual mode, they all apply to both. If I understand correctly, I now have to duplicate all my keybindings (once for normalModeKeyBindings and once for visualModeKeyBindings)? Is there any way to configure keybindings for multiple modes at once? |
No, you'll need to copy the keybindings over for both modes. |
I tried to use reference variables: {
"vim.visualModeKeyBindingsNonRecursive": "${config:vim.normalModeKeyBindingsNonRecursive}"
} However no luck. Vim bindings is a huge part of my settings and now I have to double them and maintain twice. Maybe there is a way to put a reference? |
My key bindings stopped working without any notice. It took me some time to figure out what happened. It would be nice if I would get some warning when the extension automatically updated with a breaking change. Why not have something for both normal and visual mode? Why not use the name |
First off, sorry for the inconvenience. @mdunicorn, the best spot to look for this sort of information is our change log which we keep up-to-date with each release: https://github.com/VSCodeVim/Vim/blob/master/CHANGELOG.md#v0130-2018-06-18. Easiest spot to view this is through VSCode's extension marketplace when you are updating the extension. We also announced this particular change on our Slack and on Twitter (https://twitter.com/jasonthepoon/status/1008784419354652672), so maybe look out on those channels? We will eventually adopt semvar versioning (#2756) once we feel that we've reached a v1.0.0 milestone so that'll be another mechanism in which users can identify if there is a breaking change. If you have suggestions on how we can improve this process, we'd love to hear them.
We debated this on the PR (see above) and on our slack. Ultimately, we decided to do the breaking change precisely for the point you brought up -- if we kept |
Hello @jpoon. Thanks for your kind response. I really appreciate your effort on the extension and keeping the users informed. The thing is, not all the users of the extension, follow it on Twitter or subscribe to the Slack channel. And since VS Code automatically updates all the extensions (which is very good), the users will not notice the changes, unless something stops working. Some extensions (Material Icon Theme, for example) automatically show their Release Notes on every update (which is annoying, though!). I don't know how it works, but if the extension can use a hook and be informed by VS Code when it is updated, it would be very good that it warns the users of any breaking change. Thanks for listening! :) |
add leader a command in vim normal mode to focus next error some auto formatting of settings.json
otherModesKeyBindingsNonRecursive => normalModeKeyBindingsNonRecursive Due to breaking change in VSCodeVim/Vim#2726 disableAnnoyingNeovimMessage doesn't appear to be necessary anymore? Can't find anything in the Changelog about it Fix statusBarColors config syntax, which apparently has changed, although I can't find a Changelog entry or PR about it either: https://github.com/VSCodeVim/Vim/pull/4406/files
What this PR does / why we need it:
Add
visualModeKeyBindings
/visualModeKeyBindingsNonRecursive
in addition tootherModesKeyBindings
/otherModesKeyBindingsNonRecursive
so that we can add key bindings which only works in visual mode.Which issue(s) this PR fixes
fixes #2705