I’m certainly not an audiophile or a headphone-buying addict. But I am a musician, so appreciate my music not sounding like complete mush.

If you’re in same place as me, you’ll love the Sennheiser HD 201. They’ve got excellent sound quality for a £20 pair of headphones. No doubt I’m missing out on a lot of detail I would catch if I had a more expensive pair like the well-reviewed HD 280. But after using the HD 201 for six months, I can’t imagine myself buying headphones from anyone except Sennheiser, ever.

This is probably the entire point of this model: they’re cheap but reasonably good so suckers like me are so amazed, we want higher-end Sennheiser headphones. I won’t be surprised if these were loss-leaders for Sennheiser to build brand loyalty.

Hot on the heels of Daniel Jalkut’s script for re-enabling the old ⌘⌥L shortcut for opening the downloads dialog, here’s a new version of a script I’ve been using for a while. The old version was reliant on my particular Safari configuration, but the new one should work for everyone.

The script selects the web search box in Safari’s toolbar. I use Jalkut’s FastScripts app to assign this a keyboard shortcut. In my case, ⌘; (Command-semicolon), because the shortcut built-in to Safari for selecting the address bar is ⌘L. The search field is on the right of the address bar, and semicolon is the key to the right of L on the keyboard, so I think this makes sense. When my hands are already on the keyboard, it’s much easier to hit this shortcut then type my search than to move my hand to the trackpad/mouse, then move it back to the keyboard to type the query.

-- with apologies to Daniel Jalkut

tell application "System Events"
    if UI elements enabled is false then
        display dialog "This script requires that you enable 'UI Scripting' support for AppleScript. You will be prompted to authorize this change by the system. If you do not wish to authorize this, click Cancel."
        set UI elements enabled to true
    end if

    tell application process "Safari"
        set focused of (first text field of splitter group of group of tool bar of window 1 whose role description is "search text field") to true
    end tell
end tell

The first part is stolen directly from Jalkut. It ensures that GUI scripting is enabled, which is necessary for this script to work.

The second part, starting at tell application process "Safari", gets the search field via GUI scripting with its role description. My old script targeted it directly — text field 2 of splitter group 1 of group 2 of tool bar 1 of window 1 — but if you had customised your tool bar, it didn’t work. Jalkut’s script reminded me that a whose clause could more reliably reach the same UI element programmatically.

Since “search text field” is the role description of the search field, not the accessibility description, this script will work without modification even if you don’t use English as your language in OS X, and even if you don’t use Google as your search engine. If I had used the accessibility description, it couldn’t be guaranteed to work in either of these cases. (Unfortunately, Daniel can’t use this trick with his original script, because the role description of the download button is just ‘button’, and it shares this property with many other buttons in the Safari toolbar.)

If you want to install this script, you can install it with the AppleScript editor or just download a precompiled version and follow the same instructions Daniel gave in his blog post.

It’s no secret that I have a little bit of a religion about my use of BBEdit. While I am a bit goofy about it (sometimes deliberately), it’s not hard to see why I’m so attracted to the app: I spend just about every minute I’m using the computer with it open. If BBEdit isn’t open, I’m probably not working.

While it’s an old app (vintage 1992), BBEdit does not feel dated. The only signs of its classic-Mac heritage are a single icon, hidden in a drop-down menu in the FTP browser, and the fact that the Activity Monitor gives it away as a 32-bit app, written using the older Carbon framework. In fact, BBEdit 10 makes it feel more like a modern Cocoa application than ever. If I didn’t know better, I would guess at first glance that it’s a Cocoa application.

Overview.

A text editor is an application for which aesthetics are not as significant as functionality. Nevertheless, BBEdit is a handsome application. Its decidedly minimal window layout consists of just a toolbar containing a small amount of information and display options; the text area; and a thin bar displaying more document information, such as word count, source language, and encoding.

Once dug into, it can reveal more UI elements as needed, like a sidebar for file browsing. This isn’t there until it’s needed, however, so BBEdit always seems to make excellent use of the available screen space.

BBEdit continues to offer an excellent set of built-in features. Text manipulation tools like hard-wrapping, email-style quote level alteration, automatic commenting/uncommenting of selected text, quote education, tabs-to-spaces conversion (and vice-versa), and many more are built in to the editor as standard — and the ability to write filter scripts makes the addition of further tools simple for those who know any standard Unix scripting language.

