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

Developer Essentials: Velcro Ties and Grid-It

Like most developers I feel compelled to carry around a cornucopia of cables and computer accessories because, well, “you never know”:

  • Phone cable, check.
  • iPad cable, check.
  • USB cable, check.
  • Mini-USB cable, check.
  • Micro-USB cable, check.
  • Earbuds, check.
  • Headphones, check.
  • HDMI adaptor, check.
  • Network cable, check.
  • Miscellaneous adaptors, check.

And so on. And on.
Until recently, I’d throw them all into the bottom of my rucksack and go. No hassle, until it came to finding the one I actually needed. If it was there at all — if I’d remembered to pack it — I’d then struggle to untangle it from the rat king that skulked in the bottom of that bag.

Thankfully the solution to this disastrous disarray was both simple and inexpensive.

Step 1: Velcro Ties


If you do nothing else to get your cables organised, buy a pack of Velcro Ties. Sold in various widths, they’re actually a single roll of Velcro, the hook and loop fastener, that you cut to length.

Loosely fold your cable and hold it in place by wrapping your Velcro round it (it will stick to itself). Result? No more tangles (TM, probably). For most laptop type cables — USB, etc — I’ve found the 10mm (1/2 inch) width works best. Each cable usually needs a strip about 5cm (2 inches) long. With 5m (15 feet) on a roll, you can sort out a lot of mess.

Step 2: Grid-It

Once your cables are permanently detangled , you’re ready to take it to the next level; the Grid-It.


Grid-It is one of those ideas that just seems so obvious when you use it for the first time. Comprised of a lightweight, firm base (optionally with a small pocket on the back) covered in rubberized elastic bands, it can easily accommodate dozens of cables or small accessories of varying shapes and sizes. Each is held firmly in place and won’t slip out in your bag or backpack.

They come in various sizes but I’ve found the medium (approximately the size of a sheet of A4 / Letter paper) to be more than sufficient for my everyday needs. Now, all I need do is slip my Grid-It into my rucksack and slip it out when I reach my destination.

Just two simple and inexpensive products and you’re organised. Slip on your headphones, sign in to, and relax in the knowledge that your essential cables are exactly where you need them to be and ready to use just when you need them.


The four Brackets extensions I use most often

When it comes to writing code I have no interest in using a bloated IDE or some “I do everything, but none of it particularly well” editor. I work mostly with HTML, Javascript, Node.js and need a text editor that does that job and does it without getting in my way. If I need FTP, or SSH or one of the many other tools that are useful to developers then I’d rather use the inevitably superior standalone versions, not have them cluttering up and complicating the editor. That isn’t to say that there aren’t some non-editing functions that can benefit from being integrated with the editor, just that I’d rather choose what those features are.

Unfortunately, Sublime Text is limping ever closer to an early grave, Atom is no closer to being usable (unless you enjoy swimming in a half empty swimming pool filled with treacle). End result; I switched to using Brackets as my day-to-day editor. By now, Brackets is well enough known that there’s no point in me singing it’s praises. If you still haven’t tried it then you should. Unlike the competition, it’s free, open source, multi-platform, expandable, modern and has a very low learning curve.

The beauty of Brackets is that the editor itself is written using web technologies — HTML, CSS, Javascript. This also means that anyone who knows these technologies can extend the editor with extensions. In January 2015 (the last date I can find stats for) there were 616 extensions from 371 different authors. Of course, not all of these extensions are going to be useful but many are. In no particular order, here are four extensions that I use every day:


Brackets Git
by Martin Zagora

This extension is both incredibly powerful and easy to use. An instantly accessible dialog gives access to most of the Git functions you’ll need day-to-day; Pull, Push, Stage, Commit and many more. The interface is clean, intuitive and unobtrusive but if you find the built-in commands aren’t enough there is one click access to a Terminal/Command window opened in the projects folder.

All of the available commands can be accessed from here.
All of the available commands can be accessed from the bottom panel
Git Diffs of changes are displayed in an editor dialog
Git Diffs of changes are displayed in an editor dialog

