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.
We might have two edit sessions pointing to the same buffer, for
example if we have a split pane… So when we deserialize a buffer, we
always need to check that we don't already have an instance of that
buffer on the project. If we do, then we've already deserialized it
once so we don't need to worry about the saved text.
We still have a problem when deserializing previously unsaved buffers,
because we can't use the path to identify them.
This was causing a spec to fail since the line text now had a leading
space for all results since the separator before the line text is now
': ' instead of just ':'.
Previously the line ending length was hard-coded to one which
would cause TextBuffer.scanInRange() to return incorrect results
since one character per line wasn't being accounted for.
Closes#428
This fixes the UI thread lockup when there is a gigantic line in a
file (like minified js). I took a stab at making line tokeninization
async on the atom/async-single-line-tokenization branch, but it was
still too slow.
Closes#150
