Support clangd C++ extension

[siboehm]

Problem

There are two popular extensions for C++ development: Microsoft's C++ extension (50M downloads) and LLVM's clangd (700K downloads). They offer the same functionality, so only one should be installed. My personal opinion is that clangd is much preferrable, since it's easier to configure and comes with a host of standard tooling (clang-format, clang-tidy, ...).

Problem: VSpaceCode only supports Microsofts extension, so e.g. Space -> m -> g -> a: Switch Header/Source fails with Error: command 'C_Cpp.SwitchHeaderSource' not found.

Solution

Is there a good way to let VSpaceCode support both extensions? And just use whichever action is available? I'm happy to write the PR if you guide me in the right direction.

Alternatives

Additional context

[marcoieni]

maybe we could detect which extension is installed? 🤔

[stevenguh]

Layers may help https://github.com/VSpaceCode/VSpaceCode/issues/199.

Imagine user can install a particular "layer extension" which will bundle the correct keybindings for VSpaceCode and install the correct extension.

So effectively the user can choose if they uses MS C++ layer vs llvm layer.

[mayanez]

I'm looking to take this up.

Is the layer approach still relevant or are there other alternatives to explore?

Another alternative that I've been using since I migrated to clangd is the Command Alias extension.

You can add the following to your settings.json:

"command aliases": {
  "clangd.switchheadersource": "C_Cpp.SwitchHeaderSource",
}

Update

Turns out you don't need the Command Alias extension I mentioned above. Simply add this to your settings.json.

     "vspacecode.bindingOverrides": [
    {
        "keys": "m.languageId:cpp.g.a",
        "type": "command",
        "icon": "file",
        "name": "Switch Source/Header",
        "command": "clangd.switchheadersource"
    },
    {
        "keys": "m.languageId:cpp.b.t",
        "type": "command",
        "icon": "list-tree",
        "name": "Open Type Hierarchy",
        "command": "clangd.typeHierarchy"
    },
    {
        "keys": "m.languageId:cpp.b.a",
        "type": "command",
        "icon": "list-tree",
        "name": "Show AST",
        "command": "clangd.ast"
    },
    {
        "keys": "m.languageId:cpp.b.h",
        "type": "command",
        "icon": "lightbulb",
        "name": "Toggle Inlay Hints",
        "command": "clangd.inlayHints.toggle"
    },
    {
        "keys": "m.languageId:cpp.b.d",
        "position": -1
    },
    {
        "keys": "m.languageId:cpp.b.w",
        "position": -1
    },
  ],

[stevenguh]

Is the layer approach still relevant or are there other alternatives to explore?

I am afraid I don't have much time these days to flush it out. The blockers now are mostly time, and balance between API, maintainability, and security.

The binding override is the best bet for now to customize your own bindings.