Use selection polling to update editor.range #431
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bantic
force-pushed
the
use-selection-polling
branch
4 times, most recently
from
318ebe7
to
20e6077
Compare
bantic
changed the title
bantic
force-pushed
the
use-selection-polling
branch
5 times, most recently
from
9dbe972
to
4faf0ef
Compare
SelectionChangeObserver maintains a singleton instance that polls the window using `requestAnimationFrame` for changes to the selection. Editors' EventManager instances use a SelectionManager to listen for `selectionchanged` events, and update the editor's `range` if necessary. Removes code that would use some keyup events (when `key.isMovement()`) and `mouseup` events to detect when the range could have changed. The range-detection code was previously spread out over `EventManager`, `Editor`, `Cursor` and `EditState`. This code change consolidates most of the responsibility for knowing/reading/updating the editor's `range` o its `EditState` instance. The editor now delegates `range` to the edit state instance, and the edit state instance is responsible for knowing when the editor's inputMode or range has changed. Some tests assumed selection changes would be picked up synchronously; for those tests a `Helpers.wait` helper is added that schedules a callback with `requestAnimationFrame`. Also: * use "hidepassed" for sauce tests to improve test failure debugging * remove unused `editor.selectSections` * remove now-unnecessary key commands for meta+arrow on mac
bantic
force-pushed
the
use-selection-polling
branch
from
9957892
to
2ff0590
Compare
|
released in v0.10.0 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
SelectionChangeObserver maintains a singleton instance that polls the
window using
requestAnimationFramefor changes to the selection.Editors' EventManager instances use a SelectionManager to listen for
selectionchangedevents, and update the editor'srangeif necessary.Removes code that would use some keyup events (when
key.isMovement())and
mouseupevents to detect when the range could have changed.The range-detection code was previously spread out over
EventManager,Editor,CursorandEditState. This code change consolidates mostof the responsibility for knowing/reading/updating the editor's
rangeo its
EditStateinstance. The editor now delegatesrangeto the editstate instance, and the edit state instance is responsible for knowing
when the editor's inputMode or range has changed.
Some tests assumed selection changes would be picked up synchronously;
for those tests a
Helpers.waithelper is added that schedules acallback with
requestAnimationFrame.Also:
fixes #408
fixes #383
related #369
related #302