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

Use ‘eslint-annotated-reset’ to introduce linting to your legacy project

Introducing linting to a badly maintained legacy project can be a traumatic experience but the stress can be drastically reduced by careful use of ESLint and eslint-annotated-reset.

You’ve finally got agreement – you’re going to introduce linting of your Javascript code to your project, a project that’s desperately in need some TLC. Naturally, after careful evaluation, your linter of choice is ESLint, but when you run it against your code base you’re overwhelmed by the number of errors:

627 errors? When are you going to get time to fix those?
627 errors? When are you going to get time to fix those?

In the image above, taken from a real-life project that shall remain nameless to protect the guilty, we can see an all-too-common result of simply applying ESLint with the default settings; legacy code that generates hundreds, sometimes even thousands, of errors per file.

Of course, you want to resolve those problems. You want clean, consistent and maintainable Javascript. That’s why you’re introducing ESLint in the first place. But… you also want to meet your deadlines and they don’t necessarily allow for a massive refactoring of your code. Neither do you want to alienate your team, some of whom may already be hostile to linting and eager for opportunities to derail its introduction.

It was for exactly this situation that I created eslint-annotated-reset. This is simply an ESLint configuration file – .eslintrc – that you download from GitHub and drop into the root folder of your project. The next time you lint your code you’ll notice a drastic change; zero errors or warnings. The reason for this is simple, all of the linting rules have been turned off!

the easiest way to eat an elephant is one bite at a time

Why would you run ESLint will all of the rules turned off? eslint-annotated-reset is based on the principle that “the easiest way to eat an elephant is one bite at a time”. You may not have time to resolve 600 errors today but you might be able to resolve 6 or maybe even 60. After turning off all of the rules by dropping the .eslintrc file from eslint-annotated-reset into your project you can then selectively and methodically turn the rules back on, one at a time.

To turn a rule on, simply:

  • edit the .eslintrc
  • locate the rule you want to implement
  • change the setting from 0 (off) to 1 (throw a warning) or 2 (throw an error)

Let’s say we want to fix some of those 627 problems we saw earlier. Let’s start by making sure that all equality tests use “===” or “!==” rather than “==” and “!=”. That’s considered a best practice and can help prevent pernicious  bugs.

After opening .eslintrc  we locate the rule, in this case called “eqeqeq” (you can find these names in the console output from ESLint). There it is on line 63. We can confirm from the description that it’s the rule we want (that inline description is where the “annotated” in the name comes from).

"default-case": 0,     // require default case in switch statements
"dot-notation": 0,     // encourages use of dot notation whenever possible ***
"eqeqeq": 0,           // require the use of === and !== ***
"guard-for-in": 0,     // make sure for-in loops have an if statement
"no-alert": 0,         // disallow the use of alert, confirm, and prompt

A simple change to turn the rule on:

"default-case": 0,     // require default case in switch statements</pre>
"dot-notation": 0,     // encourages use of dot notation whenever possible ***
"eqeqeq": 2,           // require the use of === and !== ***
"guard-for-in": 0,     // make sure for-in loops have an if statement
"no-alert": 0,         // disallow the use of alert, confirm, and prompt

and we can rerun ESLint:

A much more manageable 26 errors
A much more manageable 26 errors

The eqeqeq rule is now the only one turned on and we have a much more manageable 26 errors. We can make and commit those changes and take a further bite of our elephant another day.

When you’re updating .eslintrc bear in mind that some rules take optional parameters in addition to the 0, 1 or 2. In eslint-annotated-reset these are indicated by three asterisks at the end of the description. You can find more details of the allowed options on the ESLint web site at:

For example, the documentation for the ‘eqeqeq’ rule can be found at:

Details of the eqeqeq rule from the ESLint website
Details of the eqeqeq rule from the ESLint website

The current (first) release of eslint-annotated-reset includes all rules included in version 0.20.0 of ESLint, released on 24th April, 2015. For convenience, the rules in .eslintrc are organised in the same way as they appear in the documentation pages of the ESLint website. As new rules are added to ESLint, eslint-annotated-reset will be updated to ensure they are always in sync.