The text search tools are another point of strength, offering text-search through multiple files, regular expression search (using the familiar PCRE library), function navigation, among others. Particularly useful is the built-in syntax-aware reference tool, which can load the documentation for a selected symbol at the touch of a keyboard shortcut, depending on the language the file is written in.

Now that I’ve introduced BBEdit to those who might not be familiar with it, let’s dive into some of the changes in version 10.

Windowing changes.

As a BBEdit 9 user starting up version 10, the first thing I noticed is the new disk/project browser arrangement. Gone is the drawer, and replacing it is a new unified left sidebar, containing the file hierarchy, the currently-open files, and a new view of recent documents.

I think this new arrangement is far better. In project views, the drawer was unnecessary and took up too much screen space. I’ve been hoping for exactly this change since I first started using BBEdit.

The removal of the drawer also affects non-project windows, so now if you open two files in a window which was previously a normal window, it opens the same sidebar with just the currently open documents and recent documents sections. This is a good thing too. BBEdit treats even windows with one file open as a project window. If you want to see the sidebar even for single files, you can drag from the left border of the window inwards and it will show.

BBEdit 10’s default window size is far wider than in previous versions. On my screen, it takes up about half of the horizontal space. You can customise this, but because BBEdit now treats single-file windows as project windows, setting the size of the window will also affect the size of a project window. So when you open a project window, you’ll see that the sidebar in fact takes space away from the size of the editing field. One possible solution is to always show the sidebar, even when there’s only a single text document open in a window, but this doesn’t seem to be possible. I’d much rather be able to set separate default sizes for project windows and single windows.

What I would like is to always have the editor field take up the same number of pixels, and the sidebar’s presence to cause the window to get bigger but the editor text field to stay the same size. The fact that it doesn’t behave like this is my single biggest frustration in BBEdit 10.

In addition to the changes to editor windows, the HTML preview window is now full-size, taking up every pixel it’s possible for a non-full-screen app to take. This is annoying but can be configured without ill effects.

HTML editing.

HTML is BBEdit’s traditional home ground. It was mainly because of the lack of a good HTML editor for the Mac that BBEdit was successful in its earliest days.

BBEdit 10 radically modernises the HTML editing interface. Previously, the interface consisted of clunky modal dialog boxes with far too many input options full of clues that it was a part of the app left untouched since the early OS X days. They even still used QuickDraw for text rendering. Here’s a screenshot.

The new editing boxes are very minimal popovers, which are non-modal and appear at the spot where the tag will be inserted.

There are some issues with this new arrangement. The popovers are too easy to dismiss by clicking outside of them or switching to another app. Yes, yes, popovers usually vanish when you click outside them, but in this case, you quite often want to move to another window to copy a URL or refer to some documentation while you’re in the middle of composing a tag. Also, once you’ve dismissed a popover, if you bring up the same tag maker again, it doesn’t display the info from the one you dismissed — it’s lost forever.

What would be better is if either the information you had already entered was restored when you re-open a dismissed popover (with an button to blank out the data already entered), or the popovers were not dismissed without explicitly clicking a cancel or close button. (They should also be dismissible with the escape key.)

The poor interface of BBEdit’s HTML tools before meant I rarely used them, and I used only very few of them, like the re-formatting tools, syntax checker, and the text-to-HTML converters for translating Unicode characters into entities automatically. Now, though, I find myself reaching for them more often. Bare Bones have significantly improved what I previously considered the worst aspect of their application.

Preferences.

The preferences window is another point of significant improvement in BBEdit 10. Version 9’s dialog was divided into 24 sub-panels. The new window has whittled that down to just 12. And that’s not to say there are fewer preferences: Bare Bones has increased the information density of each panel so that roughly the same number of options fits into less space. This is not a bad thing.

The new window also follows Apple’s trend of automatically-resizing preferences. The window changes size so that the options available in the selected panel always exactly fill the window — no more, no less.

The appearance of the window now almost harks back to the control panel in System 6:

This has generated controversy, but I like it. It’s clearer where the preferences are, and they’re easier to get to. I think it’s a win.

Siracusa-esque ‘Grab Bag.’

Dropbox sync.

