Repository navigation
Alternative to overriding "primary+s" for emacspro compatibility?ย #3017
Description
Default.sublime-keymap sets "primary+s".
This means that the sublime emacspro package cannot work properly (ctrl+s should initiate search). Issue initially raised on that project:
sublime-emacs/sublemacspro#209
The only solution I could find was to comment out this binding in the LSP keymap and inject the keymap back into the package. It'd be nice if there was an easier way to make these packages co-exist.
Activity
jwortmann commentedon Aug 28, 2026
IIRC the
lsp_savecommand is required for the code-action-on-save and formatting-on-save features, because LSP needs to send the code action / formatting requests to the server first and then wait for the response before saving the file. It can't use theon_pre_saveevent listener because we don't want to block the UI for 1 or 2 seconds if the server is slow to respond, and I think that wouldn't work anyway because the requests run in an async way. Also LSP can't intercept thesavecommand viaon_text_commandAPI, because we still need to trigger thatsavecommand for saving the file after applying code actions or formatting, and doing that would trigger an infinite loop. So I think this is why the key binding is required. Note that the code-action-on-save and formatting-on-save features are not active if thesavecommand is triggered in a different way, for example from the main menu (File > Save).Key binding precedence is determined by (alphabetic) package load order (iirc), so instead of commenting out the LSP key binding it should be possible to just copy the key binding from the desired package into your user key bindings in the
Packages/Userpackage, because the User package gets loaded last (highest precedence).rchl commentedon Sep 28, 2026
Overriding using User keybindings is I suppose a viable alternative but perhaps not ideal if every user of that package has to do that.
Maybe that LSP keybinding could also check for absence of some key like
disable-lsp-saveand then any other package could decide to disable it by adding that context key to a file.jwortmann commentedon Sep 28, 2026
Interesting idea. I don't think it would work with a context key, because the context keys are set via our own keybindings file, so another package has no means to influence that (unless I'm missing something?). But I think it should work to use a setting instead, i.e. we could just add another context to our keybinding like this:
{ "context": [ { "key": "lsp.session_with_capability", "operand": "textDocumentSync.willSave | textDocumentSync.willSaveWaitUntil | codeActionProvider.codeActionKinds | documentFormattingProvider | documentRangeFormattingProvider" }, { "key": "setting.disable_lsp_save", "operator": "not_equal", "operand": true }, ] }Then another package (or user) could set
"disable_lsp_save"to true inPreferences.sublime-settingsto disable our keybinding.rchl commentedon Sep 29, 2026
Yeah, meant that.
Then the package would also have an option of setting that setting on the view itself if it wants to target only specific files.