BBEdit 9

Barebones have just released a new version of the venerable (17 years and counting!) Mac text editor, BBEdit.

For me, and I suspect most other people, the most important addition is the new Projects feature. Over the last few years, it seems like I've been experimenting with a different text editor every other week. It wasn't that I didn't like BBEdit (more on this in a bit), but that I couldn't help thinking that constantly switching to the finder to open files was sucking up an awful lot of time. So, having tried and failed to find another editor that I really liked, I now find that Barebones have finally got around to answering my prayers. The BBEdit implementation of projects is not without its problems, however.

Open, Slowly (⌘⇥)

For starters, there doesn't appear to be an 'Open Quickly' feature (as in Xcode or TextMate).

This is a curious omission. Since setting up a project implies you'll be working on several files at once, it's strange that opening a different file in the same project is still awkward. I should have thought this is the one area where users could get the biggest productivity boost from a project-orientated workflow, but no dice.

I do hope this feature will show up in 9.1.

Not got Git?

Michael Tsai highlights the lack of Git integration in his beautifully succinct roundup of the new release. I was thinking the same thing when I tried out the new version of Coda a few days ago - I know I said I wanted SVN support when you brought out 1.0, but, well, I...

Then I realised that I never actually use SCM integration features anyway. BBEdit has had SVN integration for a while, as has Xcode, and I still have a decent number of projects in SVN, but I guess I just don't see the point. A visual SCM tool needs to make some task that would be a pita to accomplish in the terminal straightforward. Github seems to pull this off nicely - the visual diffs are great, but I suppose I need this fairly infrequently anyway, so having it built-in to an editor isn't that important to me. For my workflow, something integrated into the file browser, like Tortoise SVN or SCPlugin would probably make the most sense. Adding new files to repository tends to be about the only thing with SCM that regularly takes any time at all, but I guess once you're used to the command line tools, it's hard to break the habit.

Actually, the projects feature doesn't really fit with the SCM stuff in BBEdit. You still specify your SCM servers in the preferences window, rather than attaching them to a project. In fact, projects don't really seem to have any settings at all - once you've made a project, and added files, you've pretty much reached the end of their capabilities. You can't specify SFTP servers, or remote/local URLS for testing. You can't even give a project a name, beyond the file name of the project file, and even this isn't exactly prominently displayed for ease of switching between open projects. I guess a lot of this comes down to the fact that BBEdit is intended to be a general purpose text editor, rather than an IDE for web development, but given the array of HTML tools it provides, I can't help wanting a little more.

A waste of space

Something I really dislike about BBEdit's projects implementation is the way it handles the list of open files. BBEdit added the open files drawer a few versions back, and I can't say I've ever really taken to it:

For starters, it's a drawer, but I won't go into why they suck so badly here. But look what happens to a project window in BBEdit 9:

That's right: by default, you lose screen real estate on BOTH sides of the edit window! The left side is the list of projects, the right side is the list of open files. Simple, you think, I'll just hide the open files list. Then, when I come to open another file in the same project - ARGH, it pops open again! Don't worry: BBEdit lets you turn off the drawer in the preferences window, so it won't keep popping out. But wait, this is a global preference! You'll have to turn it back on when you're not working on a project, unless you want to resort to switching the active file with the toolbar menu or the Window menu.

This is not an easy problem to solve. If you have files that haven't been saved yet, or are editing a file that isn't in the project, you can't just show them in the project's file list. So how do you get to them?⁽ⁱ⁾

TextMate uses the tabbed approach to handle this:

This is great for saving screen space, but this model soon breaks when you want to open more than 5 or 6 files at once:

Here is my (Coda-inspired) suggestion for what might have been been a better approach:

Basically, we show both the open files list and the list of files in a project in the same area, with tabs to switch between the two lists.

This way, we always have a list of open files on the left hand side, even if we aren't working in a project, but we can swap it for the list of the files in a project when we are. The project files list SHOULD also show which files are open (I've put them in bold, like TextMate): again, this small feature seems like a no-brainer for 9.1.

Relatedly, those project-orientated toolbar buttons that appear above the files list are more or less useless. I don't need an add or remove button, and I ought be able to rename project items by clicking on their names and waiting.

The complete package

