The editor has a tabindex of -1 so it can receive focus. This makes it
behave like a focusable element such as a textarea. But in reality,
when the editor receives focus, it just focuses the hidden input that
it watches for textInput events. So when you click, focus is stolen
away from the hidden input and goes to the editor. But then the editor
sends focus back to the hidden input. Because the input was at the top
of the screen, WebKit would scroll up to bring it on screen when
focused. So now I just bring the hidden input on screen (by positioning
it even with scrollTop) before focusing it. That prevents the WebKit
from scrolling.
Before, we were traversing through lines to remove in ascending order
and then calling remove(n) for each. But when we removed line 10, line
11 became the *new* line 10. So when we removed line 11 we ended up
skipping the old line 11. I solved this by traversing in reverse when
we need to delete lines.
Giving the hidden text area a fixed position was confusing webkit and
making scroll behavior really odd. Using position: absolute and setting
the z-index so it's behind the editor seems to make scrolling behave
more normally.
Cursor emits a move event that the selection listens for. The selection
updates its appearance when this happens, but does not tell the cursor
to update. The cursor takes care of itself.
Introduce Point and Range objects. Selection.selectRight places an
anchor object before moving right if no anchor yet exists. Still no
visual treatment.
Change takes a range and a string and replaces the range with the
string, then emits a change event with the range of text that was
changed, the range of text occupied by the new string, and the string
itself. This can be used to implement backspace, insert, as well as
various cut and paste manipulations.
I couldn't find a way to test this really. It's some interaction
between focusout and focus events. When the hidden input has focus and
then we call focus on the editor, the handling of the focusout event
away from input was trigerring a call to focus on the editor, which
didn't seem to trigger the handler that shifted it back to the hidden
input. Here I only focus the editor if something *outside* of the
editor was de-focused. So focusing the editor when the input is focused
is ignored, and focus is gracefully returned back to the input.
Now we'll be able to listen for textInput events, which give us better
information about what character is being entered in the presence of
multi-keystroke compositions like alt-u,u for ü
