-2
Brandon Fosdick 5 years ago • updated 5 years ago 2
For example, Option-Command-Arrow triggers code folding/unfolding in Xcode, but it changes tabs in ST2. Switching tabs in ST2 could use the Ctrl-Command-Arrow shortcut that's used for history forward/back in Xcode, or it could use Shift-Command-SquareBracket, to be consistent with Terminal's shortcuts.
You can customize your keybinds in Preferences->Key Bindings - User, and copy what you need from ->Key Bindings - Default.

Modifying ST2's default keybindings to conform to one specific other editor doesn't seem like a good idea, since other editors may not conform to those changes. However, this does sound like a good target for creating a sublime plugin for the task -- "Xcode Keybinds for Sublime Text 2" for instance.
You are right in that ST2 shouldn't try to conform to another editor, per se. Although, there are a lot of "standard" behaviors that are only standard because some other editor did it first. So in that sense it's not a bad idea.


Regardless, my (badly stated) point here is that apps should endeavor to integrate with the dominant paradigms of the host system. OS X apps should behave like OS X apps and Windows apps should behave like Windows apps. OS X in particular has a lot of system wide defaults and behaviors that users expect apps to conform to.


For instance, switching tabs...the Terminal app uses Cmd-Shift-Bracket. If you open Safari you'll notice that it uses the same shortcut. Firefox and Chrome do as well, despite using different shortcuts in their Windows versions. Xcode is the dominant development system on OS X and as such has set a lot of expectations.


In order to "be a good citizen", the default settings for the various ports of ST2 should conform to the expected behaviors of the respective host systems. Currently, the default keybindings for the OS X port conflict with expectations.