This allows folding, auto-indent, etc to work in a file in which *both* tabs and spaces are used to indent. Not that this is a good idea, but at least we handle it gracefully.
Now, we maintain md5 signatures for the on-disk and in-memory contents of the buffer. Whenever either contents change, we recompute the signature and store it on the buffer. We can tell if the buffer is modified by comparing these signatures. When the disk contents change, we compare the memory and disk signatures *before* recomputing the disk signature to determine whether to update the buffer or mark it as a conflict.
We build a native `OnigScanner` object at the `Rule` level which tries to match every regex for the entire rule, rather than using an individual regex for each pattern from the JS side.
This metadata will be used to record the indentation level of the first line when copying multiple lines of text to the pasteboard. The pasteboard takes the md5 of the pasted content when writing, then when reading it associates the last written metadata only when the signature matches the previously written value.
When an open bracket is inserted, an anchorRange is created. When a closing bracket is inserted, and its position matches the end of one of the anchorRanges, the closing bracket is not inserted and the cursor moves right.
When we actually want to attach the root view in window-bootstrap.coffee, we call `window.attachRootView(path)` instead of calling `window.startup(path)`. Having `startup` called automatically means we can be sure any code we add there runs in every environment (including benchmark and specs). This is where we do things like setup the global keymap, parse text mate bundles and themes, and establish the window close handler. Any globals other than the root view that we want to be available in all environments should be established here. Right now that's just the keymap, but soon I want to add a global pasteboard.
If we're pasting multiple lines starting inside an already existing line, we never want to auto indent. We should just take its existing indentation level. Also, we strip the leading whitespace off the first line we're inserting, assuming it's already being represented by the indentation of the line we're onto which we're appending it.
Also, when some lines are *less* indented than the first line, it might not be possible to outdent them as far as they originally were relative to the first line, so we do as much as possible.
For now, we auto-generate the documentation string by humanizing the event name. In the future, we may provide the option to provide more documentation, such as info about any arguments to the event, extended documentation, etc.
Also, auto-generate human readable event name in editor. This is a good example of how we could do this automatically for some kind of `onCommand`, `command`, `onInteractiveEvent` method that combines the event name, documentation string, and handler in one shot.
