Reputation: 1858
The normal mac behavior for command+shift+?
is to open the help menu search, which is super convenient to do menu commands without a mouse.
Unfortunately a sublime text package I have installed has mapped that key binding to the settings menu. Here's the relevant section of the package Default (OSX).sublime-keymap
file
[
{ "keys": ["super+shift+/"], "command": "open_settings" }
]
Based on Related to How to unbind a key binding in Sublime Text 2?
I went ahead and overrode their keybinding in my user keybinding. Here's my user Default (OSX).sublime-keymap
file.
[
{ "keys": ["super+shift+/"], "command": "noop" }
]
This stops the package from open settings when I press the key sequence. Same behavior if I use unbound
for the command, excluding the command files package keybinding. However, it doesn't bubble up to the Mac layer which opens the help search menu.
I can get things to work the way I want to by modifying the package's key binding file directly, but that's going to get overwritten the next time the package upgrades.
Is there a supported way to remove a keybinding without stopping it from bubble up to the operating system?
Upvotes: 1
Views: 423
Reputation: 22821
The only way to completely remove a key binding in a way that Sublime won't react in any way is to remove it from the sublime-keymap
file. This is true whether you want to fully remove a file from the Default/Default (PLATFORM).sublime-keymap
(there is one for each platform) that ships with Sublime to remove a default key binding as well as any that might be added by a third party package.
As long as the key remains in a sublime-keymap
anywhere, Sublime will see it and try to do something with it, even if the key is bound to a command that doesn't exist such as noop
(although that is a good way to block a default key from doing anything if that's your ultimate goal).
One way to solve the problem is to directly modify the packaged file itself, as you've already mentioned. In most cases that would mean unpacking the related sublime-package
file (which is just a zip
file), modifying the content of the file, and then repacking it.
As you've already noted, that's not a good way to go because when a package gets updated, the entire sublime-package
file gets clobbered away, so your changes will also get discarded.
A safer way to do this would be to create a package override file instead. This only works if the package in question is installed as a sublime-package
file, which covers all of the packages that ship with Sublime as well as most third party packages.
To do this, you would create a folder in the same name of the package in the Sublime Packages
folder, which you can get at via the Preferences menu item Browse Packages...
. Once that's done, extract just the file you want to override and place it into that folder, and edit it as desired.
When Sublime loads packages from a sublime-package
file, as it loads each file it checks to see if any similarly named "unpacked" files exist in the Packages/PackageName/
folder. If such a file exists, the version inside of the sublime-package
file is ignored and the unpacked file is used instead.
This means that even if the package gets updated, since your unpacked version is still there, it will still be used and so your change will remain in place.
The easiest way to create such a file is to use the PackageResourceViewer package. You can use it's PackageResourceViewer: Open Resource
command from the command palette to find and open the offending file. If you make changes to the file and save it, PRV will automatically create the override for you.
There are a couple of caveats to this process:
If the package in question is installed already unpacked in the Packages
folder, you can't create an override. In this case there's not a lot you can do other than vigilantly re-modify the file when it updates.
Most packages won't fall under this restriction because few actually need to be installed that way (only packages that contain files that need to be exposed outside of Sublime need to be installed this way).
Note also that Sublime Text 2 only installs packages as unpacked, so in that particular case you also can't do this.
When a package override exists, it's always used in place of a packed file of the same name, no matter what. This has the unfortunate side effect that if the package update actually modifies the file that you're updating in any way, those changes are masked from you without warning.
Will the full caveat/disclosure that I'm the one that wrote the package, the OverrideAudit package for Sublime can warn you when this happens by checking every time a package gets updated to see if the version of the packaged file is newer than your overridden version so that you know this is happening and can take appropriate action.
Your question is tagging Sublime Text 2 and Sublime Text 3. In the case of Sublime Text 2, the information above about needing to remove a key binding completely in order to allow the OS to see it still holds.
However as far as I'm aware Sublime Text 2 doesn't support the idea of package overrides because it always installs all packages unpacked. As such the only solution in that particular case is to modify the packaged file and keep an eye out for changes.
At this point with Sublime Text 3 officially released there are not many compelling reasons to keep using ST2. If you purchased your license for ST2 sometime mid/late 2013 or later your license should be valid for ST3.
This is particularly important in that ST2 is no longer supported and as of High Sierra when Apple removed Python 2.6, various Sublime packages will now no longer work.
Upvotes: 2