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
Previously, we attempted to automatically determine whether the editor’s
height should be based on the editor’s content or the height of its
container. Unfortunately, DOM APIs are insufficient to make this
determination in a complete way, leading to unpredictable behavior.
This PR deprecates the automatic determination of this behavior. By
default, editors base their height on their content. If an editor has
an explicit height assigned via its style or is positioned absolute with
an explicit top and bottom, we disable the content-based autoHeight and
log a deprecation warning telling the user to assign autoHeight
explicitly.
This paves the way to add an autoWidth setting, which will default to
false.
This commit moves all the remaining concerns not related to decorations
out of `DisplayBuffer` and into `TextEditor`. This means the
`DisplayBuffer` is now free to be renamed to `DecorationManager`.
