If an exception is thrown while running an operation, we clear the
undo manager and re-throw it. But if we were in a transaction, we will
commit it in a `finally` block. If the transaction is set to null,
committing the transaction will then throw an exception which hides
the original exception… we don't want that. Now clear just empties the
current transaction out.
We no longer need to restore selection ranges before and after
transactions now because selections are based on markers so they go
along for the ride for free. This allows us to delegate directly to
Buffer.transact from EditSession.
Creating a fold in one pane now has no effect on an edit session
for the same buffer in another pane. Before they were polluting each
other by sharing the same fold markers.
When creating a display buffer for buffers that already have fold
markers, which we'll eventually do on refresh, basing folds on
full-blown display buffer markers is a problem because we end up
creating display buffer markers during construction of the line map.
When we create a display buffer marker it memoizes its screen positions,
but since the line map isn't built yet we have nothing to translate
against. Basically, since the line map depends on folds, folds can't
depend on the line map. Luckily, they don't need to. Buffer markers
work just fine.
For a while, the goal has been to prevent marker update events from
firing until after the buffer change event. But at the same time, we
want all the markers to be updated when the buffer change fires. This
commit irons out some issues for markers that are invalidated or
revalidated by the change, making their behavior consistent with the
rest of marker updates.
Because we don't currently allow for direct manipulation of fold
marker ranges, if a fold's marker changes it will be because of a
buffer change. This buffer change will bubble to the display buffer
anyway, where the screen line update will account for the change to
the fold's marker range.
Still a couple of specs failing on this for changes that straddle the
start / end of a fold. We need a new marker invalidation strategy for
these cases.
Instead of marker-added and marker-removed events which are emitted
when markers are created/invalidated/revalidated/destroyed, we now
just have marker-created events that are triggered *only* when markers
are created for the first time. The marker itself emits a 'destroyed'
event when it is destroyed. The marker already notifies observers when
its validation status changes, so that's covered.
The previous API revolved around methods on TextBuffer for querying
and manipulating markers based on their id. Now marker creation
methods return marker objects. These are still retrievable by id so
they can be dealt with across serialization boundaries in the future,
but you deal with them directly as objects.
It was not possible to click on the lower part of the last line
when the editor was scrollable and listening for mousedown events on renderedLines.
Closes#464
Previously Rails classes would infinitly loop if the Ruby on Rails
grammar was loaded but the Ruby grammar had not been. This occurred
because a rule was continually pushing itself on the stack but never
advancing.
Now if the position does not advance and the last two rules in the
stack have the same scope the last rule is popped and the entire line
is tokenized with the current scopes.
Closes#524#486
