Is there a way to avoid registering commands,menus and keybindings that comes with Theia Plugins

[arunswarnam]

I am attempting to consume some VS Code extensions that offers some language contributions but I also see those VSCode extension (theia plugins) register's some commands that I don't want. Can you suggest some handles that I can look into to get rid of/avoid registering the commands/menu items/keybinding brought in by plugins?

I found a hacky way to avoid registering commands by forcing plugin.contributes.commands to undefined inside my custom extension, before passing the control to super.handleContributions(clientId, plugin) where plugin contributions are handled but I doubt if it is the right thing to do.

[vince-fugnitto]

@arunswarnam I'm not sure a simple approach exists since removing a plugin's contributions are fundamental to their functionality and use, and it is an overall uncommon use-case. I'm not sure how useful it is to consume plugins but only accept a subset of their contribution points. Since the installation of plugins are dynamic, I'm not sure how you will approach removing contributions for a specific plugin, but accepting those of another.

[arunswarnam]

@vince-fugnitto Thanks for responding. Yes, I get it is uncommon and I am just exploring if it is possible. I am looking at an use-case where I need just language contributions but don't need other contributions like debugging contributions, commands related to debug etc.
Also, Just to add, I would like to remove {menu/keybinding/command} contributions from all (at bootup or runtime)plugins and don't expect to pick and choose these contributions from some specific plugins.
After some more digging, I am guessing overriding this might be a way to remove declarative command contribution?
https://github.com/eclipse-theia/theia/blob/master/packages/plugin-ext/src/hosted/node/scanners/scanner-theia.ts#L337

[vince-fugnitto]

I am looking at an use-case where I need just language contributions but don't need other contributions like debugging contributions, commands related to debug etc.

What type of language contributions are you ultimately looking for, simply syntax highlighting? If it's the case, maybe only include such types of extensions in your application (ex: vscode-builtin-java). If you are looking for more smartness or functionality, I don't see how such plugins will even work if their contributions are removed.

Also, Just to add, I would like to remove {menu/keybinding/command} contributions from all (at bootup or runtime)plugins and don't expect to pick and choose these contributions from some specific plugins.

Do you mean you are only looking to modify builtin plugins which are bundled with your application? Unfortunately, I do not think we can pick and choose what we want from plugins, they will end up as being non-operational and ultimately how useful will they be if they do not work as advertised. You can try to remove their contributions but I'm not sure this will even work.

[arunswarnam]

What type of language contributions are you ultimately looking for, simply syntax highlighting?

I was looking for extensions with syntax auto-complete suggestions, but most of those extensions come with debugging commands which I don't plan to support at-least for time being. 

Do you mean you are only looking to modify builtin plugins which are bundled with your application?

Currently, my application doesn't allow user to install plug-ins so I can safely say the use case is restricted to built-in plugins bundled with application. The image I have shown above is the python language plugin suggesting completions, after I overrode the scanner method to not read command contributions. 

Although, With this approach I doubt if I can avoid registering commands that get registered by the extensions using registerCommand(...). Currently the extensions that I use don't register commands using API, but sounds like that might not be possible?

[vince-fugnitto]

@arunswarnam I now understand that you control the extensions you include, and restrict users from downloading their own 👍

I feel like whichever solution you find that meets your use-case and requirements is fine, but I do not believe there is necessarily a clean or straightforward way to achieve it currently (due to the reasons I mentioned) without some form of hack or workaround. You may try to rebind some plugin classes to your custom implementation, by for instance stubbing/removing contributions (based on id) instead of registering. The issue is I do not think the CommandRegistryMainImpl for instance can be easily extended.