Shortcut conflicts ? (bug?)

On my keyboard, } is shift+] and { is shift [.
The shortcut settings have “Shift Left” assigned Cmd+{ and “Shift Right” to Cmd+}, which on my keyboard translates as Shift+Cmd+[ and Shift+Cmd+]

When I tried to assign Comment to Shift+Cmd+[ and Uncomment to Shift+Cmd+], SD did not see the conflict and registered the keys as Shift+Cmd+{ and Shift+Cmd+}, which is wrong. And indeed, when I used the shortcuts, it was not Comment/Uncomment that were triggered but Shift Left/Right that were.

So that’s a bug.

On my keyboard # is shift+3.
The OS shortcut for taking a screenshot is Shift+Cmd+3. By your logic, it would be listed as Shift+Cmd+#.

The general logic is that where a key represents different values when the shift key is down, the shortcut shows the value the key represents in that state.

Or as Apple’s Human Interface Guidelines put it:

Identify a key with two characters by the lower character, unless Shift is part of the shortcut. For example, the keyboard shortcut for Hide Status Bar is Command-Slash (that is, Command-/). If the Shift key is part of the keyboard shortcut, identify the key by the upper of the two characters. For example, the keyboard shortcut for Help is Shift-Command-Question Mark, not Shift-Command-Slash.

So, let me start again because my wording was a bit confused:

Here, Shift Left is listed as Cmd+} (which happens to be produced by hitting Shift+Cmd+] here) and that is totally fine.

The problem is that when I hit Shift+Cmd+] to assign it “Comment”, SD lists the shortcut as Shift+Cmd+} and does not detect the conflict with Shift Left, which really happens!

Also, Apple’s HIG says:
"If the Shift key is part of the keyboard shortcut, identify the key by the upper of the two characters. For example, the keyboard shortcut for Help is Shift-Command-Question Mark, not Shift-Command-Slash."
So, by that logic the upper character of 3 and # being # the shortcut for taking a screenshot should be Shift+Command+#, or maybe I’m not understanding something.

OK, that’s a bug.

Apple write the rules, Apple breaks the rules :slight_smile: I suspect this is a case where different keyboards put different values above 3, and they wanted it to be consistent.

1 Like

Which is the reason the rule is silly. You never know (except for capital case letters) what is the upper character of a given combination, so the logical way would be to always describe a shortcut by the keys you really hit (which is generally the case).

Btw, when SD describes Split Editor Horizontally with Cmd+", to produce " I actually have to hit Shift+2, so by the “screenshot” standard, the description should be Shift+Cmd+2, by Apple’s HIG it should be Shift+Cmd+", but the reality is that since you don’t know where " is on any one keyboard, describing it as SD does (Cmd+ whatever it takes to get the " character) is actually more logical and practical, even if a bit unusual.

Another bug…

I was wondering why autocomplete was not working and realized that Edit>Complete did not have a shortcut assigned (at least not on my machine).

So, I call the preferences, double-clicked in the Key field, and hit ESC… And the key setting dialog was dismissed without ESC being assigned to Complete. I thought that was cute :wink:

I tried to open the preferences and add the shortcut there, but the syntax was a bit obscure so I gave up.

That dialog should not be dismissed with ESC, only with the Cancel button, otherwise there is no way to assign that key to any command :slight_smile:

Technically, only combinations using the control and/or command keys can be used as keyboard shortcuts. To use esc would involve trapping keyboard input at a higher level. It can be done, but it would require a different UI.

I’m fine with that, but the Release Notes say that ESC is the key to access Autocompletion and for some reason that’s not the case on my machine. ESC doesn’t do anything. If there is a way to fix that that does not involve a new UI, I’m a taker :slight_smile:

Hey Jean-Christophe,

This is entirely because of changes Apple made in Sierra.

F5 is now the official completion key.


Thank you Chris ! If they had tried, I’m sure they could have found an even more inconvenient key…

I was trying to set TAB, which did not work either, so I guess I’ll settle for F1.

It would be nice though if SD described the Complete function as being assigned to F5 (both in the menu and in the preferences).

Oddly enough, F5 has always been the “official” key. I presume esc was added as a second option because someone agreed with you at some point.

I’m not sure how convenient esc is on the new PowerBooks where it’s not an actual key, though.

This has nothing to do with Shane or SD. This is 100% a bad decision, bad UI, on Apple’s part.

But who thought that “ESC” should be the auto-completion key must have been smoking something. Pretty much everywhere else “ESC” key means CANCEL, or at least, don’t do something. But auto-complete? Really?

The good news is that, at least with SD6, you can set the key you prefer for autocomplete. I’ve set ⌃A:

1 Like

“… methods and enums are all just a click of the escape key away.”

Always thought so, too.:+1:t3:

Coming back to this after a bit of research…

Yes, I believe it is a bug. But the bug, as far as I can see, is that the OS will not let you enter a keyboard shortcut using { or } when using a keyboard that has {} and [] on the same keys.

Apple’s apps display the same problem. Go to TextEdit. Format -> Text -> Align Left is assigned ⌘{. Now go to System Events and Keyboard -> Shortcuts. Try assigning TextEdit’s Align Left something else, and then try to set it back to ⌘{ – you can’t. It will show shift-⌘[.

Similarly, if you leave ⌘{ assigned and add shift-⌘[ to another command, the conflict will not be identified.

But of course when you type shift-⌘[, any menu item already assigned ⌘{ will still respond.

So I think this is one for Apple.

1 Like