Previously if a selection was added and then merged
away the selection-added event would still fire even
though the selection was already destroyed.
Now the existing selection that intersects with the
range is returned when the merge destroys the new selection.
Closes#374
This event is now listened for from the editor and
re-emitted under the editor namespace. This removes
the need to monitor the syntax's grammars-loaded event
from both places and also mirrors the behavior of the
path-changed event.
The problem I've been struggling with is that we need to potentially
assign tabs both to EditSessions and also to other views added by
extensions, like a markdown preview view. EditSessions are however not
actually views… instead they plug into editors. The solution is to
have the pane ask a model object what view should be used to render
it. When asked to show a non-view item, the pane constructs and
appends a view for that item or recycles an appropriate view that it
has already appended.
Since this is the more external method, having a shorter name
is more convenient. The former `buildEditSession` method took a
Buffer, and is now called `buildEditSessionForBuffer`.
This saves the state of the rendered lines, the display buffer, the
tokenized buffer, and the buffer to a file. If a problem arises with
rendering, hopefully we can use it to diagnose in which layer things
went awry.
In additional, rename `registerViewClass(es)` to `registerDeserializer(s)`.
This moves us to a situation where any kind of object may want to be
deserialized, not just views.
- EditSessions destroy their Selections when they are destroyed
- Editors destroy their EditSessions when they are destroyed
- Editors unsubscribe from the document and window when they are
removed from the DOM.
- When an EditSession is destroyed via any code path, the Editor with
that EditSession removes it.
- Selections no longer trigger 'destroyed' events if their parent
EditSession has already been destroyed.
These are all really intertwined, so I'm doing them as one commit
since that was the only way to keep the specs green.
A "marker" is basically like a persistent selection/cursor composite,
having a head and a tail. The "head" is like the cursor in a selection,
and the "tail" is like the part of the selection that doesn't move. My
goal is for markers to be the only construct used to track regions
in the buffer. I want to replace anchors with them.
