This is actually more efficient than the CSS animation we were doing previously, because it doesn't force the cursor to be sampled at 60 FPS for something that changes around twice a second.
This will be used by the status bar and other expensive code that needs to respond to the buffer changing, but that we don't want running on every single keystroke when the user is typing quickly.
This is the fastest way I've found to get the nextTick behavior, which allows us to aggregate multiple requests for display update (from selection changes, cursor movement, line changes) etc into a single call at the end of processing an event.
Then in the editor, we update and autoscroll only the views that need it. Autoscrolling is suppressed when resetting the display so that we honor the scroll positions of the active EditSession.
We no longer call `updateDisplay` immediately when the cursor is attached. Instead, we always attach and remove cursor views from `Editor#updateDisplay`, so we will decide whether to autoscroll at that level.
The goal is that no model operation will ever modify the DOM directly. We will always request a display update, which will happen on the next animation frame.
$base works as $self worked previously. $self will need to be fixed. If inside
a embedded grammar $self refers to the embedded grammar while $base refers to the
overall grammar.
The renderedLines div can now only contain actual lines, nothing else. Thes divs are designed to match the lines div in dimensions and make it easy to put things in front of or behind the text.
Previously, we treated all grammar repositories as rules, but some
grammars have repositories that are a single pattern. If it is a single
pattern, transform it into a rule with one pattern.
Fix how repositories work in TextMate grammars
Previously, we treated all grammar repositories as rules, but some grammars have repositories that are a single pattern. If it is a single pattern, transform it into a rule with one pattern.
If the input element is a child of the scroll view, then focusing it can end up changing the scroll position of the view behind our backs. We *only* want to scroll the view via our interface on editor, because a bunch of of special code needs to run when we scroll. We can't just have the browser scrolling that view around willy-nilly.
This requires updating the padding of the rendered lines and then adjusting the vertical scrollbar content height before updating any of the rendered lines. This fixes (hopefully all of) the rendering issues when adjusting the font size.