ESLint allows you to choose which rules and stylistic conventions you want to apply to your Javascript code. With eslint-annotated-reset you can apply them at your own pace.


The work #4

Your code isn’t important: what matters are the ideas your code brings to life. Shitty code that makes a point is better than perfect code that proves nothing.

Don’t waste your short life getting lost in the geeky details of the toolkit du jour. Spend it using your skills to create something that matters to you, that may even last longer than you.

Most developers have far more power than we realize but too many of us squander it building things we don’t care about. Now is your time to make a difference. If you don’t do it now it may never happen.

— Nick Bradbury, “Code is Temporary”


Starting Brackets from the Mac terminal command line

With the imminent release of Brackets 1.3 we now have the much-needed ability to easily start the editor from the terminal.

Setup of the command line shortcut takes just a couple of minutes:

1. Install Brackets 1.3

The latest version should be released for automatic update in a few days but if you can’t wait you can download the pre-release version right now from the Brackets GitHub repository.

2. Install the Command Line Shortcut

Start up Brackets then select the File… Install Command Line Shortcut menu item which now appears at the very bottom of the File menu.

Install the Command Line Shortcut

You’ll be asked to confirm your password, then the shortcut will be installed.

If everything went smoothly you’ll see a confirmation message and Brackets will be ready to use from within terminal:

Brackets Command Line tool installed

Notice that you can open a single file or switch projects.

3. Start Brackets from within terminal


As is common with other GUI apps started from the terminal there is one peculiarity:

  • If Brackets is closed, it will be started, the file (or project) to be edited will be loaded and the app brought to the front
  • If Brackets is open but not on top (or in another space), the file (or project) to be edited will be loaded and the app brought to the front
  • If Brackets is minimised, the file (or project) to be edited will be loaded but the app will not be brought to the front. This can be confusing if you haven’t seen this behaviour before because it appears that nothing at all has happened.

More info about Brackets 1.3 can be found in the release notes on GitHub.
Command line startup can also be set up on Windows; brief details are in the release notes.

‘onelineperfile’: a custom formatter for ESLint

‘onelineperfile’ is a new custom formatter for ESLint that, unsurprisingly, displays one line per file. Linting details are displayed whether the file passed linting or not.

If you use ESLint you probably already know that it comes with six formatters (a.k.a. reporters) that allow you to change the way that messages output by ESLint are reported.
Briefly, the six styles are:

Stylish (the default formatter)












Each of these are good for what they do but none of them are exactly what I need, which is output with:

  • One line for each file processed
  • Each line to indicate the status of the linting; success, error or warning
  • Each line to indicate the number of errors / warnings, if any
  • No error details to be displayed, I can check and fix that in the editor if needed
  • A summary line showing the total number of files processed, the number which passed linting and the number with warnings or errors

The reason for these requirements is to allow the output to be used in an audit trail, for example as the result of running a Git pre-receive hook; I should easily be able to check that a particular file was linted and it’s status.

Luckily, ESLint is very extensible so I created a new formatter — onelineperfile — which meets all of my criteria.

Here’s sample output:


The easiest way to add it to your project is using NPM:

npm install --save-dev eslint-onelineperfile

You can then run it directly from the command line:

eslint --format node_modules/eslint-onelineperfile/onelineperfile.js <span class="keyword operator shell">*</span>.js

If you prefer to automate ESLint you can do so using Grunt ESLint:

    eslint: {
      options: {
        format: require('eslint-onelineperfile')
      target: ['*.js']

grunt.registerTask('default', ['eslint']);


The work #3

Some mornings, in a perfect world, you might wake up, have a coffee, finish meditation, and say ‘Okay, today I’m going into the shop to work on a lamp.’ This idea comes to you, you can see it, but to accomplish it you need what I call a ‘setup.’ For example, you may need a working shop or a working painting studio. You may need a working music studio. Or a computer room where you can write something. It’s crucial to have a setup, so that, at any given moment, when you get an idea, you have the place and the tools to make it happen.
If you don’t have a setup, there are many times when you get the inspiration, the idea, but you have no tools, no place to put it together. And the idea just sits there and festers. Over time it will go away. You didn’t fulfill it – and that’s just a heartache.

— David Lynch, “Catching the Big Fish”