Please note that we will preserve the batching behavior but we will now simply
use booleans to track functions that ought to be called during `@getState`.
This (hopefully) expresses intent better, drawing a clear line between batched
functions and "realtime" ones.
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.