BBEdit 9 also introduces auto-complete, as in the good kind that finishes words for you, rather than the bad kind that starts pairing up your HTML tags and function curly braces. It doesn't seem to work perfectly yet (it failed to autocomplete a couple of standard PHP functions I tried), but I think this is a welcome, albeit long overdue, addition. It even allows you to tab between the various arguments for a function (I still haven't figured out how to do this in Xcode!).

I find you very unfamiliar

The find and replace functionality has had an overhaul in BBEdit 9. The find dialog is now non-modal, and multi-file find has been split into a separate dialog. I could write about how much better this new arrangement is, but I must have spent so much time looking at the old dialog, I think it's going to take me a while to adjust.

Still broken

There are a few of things that still bug me about BBEdit:

1. Preferences window

   It's still ugly. It's still really hard to find what you want⁽ⁱⁱ⁾. The text is still too small. I still don't really think that stuff like FTP sites or SCM repos belong in global preferences.

2. No colour themes

   It's a small thing, but I really like being able to try out different colour themes easily (as in Terminal or TextMate). BBEdit lets you change all the text colours, but offers no theme support. I really don't want to waste my time trying to find a black background set of colours that work for me. Someone else has done this before, and they probably have better taste than me. Why not give me a range of presets, and the ability to customise and share new versions?

3. No CSS validation

   Yeah, it's easier to pickup CSS problems than HTML problems, especially since Firefox gets so shouty about them in the Error Console, but this would be a helpful timesaver.

Still golden

There are a few things about BBEdit that I really love. Every time I experiment with another code environment, these are the things that I find myself unable to do without:

1. Speed

   I don't think I've ever found a faster editor that I actually wanted to use. It appears to handle big files with ease, multi-file find is lightning fast, and you very rarely see it trying to catch up with syntax colouring. I suppose this isn't really a feature - I'm just reminded of it whenever I play with TextMate, an otherwise great piece of software that fails so MISERABLY speed-wise.

2. It doesn't attempt to guess what I'm trying to do.

   It won't try to close my tags for me. No doubt you can turn this feature off in many editors, but first impressions are important - just because I can turn off Power Pup, doesn't mean he should be there in the first place. I find this stuff really off-putting in TextMate.

3. Information I want frequently is always visible

   The charset and line ending format for the current document is always shown at the bottom of the window, and I can convert between charsets and line endings with a single click. This is not rocket science. Why doesn't everyone else do it?

4. Really nice HTML tools

   HTML / XHTML validation. HTML Tidy. Tag editor for when I can't remember the obscure attribute name. TextMate gets some of this right, and while technically using the W3C Validator tool may give you the most correct results, it doesn't make it super easy to see and fix problems in your document. It just presents the problems in a mini browser window, you need to find the line number, then switch back to the editor window to find the issue in your code.

5. Really useful text tools

   Zap Gremlins and Find Differences stand out for me, as I seem to find myself using them all the time, but there are so many wonderful text tools in BBEdit. Some of these you might only ever use rarely (e.g. Sort Lines, Normalize Line Endings etc), but it saves writing a script to do this stuff for you.

In short, BBEdit remains the king of Mac text editors in my book. Hopefully some of the niggles mentioned earlier will disappear in the next couple of point releases, and Projects will in time grow into an implementation that software this wonderful deserves.

1. You use Open Quickly, of course. Oh wait...
2. You can use the preferences sidebar and search for the feature you want. But this looks to me like an admission that the prefs window is unwieldy, rather than a real solution to the problem.

Posted by Ben @ 20:08 PM

The Git Switch

It must have been months ago that I watched Linus Torvalds' presentation on Git. At that time, I remember thinking it probably wasn't for me. I already had a source control system that worked and did everything I wanted. I generally worked on projects on my own, and didn't need to worry about how long it took to merge other people's changes. Git was supposed to be better at branching, but I never branched my code anyway. Git had a distributed model, but the centralised approach worked fine for me. People were saying that Git was harder to use. Etc.

If I think back to before I started using source control a few years ago, I had a whole set of reasons for why I didn't need it. I largely wrote code on my own. I kept copious backups. A lot of my source code was stored in binary format RealBasic project files that couldn't be diffed. I didn't see why I should have to keep fiddling with the terminal every time I changed something. Excuses, excuses.

