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.
getBoundingClientRect returns garbage values if the range has zero
width, which it does in the case of a fold placeholder or any other
zero-width character.
Sometimes getClientRects() returns an empty list, so we fall back to the
bounding rect in these cases.
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.
Previously, when a Pane would replace a pending item with
another pending item, it would emit
`onItemDidTerminatePendingState` for that item, which was
not true because the item was actually being destroyed.
Sometimes, the error event gets emitted before the renderer process has
the chance to subscribe. Therefore, we expose an
`autoUpdateManager.getErrorMessage()` in the browser process, so that we
don’t lose that information.
