...because content could get reflowed and previous measurements might
become inaccurate. Typically, this could occur when measuring while the
editor is hidden: in that case, the yardstick would always report `0px`
and save that position into the cache. Then, when the editor becomes
visible again, the wrong `0px` value would be returned, thus causing
cursors etc. to be displayed incorrectly.
This was being shadowed by a bug in our measurements cache, but after
fixing it in #12730 it started becoming evident.
When we need to check for unassigned in the deprecated code path, we
can just read the instance variable directly to avoid getting the
deafult.
Signed-off-by: Antonio Scandurra <as-cii@github.com>
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.
There's a distinction to make between rendered and visible rows, and we
were using the former as if it was the latter. In particular, if a tile
is visible, all its rows get rendered on screen, even though they might
not necessarily be visible by the user.
Also, remove specs testing RTL behavior. They don’t work as of today,
and I think we need a better approach to handle them, that doesn’t
solely rely on the DOM, but actually takes into account that e.g. (0, 0)
is the rightmost character on a right-to-left string.
Atom currently sets the `value` of the input on every `textInput` event, in an effort to appropriately handle changes made via the OSX diacritic menu (for accents, umlauts, etc).
The drawback of this is approach is that updating the value of the input will trigger layout and a subsequent layer tree update.
To resolve this, here is my proposal:
- Track a flag for `keypress` events. When the diacritic menu is used, there are two `textInput` events, with no `keypress` in between. Therefore, when no `keypress` has occurred just prior to a `textInput`, the editor model can select the previous character to be replaced by the new accented character.
- Track a flag for `compositionstart` events. When a user is in IME mode, the diacritic menu cannot be used, so the editor can skip the backward selection.
Test Plan:
Tested in a plaintext file.
- Type Latin characters, verify proper character insertion.
- Press and hold <kbd>a</kbd>. Diacritic menu appears. Select an option using the keyboard or mouse. Verify that the `a` is replaced by an accented `a`, with no extra characters.
- Type test strings in Katakana, 2-Set Korean, Telex (Vietnamese), Simplified Pinyin. Verify that characters are inserted correctly while composing, and after committing strings.
