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
Writing so much data to IndexedDB is blocking the main thread for
perceptible amounts of time. A patch-based representation of the
modified state could allows us to pay only for what has changed, but is
too complex to justify implementing right now to support full crash
recovery for large files.
Signed-off-by: Max Brunsfeld <maxbrunsfeld@github.com>
Calling `workspace.open` in an opener doesn't work properly with options
like `split: left` because it causes the opened item to be added to the
workspace as a side-effect. Since workspace openers are intended to be
used during the process of calling `workspace.open`, we need to use
`openTextFile`, which just creates an editor but does not attach it to
the workspace.
Previously, we were only calling the debounced resume callback when the
cursor was already blinking, but this meant we didn't renew the debounce
window. This in turn meant we attempted to start blinking the cursor
again every 100ms regardless of cursor interactions, which was consuming
an extra frame and causing cursor movement to not feel smooth.
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
