Sublime Forum

Cannot override super+l key binding on MacOS

#1

Hello,

As part of a new job I’ve been forced required to use a MacBook Pro for my primary work computer. I use Sublime Text for my primary editor, and I’m struggling with some key binding issues on MacOS.

The core of the issue is that I’ve created a service to bind super+l to Start Screen Saver in order to quickly lock my laptop without putting it to sleep. Unfortunately, super+l is already defined in the default key binds for OSX.

	{ "keys": ["super+l"], "command": "expand_selection", "args": {"to": "line"} },

I’ve tried changing this to various other key sets, but Sublime continues to see super+l as the default Expand Selection to Line command.

I want to change this command to either alt+super+l or simply disable the key bind all together. There are other binds to super+l as well, but so far I don’t see them being called in place of Expand Selection to Line.

I have verified that the key combination is correct using sublime.log_input(True) as indicated in other posts. I’ve even copied the whole default linux key bind set into my user key binds, and Sublime still intercepts super+l.

Does anyone have any idea what is going on here? Please help!

Thanks in advance.

0 Likes
#2

If Sublime can see the key event, and it’s bound to a key binding, then it will handle the key and try to do something with it. The fact that you can see the key when using log_input() verifies that Sublime can indeed see the key. Using the log_commands() function (which operates the same as log_input()) you can see what command gets executed in response to the key.

One way to resolve the issue is to get things into a state where log_input() doesn’t report that you pressed the key. This is usually the problem people have when they want to use a key binding that the OS thinks is special. In that case the key gets captured and handled before it ever gets to Sublime. I’m not sure if that’s possible in your case though (that’s one aspect of MacOS I’ve never investigated).

Failing that, possibly if you can get things into a state where log_input() says that it sees the key but log_commands() doesn’t tell you that it’s doing anything, things will work the way that you want them to; the caveat here is that I don’t have any direct experience with this in a way that’s caused a conflict before so I’m not entirely sure.

The thing that might be confusing you is that the default key bindings are always in effect, and any bindings added by packages or by you in your user key bindings are applied in addition to the default bindings. That part is bolded because it’s fairly important.

Adding your own binding to super+l in your user package replaces the one in the Default package with yours so that the key does something different (including nothing, if you bind it to a command that doesn’t exist such as noop), but it’s still bound to something so when the event happens, Sublime still handles the key.

Adding a binding to the command that super+l is bound to on a different key adds an additional binding to the same command, but still leaves the original in the Default package there; thus you now have two ways to run the same command, and the default still applies, so when the key is seen Sublime handles it.

Thus in order to resolve your problem you may need to resort to directly editing the default key bindings in the Default package directly to remove the default binding. You mention other bindings that don’t seem to take effect; they may or may not be an issue (it’s possible to bind keys only in certain situations, for example).

You can use PackageResourceViewer to edit the default key bindings file to directly remove the binding to super+l.

Doing so would remove the default (make sure you have a bind on an alternate key if you care about that functionality), and if there are no other bindings on that key (log_commands() does not display anything), that may allow the service to see the key.

0 Likes
#3

You can use PackageResourceViewer to edit the default key bindings file to directly remove the binding to super+l.

This suggestion worked perfectly. By removing the line below Sublime Text is no longer intercepting super+l:

  { "keys": ["super+l"], "command": "expand_selection", "args": {"to": "line"} },

What is interesting about this is that there are other instances of super+l defined:

  { "keys": ["super+k", "super+l"], "command": "lower_case" },

However, in that case in particular, Sublime Text is not invoking that command at all.

Related, the logging suggestion log_commands() is not working for me, but that would be a different problem entirely:

>>> log_commands()
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'log_commands' is not defined
>>> log_commands(True)
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'log_commands' is not defined

Thanks for the help!

0 Likes
#4

That’s a chorded key binding; for that to trigger you have to press both keys in sequence, so Super+K followed by Super+L (within a short period of time). I would imagine that this would also cause Sublime to block the key, but arguably in that case it’s what you want to happen.

Sorry, my bad on that one; it’s actually sublime.log_commands(); it’s essentially the same thing as the input logging you were already doing, only it logs command executions instead of input.

0 Likes
#5

Thanks for the clarification.

0 Likes