Commit 8e77c05c fixed scrolling *up* when clicking the buffer while
scrolled down. But it was still scrolling to the far left when typing /
clicking on a really long line. This commit solves both issues by
always positioning the hidden input to the same location as the cursor,
so it doesn't tell webkit to scroll away from the current focus when it
is focused or the user types.
If a region of the selection needs to span the full line, I assign
right: 0 instead of a width so that it always stretches across the
entire editor, even after a resize.
This is a temporary fix, it just stores compiled scripts in memory. It
doesn't speed up the app start since the scripts need to be compiled
once. Here are some numbers.
#file load
pre: 1.5 seconds
post: 0.25 seconds
#spec load
pre: 5.4 seconds
post: 0.36 seconds
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.
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 ü
