This regression was introduced with the removal of the shadow DOM from
`<atom-text-editor>` elements. Previously we were relying on Chrome
always reporting `<atom-text-editor>` as the mousewheel `event.target`.
As a result, removing the shadow boundary caused the mousewheel event to
be potentially dispatched from anywhere inside the editor element,
making our previous logic for handling ctrl-mousewheel invalid. This
commit fixes it by recognizing mousewheel events that are dispatched
from within an editor.
We are working on a feature that changes the content of the editor when you mouse over some things and it makes the UI jump when going from 1 line to > 10. This makes the UI feel really bad.
I've looked at Sublime and the 1-9 state is the same as 1-99, only when you reach 100 lines then it jumps. I think that it is a better behavior as you want to minimize jumps as much as possible and it is extremely likely that you are going to hit the 9-10 lines threshold.
While this is being reviewed and until the new version shipped, we are going to monkeypatch Atom in order to get this feature.
```js
var presenter = atom.textEditors.editors.entries().next().value[0].presenter.__proto__;
var old_updateLineNumberGutterState = presenter.updateLineNumberGutterState;
presenter.updateLineNumberGutterState = function() {
var res = old_updateLineNumberGutterState.apply(this, arguments);
this.lineNumberGutter.maxLineNumberDigits = Math.max(2, this.lineNumberGutter.maxLineNumberDigits);
return res;
};
```
Released under CC0
Right now, it is not possible to hide a tooltip programatically. This is useful when we know better than the tooltip implementation that we did an action that should hide it.
After discussing with @lee-dohm, he suggested the findTooltips API that mimicks the KeyMapManager API.
Released under CC0
@damieng This is unlike the other tests in this file in that none of the
assertions pass. Maybe you could take a look at some point to enable at
least some coverage on Windows for this?
