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.
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.
Previously this logic lived in atom-reporter, but it seems more
reasonable to throw errors in spec-helper instead, so that the test
suite fails in CI as well whenever a deprecated method or stylesheet is
used.
This will allow packages to observe the state without having to worry
about subscribing to the events after they've already fired.
Originally suggested in #10839
