Inside of Nuclide, we have multiple places where we have multiple icons close together that have a tooltip: the left toolbar, the bottom status bar, the debugger icons...
The current behavior is very frustrating as you've got to wait for the delay on every single one of them. But, we have a clear signal that the user wants a tooltip when s/he waits the time to see it and it's likely that moving the mouse over the next item quickly means that s/he wants to see it as well.
This pull request introduces the concept of follow through: if you have seen a tooltip, you're going to instantly see tooltip on the next element you mouse over within a short timer (300ms right now).
Test Plan:
Video before:
Video after:
Released under CC0
Simply replace ::shadow with .editor to preserve the specificity of the
transformed rule. This isn't beautiful, but it's the only way to
guarantee that the styling transition is smooth enough to justify not
bumping the major.
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.
