Refactor OakHTMLOutputView
Open new window for HTML output links with target="_blank"

Since switching to ARC we need to ensure the NSWindow is “over-retained” as we rely on “setReleasedWhenClosed:YES”.

Also add ability to close such windows from JavaScript.
Add debug output to WebView delegate
Find in folder window’s title could switch to “Untitled”

This is because we are using an NSDocument to perform the folder searching (as that’s a decoupled way to have the window indicate “unsaved changes” and present a warning sheet).

The downside is that by using an NSDocument we get some undesired implicit behavior, like automatically changing the window title or trying to re-open the “document” after relaunch.
Indicate that find window is not restorable

Since we are using it with an NSDocument, it defaults to use NSDocumentController as restoration class, which gives a warning during launch, if the find window was open during termination, and the conditions are so that the system wants to restore windows from last session.

Also indicate that we do not want to save drafts, unsure if this has any effect.
Make the preferences window restorable

This is not overly useful but the code serves as copy/paste for future endeavors into restoring non-document windows.

The feature requires that “Close windows when quitting an application” is disabled in System Preferences → General (I think that option is enabled by default, at least on 10.9).
Add comment to explain workaround for presumed WebKit bug

Since the code was written before open sourcing TextMate, the explanation was only to be found in a private commit log.
Use (custom) block based API for showing sheet
Refactor HTMLOutputWindow: Use properties and argument free init
Do not re-use busy HTML output views/windows

Additionally, we only re-use a window when the command is the same as what was last associated with the window. So doing a documentation lookup and then building the project will not re-use the (non-busy) documentation window for the build progress.

Closes #733
Show alert sheet when closing window with a running command

This only applies to commands being run embedded in the document window.
Update API to reflect that setting command runner can’t fail
Do “refresh” for actions which are no-op due to current state

For example when caret is at the beginning of the document, using “move left” would be a no-op and would cause “refresh” to be skipped, which meant if the caret was outside the visible area, no scroll would happen (to make it visible).
Add bundle item setting for how to re-use output windows

This presently does not have any effect.
Refactor: Collecting output windows moved to own method
Handle output window re-use options for commands
Don’t let HTML output window itself keep track of open windows
Inserting “after input” is always lower/right corner for columns

For example selecting a column of numbers and selecting “Add Numbers in Selection” will now always insert the result at a logical position rather than on the defined end points of the selection.
Announce current OakChooser item to accessibility

This solves accessibility of situation of a user browsing results in
OakChooser (currently File Chooser and Symbol Chooser). Typically
the user is in search field and after typing the search string
wants to use arrow down and up to browse results.

The problem this presented to accessibility was that VoiceOver reads
only changes of selection in the current VoiceOver item. As the user
is on the search field but the selection changes in the results table
below, VoiceOver did not read the various search results when pressing
arrow up/down.

Alternative was to leave the search field, move to the results table,
interact with it and then navigate it with VoiceOver. This is however
not the desired user experience comparable to that of sighted users,
as the VoiceOver user still has to do quite a few steps after entering
the search string to browse the results, not to speak about the situation
when the user would like to change the search string - he/she would need
to leave the table and get back to the search field.

This solves the problem by making the search field (or more generally
any user interface element that triggers change of selection in the
results table, which should be the element the VoiceOver cursor is on)
announce to accessibility the contents of the selected row in search
results table.

See this thread on accessibility-dev mailing list where the options for
implementing such a user interface in an accessible way are discussed:

http://lists.apple.com/archives/accessibility-dev/2013/Dec/msg00000.html
and
http://lists.apple.com/archives/accessibility-dev/2014/Feb/msg00016.html

If the user did not move selection (it is on the first line) and they
want to hear it, they should use arrow up to hear it. Then they can
use arrow down to move through results.
Workaround for accessibility of OakChooser's search field

Currently for VoiceOver user when the text cursor is at the end of the search
field (which is 99% of the time) and the user wants to navigate the results
in the table view using arrow down, then after each arrow down, VoiceOver first
plays a "end-of-text" sound, then announces whole contents of the search field,
and only then announces the newly selected search result. (The same happens
when text cursor is at the beginning of the search field and user presses
arrow up.)

This is probably a bug in the way AppKit handles text field accessibility - see
http://lists.apple.com/archives/accessibility-dev/2014/Feb/msg00019.html

I also reported this as <rdar://problem/16271507>

I hereby present a hacky workaround for this - a subclass of NSSearchField
that tricks accessibility into thinking there is one extra space before and
after the text in the search field. Therefore VoiceOver will not think the user
is at the end of text when they actually are, and therefore will not play the
"end-of-text" sound and announce whole contents of the search field before
getting to the information user wants (the newly selected search result).

While this is a bit hacky, along with the previous commit it allows VoiceOver
to have the same instant great experience as a sighted user when filtering
and browsing results in OakChooser. So I think it's worth the hackiness until
there is a better alternative.

There is only last issue, as currently VoiceOver is very chatty when the
OakChooser window appears: first says "Go to file", if user interrupts it with
an action (i.e. moving VO cursor or typing a character), then VoiceOver starts
telling the whole title of the window, and only after user interrupts it again
does VoiceOver say or announce only the user actions (including search results
table selection change).

So the simpliest if the user wants to start navigating the table items
immediately after showing the OakChooser's window (i.e. without entering
a search term) is to, after showing the OakChooser (e.g. with ⌘T or ⇧⌘T),
quickly type any letter and immediately delete it with backspace and then
use arrow down/up.