Just like the cursor clears its goal column when it is moved in any
way other than vertically, the selection clears its goal range (the
range it will attempt to use when adding a selection below) when it
is changed in any way.
Just like the cursor tries to stay in its "goal column" when moving
vertically, here we try to keep the same selection even when adding
across shorter lines.
Previously, logic associated with swapping grammars was a bit
scattered. Now grammar reloading / assignment methods delegate to
LanguageMode directly, and it emits a 'grammar-changed' event when
the grammar changes. Now EditSession and TokenizedBuffer listen for
this event and perform necessary actions for grammar change.
This is more consistent with other range-oriented methods on
EditSession. At this layer, we need to be explicit about what kind
of range we are talking about.
This makes it easy to only assign variables for the information you
need in the iterator. Before, we always forced you to take a match and
a range as the first two arguments even if you weren't using them.
Since buffers are now serialized directly, previous versions of the
EditSession state which used the buffer's path as the `buffer` key
are no longer valid.
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.
