CamelCase cursor movement in Xcode

259 words (about 2 minutes.)

I mostly write Swift in Xcode these days. I can’t say I miss Java. I do, however, miss IntelliJ IDEA, and specifically, the little CamelHumps option:

A checkbox with the title: ‘Use “CamelHumps” words’

This changes the behaviour when using the arrow keys to navigate between words (⌥+→, ⌥+← on MacOS) so that it respects CamelCase—i.e. it treats the word CamelCase as two words, rather than one. This certainly made it easier for me when it came to renaming variables with long names:

A moving image: an IntelliJ IDEA text editor where the cursor navigates forwards and backwards word-by-word. When it comes to a long CamelCase word, it treats each CamelHump as a separate word.

I was always annoyed that Xcode didn’t seem to support this behaviour. It turns out it does! Xcode calls this ‘Move Subword,’ and by default maps it to the Control (^) key:

A screenshot of Xcode’s Key Bindings preference pane. “subword” is in the filter box, and four entries are selected: Move Subword Forward Extending Selection (mapped to control + shift + right), Move Subword Forward (control + right), Move Subword Backward (control + left), Move Subword Backward Extending Selection (control + shift + left).

The immediate problem is that in all recent MacOS releases, ^+→, ^+← are mapped to workspace switching. Indeed, the default configuration warns it might be overridden by System Preferences!

You can, of course, just re-map it to the ⌥ key and override the default behaviour. Once you’ve cleared the conflicts, it works quite well…

A screenshot of Xcode’s Key Bindings preference pane. “subword” is in the filter box, and four entries are selected: Move Subword Forward Extending Selection (mapped to Option + shift + right), Move Subword Forward (Option + right), Move Subword Backward (Option + left), Move Subword Backward Extending Selection (Option + shift + left).

A moving image: an Xcode text editor where the cursor navigates forwards and backwards word-by-word. When it comes to a long CamelCase word, it treats each CamelHump as a separate word.

The one caveat

The trade-off, at least as of Xcode 10.2.1, is that subword movement doesn’t seem to work in all of Xcode. And since the keymap applies for all of Xcode, this means you can no longer navigate by word or subword in:

  • the filename input
  • the source control commit sheet
  • anywhere else you’d normally be able to navigate by word other than the editor

I assume this is a bug, and I presume it’s long-standing enough that Apple hasn’t bothered to find a new default shortcut for subword navigation that doesn’t conflict with the MacOS defaults!