You can now put your BBEdit Application Support folder in your Dropbox and sync it across multiple machines and it will be recognised. For people working with BBEdit on multiple computers (perhaps at home and work, or on both a desktop and laptop machine) this is a huge convenience.

Packages.

Packages are a new feature that promise a lot. They’re bundles which can be dropped into the Application Support folder, which contain features like (for now, this is all) clippings, language modules, scripts, stationery, and text filters which work in addition to the stuff inside the support folder.

If this doesn’t seem like a big deal, you’re wrong. Once this feature starts getting more functionality, it will be completely normal to download a “BBEdit package” for a language or purpose. It’ll be much easier to keep BBEdit additions organised.

The fact that Bare Bones has marked certain files as “reserved for future use” assures me that packages will become more functional over time, perhaps being able to fully replace BBEdit’s old plugin architecture that was done away with in version 9.6.

Change Case moved.

Change Case now has its own submenu with separate items for each of the options. This means it’s possible to assign a keyboard shortcut to a change case command for the first time. However, the old dialog box is still there if you prefer it.

Preview improvements.

You can now apply HTML and CSS templates to the Markdown preview. No more Times!

Search inside compressed files.

Amazingly, it’s now possible to run a multi-file search on documents inside a zipped archive. This could be quite useful.

Conclusion.

BBEdit 10 is a solid upgrade. It’s fixed a lot of quirks that made the app feel old. Now it just feels reliable.

There are still some annoyances, however. It still doesn’t recognise blocks in Ruby for balancing and folding, for instance. And in terms of Lion support, BBEdit 10 already supports full-screen operation, but it’s a little buggy with regards to closing a window, and it doesn’t yet support file versions (though BBEdit’s own auto-save and state restore features do make up for the lack of those features in apps). Nor can you resize the window from any edge like in other Lion apps.

It’s also still quite easy to lose the Find dialog in a stack of windows. I’d prefer if it was a panel which always floated on top of all the open documents, instead of a normal window which is so easy to accidentally leave behind a stack of others.

BBEdit 10 also seems to be a very direct attack on TextMate, the editor whose 2.0 release has been ‘Coming Soon’ for nearly 5 years. With the TextMate community tired of waiting, Bare Bones is reaching out to them with a modern application which offers many of the same features. This should appeal to BBEdit users, too — BBEdit 10 is very much the stuff I liked about BBEdit plus the things that intrigued me about TextMate.

BBEdit can serve as an excellent example to those who need proof that an old Carbon application can be updated to feel like a 2011-class Cocoa application. And while a Cocoa version of the editor would be nice — and has been all but confirmed by Rich Siegel — the BBEdit of today is a smart, reliable application for editing text files on the Macintosh. Highly recommended.

I have carried pocket notebooks, and I have carried refill pads. I’ve tried loose index cards and the Hipster PDA. I have had them bound, punch and perforated. I’ve tried pencils and pens.

I have never managed to make a habit of taking notes and planning on paper.

Some people say I’m a deep thinker. I think I’m an over-thinker, but I certainly prefer to think things through and hold them in my head before I start working on something, instead of plotting it out and outlining on paper.

For example: for my most recent personal project, my own dialect of the Lisp programming language, I have not yet made a single plan outside of my head. I’ve written programs in it on squared maths paper (which is insanely fucking difficult and will always make you wish you had access to a computer when you do it) but all of the details of the implementation, as yet, have been kept only in my thoughts from the start.

All that happens when I do use a paper notebook is that I end up doing endless, pointless doodles and occasionally writing long-form in it.

The only outlining I’ve ever managed to pull off is planning for a public speech. Writing the plan of the speech on index cards makes it far easier to keep track of my topic and points during the talk.

To be clear, it’s not specific to paper; I’ve tried Yojimbo and text files, too, but on the occasions when I have outlined and diagrammed, paper has always seemed much easier for me.

Many programmers have told me how useful their notebooks are. There are many pages exhorting their benefits. I’ve never found myself in the habit.

I’ve always found that the best way I work is just doing it, keeping the plans in my head and letting my thoughts evolve along with the output. It’s probably part of the reason I like Lisp and its notion of bottom-up programming — the effect of building things in layers creates such flexibility of expression that it’s entirely natural for the program to evolve alongside your thoughts.

Perhaps I’ve been doing it wrong. But note-taking has never really managed to hold my interest and be effective in mapping and recording my thoughts.