Previously we were storing a {type: ‘selection’} property, probably
leftover from the “pre-marker-layer” world. We were also storing
`Selection`’s `goalScreenRange` on the marker, which is now just an
instance variable.
Based on a cursory search, there’s only one package using that API. Even though
we could submit a PR, we’re introducing deprecations to ensure we're not missing
any other package.
Previously, we were copying the selections marker layer into the current
editor’s display layer. This would work fine until the spatial mapping
drifted in the copied editor, and would then have counterintuitive
results.
Even though it was a private field, we used it in some of our packages
and it is widespread enough to warrant some effort to smooth the
transition.
Also, we added a couple methods that were formerly implemented on
DisplayBuffer to TextEditor itself because they were used in packages.
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`.
This archive is created on an Ubuntu 64 bits machine, publish it if present
in the assets. The version contains the channel name, so don't append
channel name to it.
This archive in tar.gz format contains the whole Atom binary and resources
to enable multiple channels and versions to be installed on the same
distribution.
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.
