Keymappings for Multiple Platforms - Issues with particular tags


#1

I would like to manage all keybindings for the multiple platforms that I use through one keymap file. If there’s a better way of doing this (not necessarily through one file), I’d love to hear it, but it seems that the platform-specific selectors provided should do the trick.

However I’ve come across a couple of selectors that don’t seem to work when I add the platform specificity. For example, adding a custom binding to body using platform specificity:

# doesn't work -- in keybinding resolver, this command shows grayed out
'.platform-win32 body, .platform-linux body':
    'alt-o': 'window:focus-next-pane'  

But omitting the platform works fine:

'body':
    'alt-o': 'window:focus-next-pane'                  

The same seems to be true for .platform-*** atom-workspace .editor .find-and-replace – any binding specified here appears grayed out in the resolver, but putting the bindings in atom-workspace .editor .find-and-replace works fine.

Any suggestions? See something I’ve missed?


#2

Is always going to fail the way you’re doing it because .platform-win32 body looks for a <body> tag that’s inside the tag with the platform class, which it’s not. <atom-workspace> is also not a child of the element with the platform classes on it, because it is the one. What you want is to use selectors like body .platform-win32 and atom-workspace.platform-win32.


#3

Thanks – it hadn’t occurred to me that an element within Atom would be less specific than the OS.

Follow-up question: is combing through Atom’s elements in the inspector still the best way of figuring out which selectors reference what, or is it documented somewhere beyond my googling skills?


#4

Where in an HTML document would you put an informative class that is a parent of the body element? The classes that tell you about the active themes and the operating system are stored on the element that contains all of the visible elements in the DOM.

is combing through Atom’s elements in the inspector still the best way of figuring out which selectors reference what

Yes. A lot of that information changes based on what packages you have active and what you’re doing in Atom, so it’s difficult to offer blanket guidance.