Add note about unsupported motions

[karlhorky]

What this PR does / why we need it:

As @alexpattison mentions in #3623 (comment), there is a caveat that causes motions involving j and k to not work with the performant line-wrapping solution.

Which issue(s) this PR fixes

This documents the issue as well as linking to a solution if this caveat is unacceptable to users.

cc @jpoon @alexpattison

[TravisBuddy]

Travis tests have failed

Hey @karlhorky,
Please read the following log in order to understand the failure reason.
It'll be awesome if you fix what's wrong and commit the changes.

Node.js: 8

View build log

if [[ $(git diff-index HEAD -- *.js *.ts *.md) ]]; then git diff; echo "Prettier Failed. Run `gulp forceprettier` and commit changes to resolve."; exit 1; fi

diff --git a/README.md b/README.md
index 6d966db..a9f2f5d 100644
--- a/README.md
+++ b/README.md
@@ -667,7 +667,6 @@ Vim has a lot of nifty tricks and we try to preserve some of them:
 
   **Caveats:** This solution restores the default VS Code behavior for the <kbd>j</kbd> and <kbd>k</kbd> keys, so motions like `10j` [will not work](https://github.com/VSCodeVim/Vim/pull/3623#issuecomment-481473981). If you need these motions to work, [other, less performant options exist](https://github.com/VSCodeVim/Vim/issues/2924#issuecomment-476121848).
 
-
 ## ❤️ Contributing
 
 This project is maintained by a group of awesome [people](https://github.com/VSCodeVim/Vim/graphs/contributors) and contributions are extremely welcome :heart:. For a quick tutorial on how you can help, see our [contributing guide](/.github/CONTRIBUTING.md).
diff --git a/test/mode/normalModeTests/motions.test.ts b/test/mode/normalModeTests/motions.test.ts
index 9859460..6d93d8d 100644
--- a/test/mode/normalModeTests/motions.test.ts
+++ b/test/mode/normalModeTests/motions.test.ts
@@ -387,7 +387,7 @@ suite('Motions in Normal Mode', () => {
     keysPressed: '/two\n/three<Esc>n',
     end: ['one', 'two |two', 'three three three'],
   });
-  
+
   newTest({
     title: 'Backspace on empty search cancels',
     start: ['|one two three'],
Prettier Failed. Run [13:45:07] Using gulpfile ~/build/VSCodeVim/Vim/gulpfile.js
[13:45:07] Starting 'forceprettier'...
[13:45:22] Finished 'forceprettier' after 15 s and commit changes to resolve.

TravisBuddy Request Identifier: e35c2680-5b96-11e9-8b34-015589fd6260

[jpoon]

Should we start using GH wiki's? Can I open them for editing to anybody? that might be a quicker/easier way to share information to the community.

[jpoon]

Created the wiki. Wanna try moving these docs there? https://github.com/VSCodeVim/Vim/wiki

[karlhorky]

I would suggest against GitHub wikis.

It moves the documentation out of code into a proprietary system (which first of all means, one more thing to maintain, one more system to have to configure).

I have found that it decreases visibility of the documentation too, leading to confusing situations and splintered SEO.

Having the documentation in code allows for portability and also interesting other features, such as updating the documentation for features as part of their pull requests.

I don't see any positives from moving to a GitHub wiki.

---

If the VSCodeVim team decides to nevertheless go for a GitHub wiki after consideration, I will update the wiki.

[jpoon]

Benefits I see of using a wiki:

• Time. I'm the only active maintainer of this project at the moment and with a several month old 👶+ my day job, I have limited time to keep up-to-date and respond to PRs and issues.
• Living documentation. People won't need to go through the whole fork/PR flow to edit docs. Hopefully in removing that barrier we'll have more people contributing.
• Community-driven. As we don't support vimrc and have our own way of defining keybindings, an question I often see on the GH issues, is "how do I do this XYZ keybinding?". With a wiki, folks can share their own settings.json files with the community at large. Such that we can expand this section (https://github.com/VSCodeVim/Vim#quick-example) and offer more examples.
• Organization. The Readme is a hella verbose to the point it's getting hard to find things unless you know where to look. A wiki will help us put these into sections and such.

It moves the documentation out of code into a proprietary system (which first of all means, one more thing to maintain, one more system to have to configure).

My time in maintaining this project is fairly limited. I'm hoping moving to a wiki will allow the community to help maintain. It was fairly easy to configure -- ie. one is already setup.

I have found that it decreases visibility of the documentation too, leading to confusing situations and splintered SEO.

If angular/react are able to do solve this, why can't we? https://github.com/angular/angular.js/wiki

Having the documentation in code allows for portability and also interesting other features, such as updating the documentation for features as part of their pull requests.

Portability? Not sure I see your argument there. Forking the repo will also fork the wiki AFAIK.

[karlhorky]

Okay, seems like you have some pretty strong opinions. Since you're the sole maintainer at the moment, if we don't find another way, then it seems like it's that is the way to go.

Some responses (TLDR: maybe we can get more maintainers instead?):

People won't need to go through the whole fork/PR flow to edit docs. Hopefully in removing that barrier we'll have more people contributing.

I would propose that forking + PR + review + approval is such standard practice and no less well-known than editing the Wiki (which may or may not exist for a GitHub project - readmes are almost always present).

Time. I'm the only active maintainer of this project at the moment and with a several month old 👶+ my day job, I have limited time to keep up-to-date and respond to PRs and issues

Totally get this. Maybe the solution is not a new tool, but another maintainer? I'm sure there are a lot of passionate people that would like to get involved here (myself included). Maybe open a call for co-maintainers?

If angular/react are able to do solve this, why can't we?

Angular.js is the old pre-v2 Angular. The new Angular does not use GitHub wikis.

And React is not using a wiki, they have their own docs site:

I have not seen GitHub wikis effectively implemented in open source projects except for a few academic project exceptions. And even then, it was confusing to have them separate from the other documentation in the project (which was in code).

Portability? Not sure I see your argument there. Forking the repo will also fork the wiki AFAIK.

Portability is not just about forking. Cloning the project does not clone the wiki (you have to use a separate URL for this, which again, may or may not exist). And once forked, the wiki doesn't follow the normal PR flow.

With a wiki, folks can share their own settings.json files with the community at large

This is the first use case that I would agree justifies a new tool. But I would suggest to do this separately and only for community discussions. And now that GitHub has acquired and integrated Spectrum, maybe that would be a better option for a community platform (see https://spectrum.chat/next-js for an example)

Organization. The Readme is a hella verbose to the point it's getting hard to find things unless you know where to look. A wiki will help us put these into sections and such.

Interesting, I actually see this as a plus. I like going to one page and being able to use the super-fast Find in Page in my browser to find the information that I need. For example, I like the Next.js readme, the Ramda docs. create-react-app also had their docs in one markdown page for a bit (now they are fairly established and can support a full docs site).

[pablospe]

I wonder why the following doesn't work.

VS Code's keybindings.json settings file.

{
  "key": "up",
  "command": "cursorUp",
  "when": "editorTextFocus && vim.active && !inDebugRepl && !suggestWidgetMultipleSuggestions && !suggestWidgetVisible"
},
{
  "key": "down",
  "command": "cursorDown",
  "when": "editorTextFocus && vim.active && !inDebugRepl && !suggestWidgetMultipleSuggestions && !suggestWidgetVisible"
},

Then, in settings.json:

  // Normal Mode
  "vim.normalModeKeyBindingsNonRecursive": [
    {
      "before": ["j"],
      // "after": ["g", "j"]
      "after": ["<down>"]
    },
    {
      "before": ["k"],
      // "after": ["g", "k"]
      "after": ["<up>"]
    },

[UndesW]

I let k and j behave natively as they should in Vim, and configure the up and down arrows to move across wrapped lines as typically desired in prose writing:

In VSCode settings.json, I added the following:
"vim.normalModeKeyBindingsNonRecursive": [
{ "before": ["down"], "after": ["g", "j"] },
{ "before": ["up"], "after": ["g", "k"] }
],
"vim.visualModeKeyBindingsNonRecursive": [
{ "before": ["down"], "after": ["g", "j"] },
{ "before": ["up"], "after": ["g", "k"] }
],

In VScode keybindings.json, I added the following:
{
"key": "up",
"command": "cursorUp",
"when": "editorTextFocus && vim.active && !inDebugRepl && vim.mode == 'Insert' &&!suggestWidgetMultipleSuggestions && !suggestWidgetVisible"
},
{
"key": "down",
"command": "cursorDown",
"when": "editorTextFocus && vim.active && !inDebugRepl && vim.mode == 'Insert' && !suggestWidgetMultipleSuggestions && !suggestWidgetVisible"
},