A particularly useful feature is that changes made since the last commit are highlighted by a coloured block in the editor gutter. Clicking this block reveals the changes and gives us the option to revert it with just one click.

Changes made since the last commit can be viewed and reverted if necessary
Changes made since the last commit can be viewed and reverted if necessary


Brackets ESLint
by Andrée Hansson

ESLint is by far the most most configurable and most useful Javascript linter. Install this extension and your code can be validated for adherence to your coding standards and style guidelines on each save.

Code is linted on save
Code is linted on save


Show Whitespace
by Dennis Kehrig

Does what it says on the label.

Whitespace Off
Whitespace Off
Whitespace On
Whitespace On


White Space Sanitizer
by Miguel Castillo

If you’ve recently started using JSHint, JSLintESLint or some other, lesser-known, linting tool, the chances are (depending on the strictness of the settings) that you were shocked by the number of errors or warnings your code generated. Many of these alerts will likely be the result of your excessive or perverse use of whitespace. Lines with trailing spaces or containing only spaces, mixed tabs and spaces — all common mistakes. Install White Space Sanitizer and those problems will soon be a distant memory. On every save (but before linting) your white space will be cleaned up automatically.


All of these extensions and many, many more can be installed directly from within Brackets using the Extension Manager or from their respective GitHub repos.


Web Tools, Weekly

It’s only been a couple of weeks since it launched but already Louis Lazaris’ “Web Tools Weekly” newsletter is shaping up to become an essential read, one that I look forward to dropping into my mailbox every Tuesday. In each issue, Louis presents a tip or tutorial, followed by a “round-up of various apps, scripts, plugins, and other resources to help front-end developers solve problems and be more productive”.

To date, he has introduced me to such diverse resources as

  • Prepos, a multi-platform alternative to the popular Mac-based CodeKit pre-processor
  • countable.js, a small Javascript function to add live paragraph, word and character counting to HTML elements
  • Heliuma tool for uncovering unused CSS across multiple pages of a website

With his first two issues Louis has set a very high standard – I hope he can continue to keep us informed and entertained.



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.





Adobe unveils Brackets, “A free, open-source code editor for the Web”

Adobe Brackets LogoAdobe today announced the general availability of Brackets, a lightweight, “free, open-source code editor for the Web”. Built entirely with HTML, Javascript and CSS (though currently running in a OS-specific wrapper rather than the browser) this is a very early release. In the few hours I’ve been using it, it has been generally stable on both Windows and Mac though it still suffers from lack of features and sluggish performance. Despite this it’s certainly usable and gives a good indication of where Adobe are heading with this app. Two of the features that are included are worthy of note, incomplete though they are:

  • Inline editing
    Also called “the quick editor”, this is definitely an innovation worth having. With this feature we can place the cursor over, say, a body tag and click Cmd/Ctrl-E and a small inline editor overlays pops up showing all of the css rules that apply to that tag, even though they may be defined in multiple, external files. Better yet, we can edit them in place and save them back to their original files, all without leaving our main editor window.
    This feature already works pretty well (it can be a little slow to open) – I’d really like to see it appear in other editors (Sublime Text, for example).
  • Live Development
    Live Deveopment  allows you to make changes in the editor and instantly see them applied in the browser, without having to refresh the page. If you work with two monitors or a large screen this can be a very productive way to develop. Mac developers may already be familiar with this kind of syncing from apps such as the excellent Live Reload though this is the first time I have seen it built directly into the editor.
    Unfortunately, I couldn’t get this to work reliably using Chrome 20 beta on OSX Lion… changes would sync and appear in the browser, only to be followed by an error message and a prompt to reload Chrome.
Both of these features are shown in the following video from Adobe:


Adobe are keen to emphasise that this is a very early, unfinished, pre-release version of Brackets with many missing features and a long way to go before it matches the polish or performance of other code editors such as Sublime Text. Despite that, it’s an ambitious project and has the potential to really deliver something fresh and innovative. I’d recommend that you get a copy and give it a try for a few days and, if you have any HTML, CSS or Javascript skills, have a look at the source code that comes with the download and consider making a contribution to help make it even better.