Of course, source control is one of those things that you find impossible to live without as soon as you start using them, and all the excuses I'd made became unimportant overnight once I got began using SVN. Starting to use source control was a revelation: things that were fiddly became easy, and things that were time consuming became things the computer did for me.

After a fair amount of prevaricating, I've made the jump to Git for several larger projects. This switch has been a revelation too, albeit a smaller one than starting to use source control.

Unless you're the smartest and most organised person on the world (in which case, what are you doing reading this?) or are currently in higher education, you probably have limited time available to learn new things. Why should you devote time to learning Git, over and above say, playing GTA? I'll note a few reasons why you should give Git a go, with a emphasis on migrating from Subversion, since that's the way I came in. However, it's worth noting that fair few of the things I find so compelling about Git are features of other modern SCM systems too, so do shop around for the best deal.

Why do I want Git?

Apart from a really cool name, Git has lots of great things going for it. A couple of the obvious ones:

• Every checkout is a complete repository, so you can still commit, revert and explore the history of a project, even when you're offline
• De-centralised design means you can push batches of commits to another checkout (eg a repository that other developers publish their changes to) whenever you like
• It's very, very fast, compared to SVN at least. If this doesn't sound like a big deal, wait till you've been using Git for a couple of weeks - you'll be amazed at how much time you spent waiting for subversion.
• Git keeps all its files in a single hidden (.git) directory at the top of your source tree, so you don't have .svn folders hiding all over your source
• Git is used to manage the Linux Kernel, and Ruby on Rails, so people a great deal smarter than me think it's the bee's knees too!
• Git makes branching really easy

Hold on: I don't need Git because I never do branching!

Chances are, you never do branching because your source control system makes it hard. Branches in git are super-easy and super-quick to do:

Show the list of branches

$ git branch

Make a new branch and switch to it

$ git branch mybranch
$ git checkout mybranch

>>make changes<<

Commit changes

$ git commit -a

Switch back to main branch

$ git checkout master

Merge mybranch into main

$ git merge mybranch

There's no fiddling about with branch paths, and git won't waste time and disk space duplicating all the stuff in trunk so you won't have to clean it up later. The fundamental difference between Git and SVN in this regard is that Git 'knows' about branches, while branches in SVN are simply a pattern you use in laying out your repository structure. With SVN as each branch is simply an 'svn copy' of an existing directory.⁽ⁱ⁾ Git shields you from the details, so there's no need to bother with trunk/tags/branches folders ever again.

The fact that Git makes branching easy is a lot more important than it might sound. You'll find you start to make temporary branches as part of your day to day work - experiments to try things out. This helps remove one of the mental barriers to getting things done - what if I try something and it doesn't work - how much time will I waste trying to revert?

GitHub - like Trac, without the pain

Trac is a neat web frontend to SVN that allows you to browse your source history visually, and keep notes about your project in a wiki. It's also a real PITA to install in my experience...

GitHub is a software as service tool that's quite similar to Trac. They host (and backup⁽ⁱⁱ⁾) your Git repositories for you, so there's minimal setup required. It's beautifully designed and very easy to use. It's also pretty inexpensive ($7 month for the cheapest version with private repositories), or free for open source projects.

Surely Git must be hard to install?

I installed git with MacPorts:

# sudo port selfupdate
# sudo port install git-core +svn

On Linux, I was able to build from source without any headaches, so if you aren't on Mac OS, you should still find Git trivial to install.

Super-helpful links

Git is certainly a little confusing when you arrive as I did with your head full of how things are supposed to work in another source control system. I found these pages particularly helpful in getting to grips with Git, I hope you will too:

• The official intro:
  http://www.kernel.org/pub/software/scm/git/docs/tutorial.html
• Migrating your repository from SVN:
  http://www.simplisticcomplexity.com/2008/03/05/cleanly-migrate-your-subversion-repository-to-a-git-repository/
  Works beautifully!
• Cheat Sheet:
  http://zrusin.blogspot.com/2007/09/git-cheat-sheet.html

1. Within a repository, SVN will store only parts that change for a branch, so your respository won't end up taking up lots of space if you have lots of branches. However, if you checkout a whole repository, you will get 1 file for every file in the repository.
2. Though of course, every local checkout is a full copy of the whole repository. This is worth noting because you won't lose anything if GitHub go out of business, and I wonder how many people actually backup their SVN repositories if they host with a third party provider?

Posted by Ben @ 11:05 AM