If the Git bundle is checked out to Application Support then TM_BUNDLE_SUPPORT will contain a space.
Not escaping spaces in file URLs seems to have worked in the past (with WebKit) but escaping them is the right thing to do, and it does not work in macOS 10.12.

Because `Scm::Git#short_rev` (as well as `ApplicationHelper#short_rev`) always produce 8 digit refs, we need the output of `git blame` to use the same length, otherwise clicking on a (short) revision in the blame window fails to select the appropriate revision from the select at the top. Fixes#46
Note that we have to specify `abbrev=7` to actually get 8 digit revisions (see man page excerpt below).
Long explanation: In some cases / repositories, `git blame` seems to use longer refs by default. I’m not sure why, as the man page (git 2.13.2) explicitly states that the default is 8 (7+1) digits:
```
--abbrev=<n>
Instead of using the default 7+1 hexadecimal digits as the abbreviated object name, use <n>+1 digits. Note that 1
column is used for a caret to mark the boundary commit.
```
I suspect that this description is incorrect and that the default value is instead taken from `core.abbrev`. The man page for git-config says about this setting:
```
If unspecified or set to "auto", an appropriate value is computed based on the approximate number of packed objects in your repository, which hopefully is enough for abbreviated object names to stay unique for some time.
```

From ‘git help commit’ the recommendation is simply to make it ‘less than 50 characters’ which we still use as the limit for marking it as deprecated.
I think GitHub used to truncate at 65 characters but currently they truncate at 72 which is a commonly used value for hard wrapping, so it makes sense for us to use this as well.

This changes the previously zero-width whitespace character used to control the menu item selected when typing a C with the menu open. The previous workaround became very visible on Yosemite, a hair space isn't absolutely invisible but almost so.

Previously, we would wait on TextMate to close before cleaning up the temporary file; however, we may want to avoid this since in the future TextMate may be able kill the process (before closing) and therefore leave behind the file. Also, let's use `TextMate.detach` instead of just `fork` to ensure we detach.
This resolves an issue reported on the TextMate mailing list (http://lists.macromates.com/textmate/2014-September/037756.html).

Since we auto populate the textview with the last commit message, we eliminate the need to include the "-- update commit message --" item. This item was used to inform the bundle if the user intended to update the commit message (check) or just use the previous message (uncheck).
So now when amending a commit, the commit window will show the last commit message in the textview and a list of potential files only if necessary (i.e., the table view will be empty in situations where the user wanted just to edit the commit message). This behavior is more consistent with the way amending a commit works when running "git commit --amend" from the command line.
Also, we now check to see if there is nothing to amend (i.e., it is the initial commit).

This is useful when we would like to discard and not show any potential (html) output that may have been generated up to that point (e.g., canceling an action).
Note that all output will be suppressed until "unsupress_output" is called. I.e., calling "flush" will not show the current output buffer.

By default, running “git diff” shows local changes that have not yet been staged, so if the user had already added (a version of) the file to the staging area, the diff button would only show changes done since that, which is misleading (as we commit to HEAD not the staging area).
A minor issue exists for newly initialized repositories without a HEAD to diff against, here the diff command actually fails, but we ignore the return code and show a blank diff.

When the commit window was a separate program and required siginificant time to launch, it made since to initially send some kind of information to the users via the output window. However, now that the commit window runs as part of the Textmate, it may be a better user experience to delay output until after the commit window is closed.