Lsp: ctrl+. hijacks bindings from other plugins

[arsham]

• OS and language server
  Linux, gopls
• How you installed LSP
  Cloned from git
• Minimal reproduction steps
  N/A
• Log
  N/A

Please consider changing the lsp_code_actions key binding from ctrl+. to something else.

I'm using GoSublime and I assume there are people still using this plugin for features that are not in the gopls/golsp yet. Most GoSublime's key bindings are a combination of ctrl+. and another key. LSP's configuration hijacks it and the only way I've found to fix it is to copy all key binding to the user's key binding file, which is annoying.

ctrl+., ctrl+a would be a good choice.

[tomv564]

This is unfortunate, I like the current keybinding because it matches VS Code and I really believe multi-key chords are much harder to memorise. Thanks for sharing the workaround, but I agree it's really painful - hope there is a simpler way to disable it for the few people using both GoSublime and LSP.

[rchl]

I don't care too much because I've remaped it but given that it also overrides ST's built-in command for navigating changed chunks (Next modification command), it really shouldn't do that.

[tomv564]

Thanks for pointing that out @rchl - unfortunate I wasn't aware of that use ( suspect it came later with Sublime Merge?) I'll re-open the issue then.

[math2001]

Disclaimer: i'm the maintainer of [FileManager][] and [package_setting_context]. Shameless self promotion here.

I had the same problem with FileManager (default keybinding annoying users). A nice solution is to use package_setting_context, as it allows users to change a setting to disable your package's key bindings.

All you do is add an entry to the packages settings, for example:

{
    // LSP.sublime-settings

   // ...

   "enable_default_code_actions_keybind": true,
}

And, then you add a context entry in all your keymaps, for example:

{
    "keys": ["ctrl+."],
    "command": "lsp_code_actions",
    "context": [
        {"key": "setting.lsp_active"},
        {"key": "package_setting.LSP.enable_default_code_actions_keybind"}
    ]
},

If a user wants to disable the default keybind, all they have to do is go in settings and set enable_default_code_actions_keybind to false. Done.

Like this, you can set default keymaps so that LSP works nicely out of the box, whilst allowing users to easily disable them if they conflict with their existing mappings/habits.

I'd be happy to send a PR, LSP is pretty cool :slightly_smiling_face:

[predragnikolic]

We currently have setting.lsp_active which I think is sufficient.

 "keys": ["ctrl+."], "command": "lsp_code_actions", "context": [{"key": "setting.lsp_active"}]},

Although currently this keybinding has a conflict with the default which was added later when merge. Technically LSP used it first :)

{ "keys": ["ctrl+."], "command": "next_modification" },

Can we close this or do we need to remap the keybinding? :)

[rchl]

It should be IMO remapped. Or disabled and user could enable it himself.

On mac this seems fine as we are using cmd+..

[predragnikolic]

I am ok with remapping as long as we inform the user that we remapped it.

Most of the LSP keybinding are unbound, only the code actions and diagnostic toggle panel command are bound.

    // Show Code Actions
    { "keys": ["ctrl+."], "command": "lsp_code_actions", "context": [{"key": "setting.lsp_active"}]},

    // Show/Hide Diagnostics Panel
    { "keys": ["ctrl+alt+m"], "command": "lsp_show_diagnostics_panel", "context": [{"key": "setting.lsp_active"}]},
    ...
    // Go To Definition
    // {"keys": ["UNBOUND"], "command": "lsp_symbol_definition", "context": [{"key": "setting.lsp_active"}]},

    // Go To Type Definition
    // {"keys": ["UNBOUND"], "command": "lsp_symbol_type_definition", "context": [{"key": "setting.lsp_active"}]},
    ...

I suggest these options:

• we make the Code Actions and The Diagnostic Panel unbound, to be consistent with other LSP commands.
• or we assign a different key binding alt+. for example.

I would prefer the first suggestion, as it let the user decide what keybinding suits him best.

[rwols]

The ST4 version will have the keybinding unbound. You'll have to bind the lsp_code_actions command to some keybinding yourself.