Previously, for null grammar and large file mode, we were short
circuiting the tokenization of the next chunk or the invalidation of a
row. However, that is unnecessary because there is no additional chunk
to process with null grammar or in large file mode.
Previously we were treating the local `NullGrammar` differently from
`atom.grammars.nullGrammar`. These two grammars are conceptually the
same, as the former was created to support editors creation without a
grammar registry.
To keep backwards-compatibility, we also build placeholder lines
on-demand when calling `TokenizedBuffer.prototype.tokenizedLineForRow`.
This ensure that packages relying on the internals of `TokenizedBuffer`
to retrieve syntactic boundaries won't break when the null grammar is
used or large file mode is on.
No packages use it currently, and it's really complex to support so
we should kill it while we have the chance. When it comes time to
rewrite the tooltip code or add features, not worrying about selectors
will make it easier.
I want to eliminate the selector option and open the door to diverging from
the lesser used parts of that API in the future by only documenting a subset.
When, after flashing a decoration, the decorated range moved, Atom was
showing an additional flash, even if the previous one had already been
consumed. This bug originated in `HighlightsComponent`, where we
maintained state about a certain highlight's flash count. The problem
with this approach, however, is that highlight objects in the component
are very volatile, and we could even have more than one for a single
decoration (i.e. when such decoration spans multiple tiles).
To fix this, we'll now maintain some additional state in
`TextEditorPresenter`, which will set a `needsFlash` attribute on the
highlight state objects, thereby preventing `HighlightsComponent` from
showing the flash animation more than once when the decorated range
changes.
