Implement conditional bindings

[stevenguh]

Close #11

@marcoieni It would be nice if you can look at the README and see if conditional binding makes sense to you.

[stevenguh]

@marcoieni Is there any update on this? I would like to merge it and unblock the task on the VSpaceCode repo to implement <spc> f t and major mode.

[marcoieni]

I procrastinated a little bird here, sorry, I was planning to do it in the next hours :)

[marcoieni]

I tried to improve a little bit the README, but in my opinion the syntax is a little bit too complicated to be easily understand.

I am sure you had valid reasons for your design choices, but in the following I will write down some things that seemed strange to me the first time I read them:

key and serialization

• It is confusing that the key contains conditions, too. I would expect that the key is just a character.
• In order to explain what languageId:javascript;when:sideBarVisible means, you first showed a json. Why don't we just use the json instead?

examples

this:

{
  "key": "when:sideBarVisible && explorerViewletVisible",
  "name": "Hide explorer",
  "type": "command",
  "command": "workbench.action.toggleSidebarVisibility"
}

might become this:

{
    "condition": {
        "when": "sideBarVisible && explorerViewletVisible"
    },
    "name": "Hide explorer",
    "type": "command",
    "command": "workbench.action.toggleSidebarVisibility"
}

and this:

{
    "key": "languageId:javascript;when:sideBarVisible",
    "name": "Open file",
    "type": "command",
    "command": "workbench.action.files.openFileFolder"
},

might become this:

{
  "condition": {
      "languageId": "javascript",
      "when": "sideBarVisible"
   },
  "name": "Open file",
  "type": "command",
  "command": "workbench.action.files.openFileFolder"
},

Other stuff, WIP

[stevenguh]

That's why I marked this as experimental for now, and change it if we need to. I don't like the reusing of the key key either; however, it's more consistent and flexible with the overrides and other types than to accept a condition json in an overrides keys. The thinking is I would rather have it be weird consistently (using keys for both binding and overrides, instead of condition in binding, and keys in overrides) Also, it doesn't increase the complexity of json schema. It's definitely a trade-off sadly :(

---

I explained the serialization because the same serialization is used for both keys in overrides and key in binding item. I am a little worried that putting the condition in the example will be more confusing? If you think that's clearer, do you mind updating the README? :) We can always change the doc if people find it confusing

[marcoieni]

It's definitely a trade-off sadly :(

Ok, so we keep key instead of condition.

I explained the serialization because the same serialization is used for both keys in overrides and key in binding item.

If we keep this syntax is ok to explain it of course.

I am a little worried that putting the condition in the example will be more confusing?

We decided to keep key instead of condition, so we should not put condition in the README, right?

Overall, since we decided to not change the implementation at the moment, I think that the README is ok as it is (except one comment I will do in the code in a couple of minutes).

[stevenguh]

so we should not put condition in the README, right?

If that's clearer :)

Thank you for reading the issue and working with me :)

[marcoieni]

This and the following json are not very clear to me.

[stevenguh]

Updated, let me know the updated version is clearer :)

[marcoieni]

If that's clearer :)

If condition is not a valid keyword, I don't think we should put it in the README.

Thank you for reading the issue and working with me :)

no problem, thank you for working on this, it will enable really great stuff :)

[stevenguh]

I will fix them later today, and we can look at them again tomorrow :) I know it's probably late in your time zone.

[marcoieni]

Ok, with your changes it was a lot clearer, thanks!
I reviewed it a bit. Of course feel free to revert/change as you like.

I also hidden the section by default, since it is very long and experimental. In this way users are not forced to read it.

[stevenguh]

Thank you for working on it. Can't wait to the features on VSpaceCode that can build on top of it🚢 ship it.