Dash, the documentation browser and code snippet manager for OSX, now includes a cheatsheet for Brackets editor, version 1.3
Dash is an excellent offline documentation browser and code snippet manager for OSX and iOS (though there are also “officially sanctioned” 3rd-party versions for Windows and other platforms).
Yesterday I submitted a pull request to the cheatsheets repo on GitHub that adds a cheatsheet for Brackets 1.3 keyboard shortcuts to Dash. Earlier today my change was accepted by Kapeli (a.k.a. Bogdan Popescu) and the cheatsheet is now available for download from within Dash.
To install it, first open the Dash Preferences then:
This version of the cheatsheet covers keyboard shortcuts for Brackets for Mac, version 1.3.
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.
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:
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.
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 manyprojectsmakeuseofit.
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.
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.
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.
If you’ve recently started using JSHint, JSLint, ESLint 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.
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: