Enable major mode support

[MarcoIeni]

As I said here:

In spacemacs you have major-modes, like "python", "markdown", and so on. So for example if you open a .md file ? spacemacs will use Markdown mode in that buffer.

When you are using a mode, key bindings under <spc> m or under , will be unique to that mode.

This means that when you are editing a markdown, <spc> m b could be assigned to "make bold", while in python <spc> m b could be assigned to "toggle breakpoint" (I am just inventing).

Maybe the discussion in the above linked issue could be relevant.

[stevenguh]

This should be supported by VSpaceCode/vscode-which-key#11. Should we include some major mode bindings built-in to the default bindings of VSpaceCode?

[MarcoIeni]

I think so. I was thinking about doing an issue where we list some programming languages, like

- [ ] java
- [ ] cpp

and we ask to our community to take ownership of one of them and to write the key bindings for that. In addition, they should provide a document where they list needed extensions used by these key bindings, so that users know what to install.

[stevenguh]

That's would be awesome to have some community maintain ones. I am wondering how should we bundle major mode?

1. Bundle 0 major mode conditional bindings but at least have an item on the root menu. (Requires override on user's settings to "install" a major mode)
2. Bundle some major mode conditional bindings like javascript and markdown that are have built-in support with no extension
3. Bundle some more major mode conditional bindings like javascript, markdown, java, c++ that might requires external extensions

I imagining this is a little bit like the community-config repo, where people contribute a major mode specific to that language and its extension. The question, should we ship some default major modes?

[MarcoIeni]

Option 3 may be ok just for markdown in my opinion. We already ship a lot of extensions.

I would follow option 2.

In VSpaceCode we write the key bindings for a lot of major modes. If you execute there there will be an error that says that the extension was not found, right? At that point the user may choose to install the used extension. If they want to use other extension they can override the key bindings and maybe they will find something useful in community-config, which may contain alternative major modes, with other extension, for example.

[stevenguh]

Not sure if I follow

Option 3 may be ok just for markdown in my opinion. We already ship a lot of extensions.

Basically option 2 and only support markdown right out of the box?

In VSpaceCode we write the key bindings for a lot of major modes. If you execute there there will be an error that says that the extension was not found, right? At that point the user may choose to install the used extension. If they want to use other extension they can override the key bindings and maybe they will find something useful in community-config, which may contain alternative major modes, with other extension, for example.

Is this a describing option 3 where we ship some bindings that require specific extensions and we don't bundle them? In that case, the error will probably say something like command "cpp.somecommand" not found. You are right that, the user can try to figure what extension that command requires and install it or override completely.

I am assuming even if we are going with option 3, we won't be bundling extension the major bindings might require. Maybe that's a good point that we should go with the more manual approach where the user will have to add major mode via override manually.

Side note: We can potentially improve the way to specifies such major mode config instead of in the user's overrides (This would be more like option 1) My currently imagination is that it can be a community own repo that will be another extension a user can install like vspacecode-cpp which will bundle all the necessary extension and contribute a default major mode binding. VSpaceCode can just read the config the other extension contributed. This way the default installation of a specific major mode will be way simpler for user than playing around with configs. There's a bit of work involved with this, and I probably won't have the capacity to implement this in the short term. (Kind of just jotting my thinking here)
Also, this type of extension should have low overhead since it doesn't contain any code to load.

[MarcoIeni]

Is this a describing option 3 where we ship some bindings that require specific extensions and we don't bundle them? In that case, the error will probably say something like command "cpp.somecommand" not found. You are right that, the user can try to figure what extension that command requires and install it or override completely.

Yes, exactly! And Markdown is the only extension that I would consider to install by default, but I am not so convinced about it.

it can be a community own repo that will be another extension a user can install like vspacecode-cpp which will bundle all the necessary extension and contribute a default major mode binding.

This would be awesome, but only in certain situations.
For example, let's say that you are programming in Cpp. When you open a .cpp file, VSCode asks you to install their default language extension.
It is really likely that user will install that extension, so if our major mode uses only that extension, VSpaceCode will work out of the box for them if we bundle cpp major mode key bindings in VSpaceCode. In this scenario, installing vspacecode-cpp would be just an extra step for the user.

But if we have some major mode that uses different obscure extensions, we could bundle them as another extension.

---

So, if we agree on the approach we could procede to open a new issue where we describe this process and we ask for partecipation.
But before doing that..I think it would be easier for other people (and for me 😄 ) to have a working example as a reference.
Do you want to be the first? ^^'
For example you can do javascript major mode. Of course there is no need for it to be huge, you can just set a couple of key bindings as an example.

[stevenguh]

Yes, exactly! And Markdown is the only extension that I would consider to install by default, but I am not so convinced about it.

Let's not bundle anything in the beginning 👍

It is really likely that user will install that extension, so if our major mode uses only that extension, VSpaceCode will work out of the box for them if we bundle cpp major mode key bindings in VSpaceCode. In this scenario, installing vspacecode-cpp would be just an extra step for the user.

That's an interesting point. Installing vspacecode-cpp will definitely be an extra step, but I was thinking like the spacemacs layers. The benefits of the major mode extension are:

• Store the config in a concise manner instead adding a potentially huge override config in user space manually especially when each major mode can be huge
• Ensure the major mode extension "bundles" the extensions it uses
• Update bindings automatically without user intervention
• Allows any users to create a third party bindings
• Not bundling any default major actions in vspacecode.bindings, so we don't need to load those major mode items if the user doesn't use that major mode.

However, this needs more thinking in what's the best way do the plumbing

The alternative, which is available now, is to do a vspacecode.overrideBindings manually for each major mode, and each one can be a huge config for a user to manage.

---

I would be happy to set up an example major mode once we agree on the approach.

[MarcoIeni]

I don't want the user to manage major modes in their own settings.json file, too.
I was thinking to add major modes to package.json.

Not bundling any default major actions in vspacecode.bindings, so we don't need to load those major mode items if the user doesn't use that major mode.

If there is a relevant overhead in loading a lot of major modes, we definitely should use the vspacecode-cpp approach.

Ensure the major mode extension "bundles" the extensions it uses

Yes, in the cases where there are different extensions to bundle, the vscpacecode-cpp approach is better.

Anyway to me both the two approaches are fine :)
Do you think that a mix of the two is the best (built-in support for simple major modes and vspacecode-cpp approach where you have to bundle different extensions)?

