This is better behavior for alt-del/backspace operations, is less
"greedy" and doesn't eat up excess characters.
Also set default key mappings to these, feel free to trash my changes
to keymaps/darwin.cson. Though I do feel this should be default
behavior, personally.
With the presenter we started clipping screen positions prior to
translating them to pixel positions. This interacts with the current
clipping behavior on folded lines (which should change) where the cursor
is always clipped to 0. So when the longest line was also folded we
were miscalculating the width. 🙈!
The removal of clipping also causes us to calculate the width based on
the trailing whitespace of soft-wrapped lines, which I actually think
is an improvement but it is slightly different.
In adding custom gutter APIs, I suggested to @jssln that we associate
the gutter model objects with DOM nodes in the view registry to make
it easy for package authors to get at the view layer for a particular
gutter. She also applied this treatment to the line numbers gutter,
which makes sense.
However, using the view registry opened up an unexpected wrinkle…
When you detach an editor, we need to tear down all the associated view
logic because at that point, we don’t know whether the element is about
to be reattached or whether it’s going to get garbage collected. In the
case where we reattach, we end up constructing a new TextEditorComponent
for the element. When this happens, the gutter component requests a DOM
node for the gutter from the view registry. Except in this case the
DOM element isn’t empty because it was already used by a different
component for the same element before it was detached. The fix is simply
to always clear out the line numbers to ensure we start in a clean
state.
@jssln: You should apply this same fix to custom gutters or we’ll see
the same issues.
A common pattern is to put something on the DOM, measure it, then update
the DOM again based on that measurement. This change ensures that any
updates requested as a result of reading from the DOM get scheduled for
the end of the current frame. If you want to read *again* after these
follow-on updates, you will need to wait for the next frame. But at
least this way we ensure instant feedback with minimal thrashing
(1 reflow) when we have no choice but to read the DOM before updating.
/cc @benogle
