Previously if null was returned for the end of word position then
it was interpreted as 0,0 which would select the entire contents
before the current word instead of the current word.
Any events emitted from DOM nodes should be prefixed with an identifier
for the node that emits them. This eliminates the possibility of ambiguity
when the events bubble up the DOM away from their emitter.
For this to work, I needed to make the updating of anchors transactional. Now, all anchors are updated and *then* they emit their events. That way when the cursor moves based on the user typing, the tab stop they're in has a chance to expand before we handle the move event. This prevents spurious cancellation of the snippet when typing on a tab stop.
If the input element is a child of the scroll view, then focusing it can end up changing the scroll position of the view behind our backs. We *only* want to scroll the view via our interface on editor, because a bunch of of special code needs to run when we scroll. We can't just have the browser scrolling that view around willy-nilly.
This does *not* include newlines. Doing this makes it possible to double-click regions of whitespace to select them just as you can select a word. It also makes word movement bindings behave similarly to TextMate.
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.
Add the 'strong' option to anchors. If anchors are 'strong' instead of being destroyed by encompassing changes they move to the beginning of the change range.
Cursors and selections no longer need to handle buffer/display-buffer changes directly. They register anchors with the EditSession, and subscribe to changes in their position instead. This opens up the anchor facility for use by extensions that want to track the screen position of a point in the buffer as the buffer and display buffer change.
The old cursor view still does most of the work, but to add a new cursor view we now must add a cursor model to the edit session at the correct position. The editor watches the 'add-cursor' event on edit session and add a corresponding CursorView to the CompositeCursor whenever a model is added. Next step: have the cursor view observe the cursor model and shadow its changes in position.