[stevenguh]

I was thinking to add major modes to package.json.

So that's the option 3 where we put all the major mode in the vscodespace.bindings? Sorry if I wasn't being clear enough with the different options.

If there is a relevant overhead in loading a lot of major modes, we definitely should use the vspacecode-cpp approach.

We load all of the bindings upfront, so there are some overhead indeed if the conditional bindings get big. This is where my head was thinking the imagined approach (because it needs some engineering effort/thinking) where we can use the extension infrastructure to install major mode instead of binding all in vspacecode.bindings in package.json.

Do you think that a mix of the two is the best (built-in support for simple major modes and vspacecode-cpp approach where you have to bundle different extensions)?

I think to start out, we can put the conditional bindings in the the vspacecode.bindings in package.json for now. We can then switch to the extension base approach once the major mode conditional bindings get big and the engineering is there.

I am not ruling out a possibility that in the future we can have a hybrid where to bundle some and also allows the extension approach. For now maybe we should try just putting them directly in vspacecode.bindings (since the engineering for the extension approach is not there yet) and see how that works?

[MarcoIeni]

So that's the option 3 where we put all the major mode in the vscodespace.bindings?

yes!

I think to start out, we can put the conditional bindings in the the vspacecode.bindings in package.json for now. We can then switch to the extension base approach once the major mode conditional bindings get big and the engineering is there.

yes!

For now maybe we should try just putting them directly in vspacecode.bindings (since the engineering for the extension approach is not there yet) and see how that works?

and yes :)

[stevenguh]

I added a single binding for markdown as an example in 23b5b75. Feel free to add more to it or other mode :)

Maybe we should target top 5-10 languages for now until we have the extension system?

[MarcoIeni]

Maybe we should target top 5-10 languages for now until we have the extension system?

Yes, we can open an issue where we list most used languages in vscode, as tasks in the format - [ ] language but we specify that users can propose new languages if they want to work on them.

[stevenguh]

That sounds good. Do you mind leading that effort?
Btw, here is the list of the top vscode extensions: https://marketplace.visualstudio.com/search?target=VSCode&category=All%20categories&sortBy=Installs

[MarcoIeni]

opened #98

[david-morris]

What do you think of a "fallback major mode" that would, for example, react to , g d the same as SPC SPC go to definition RET?

How feasible is that and does it fit with the design philosophy?

[MarcoIeni]

I didn't get what you mean.
g d (whithout the initial space) already does that