Although we have a couple of components which still access it, we
agreed it would have been just better to avoid relying on
`TextEditorPresenter` where possible and use it purposefully in other
places (e.g. `LinesComponent` which needs it to store text
measurements).
/cc: @jssln
This reverts commit f2bab35f57c05d5a0bb21e9fb02117f802ff278b. It didn't actually
improve performance, nor memory usage, therefore I decided to avoid changing it
for the time being.
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.
