Sensible global shortcut key definitions for iTerm2

Despite being a Mac-only product, the terminal replacement iTerm2 defaults to using very un-Mac-like shortcut keys. Fortunately, this is easily remedied.

Earlier today I updated my configs repo on GitHub to add the settings I use for the OSX terminal replacement iTerm2. When I installed iTerm2 I left many of the settings unchanged from their presets but one section I immediately updated was the global shortcut keys. These are initially set to reflect the illogical, outdated and downright bizarre shortcuts used in the editors of yesteryear – Vi and Emacs – and I wanted them to behave more like the standard OSX shortcuts. Thankfully, iTerm2 makes this very easy to do.

The shortcuts can be configured in the Keys section of the preferences (accessed via the iTermPreferences menu item). Below are my updated settings:

iTerm2 global shortcut keys redefined to be more OSX-like
iTerm2 global shortcut keys redefined to be more OSX-like

Only 7 key combinations were changed:

  • ⇧⌘↑ became Scroll One Page Up
  • ⇧⌘↓ became Scroll One Page Down
  • ⌃⌘↓ became Scroll To End
  • ⌥← became Send ^[ b i.e. Move Cursor Left One Word
  • ⌘← became Send Hex Codes: 0x01 i.e. Move Cursor To Start Of Line
  • ⌥→ became Send ^[ f i.e. Move Cursor Right One Word
  • ⌘→ became Send Hex Codes: 0x05 i.e. Move Cursor To End Of Line

Shortcuts are redefined by double-clicking on the entry then selecting the new action to be applied. In most cases you simply want to chose a predefined action such as Scroll to End:


though for Move Cursor To Start Of Line and Move Cursor To End Of Line you should chose Send Hex Code as the action and enter the appropriate code (0x01 for start of line and ox05 for end of line):



Similarly, for Move Cursor Left One Word and Move Cursor Right One Word you should chose the Send Escape Sequence action and enter the appropriate code (b for left one word and f for right one word):



After closing the preferences dialog your new shortcuts will be available for use.


  • iTerm2
  • configs – some of my config files, including the one I use for iTerm2

Ensuring editing consistency with .editorconfig

Today I updated my recently created GitHub repo configs to include my .editorconfig file. EditorConfig is one of those incredibly simple ideas that I initially hesitated to install (“is that all it does?”) but now find invaluable. By defining a few properties in a file that you store in your repo, usually in the root, you can go some way to ensuring that everyone that works on your source uses the same basic whitespace settings; indent style, indent size, line terminator, and so on.

Nowadays, many (most?) editors allow for settings at both the user and project level, but often a project repo doesn’t include a settings file for the project or, if it does, it’s for an editor that you don’t use. If you work on multiple projects with differing conventions or even just in a team where everyone uses their own favourite editor, EditorConfig can ensure consistency of layout and less time wasted in reformatting.

EditorConfig consists of two parts; a simple configuration file, .editorconfig, and an editor/IDE plugin. Once you have selected and installed the plugin for your preferred editor (at the time of writing there were over twenty available) you can set your preferences and you’re ready to go. As it’s a simple text file it can be checked into your repo to ensure that everyone working on your project shares the same settings.

The config file allows eight properties to be set with seven of them allowing you to control the appearance of your code.


EditorConfig is one of those things, like Markdown formatted ReadMe’s, that has become ubiquitous in open source projects. Even a cursory browse through GitHub or BitBucket will reveal that many projects make use of it.

My own .editorconfig can be found in my configs repo, a small collection of my most-used config files on GitHub.



jList: CodeKit project configuration file added to GitHub

The last few years has seen an explosion of techniques, tools, libraries and frameworks introduced for web developers – jQuery, Node, SASS, Less, Compass, templating, CoffeeScript, jsLint, jsHint and many, many more. Unfortunately, this means that producing even a relatively simple web page can become a multi-step process. Even jList, my simple, single file Javascript library which has no runtime dependencies, must be run through jsLint, then Uglify,js (each with their own preference settings), then Jasmine, every time a change is made. Worse still, as a project grows the number of tools and the complexity of their interactions may increase significantly.

Luckily, if you are a Mac user, help is at hand in the shape of CodeKit. Described by it’s developer as “like steroids for web developers”, a statement I wholeheartedly agree with, CodeKit lets you automate and streamline your development process. For jList, this reduces my cycle of change / save / run jsLint / run Uglify.js (if jsLint was ok) to the more manageable change / save. Better still it makes sure I don’t accidentally skip a step in my hurry to complete a change.  With many more features such as Less compilation, file concatenation and live browser reloads, CodeKit quickly becomes an essential, time-saving app.

CodeKit showing the jList project files

What all this is leading to is that I have now added the CodeKit configuration file I use for jList to the project in GitHub. To quote from the CodeKit help:

When you add a project to CodeKit, the app will look for a file named “codekit-config.json" in the project’s root folder. If it exists, CodeKit will automatically set up the project to match the configuration file. First, it will apply the project defaults from the file. Then, it will change each file’s settings to match those recorded for that file. (If it encounters a file that is not described, it will use the project defaults to set initial options for that file.)

So, simply dragging jList into CodeKit will give you all of the settings I use while developing it. It’s a simple enough configuration but having it included in the repo is a time-saver and will allow you to easily replicate my process and settings should you be changing jList.