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.
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.
Previously, we were attempting to preserve the fold and adjust in an
intuitive way in the face of changes that straddled the beginning or
the end of the fold. That added complexity… we would have to add a new
marker invalidation strategy to support it and I'm not convinced it's
actually a big deal to destroy folds in the face of straddling changes.
So that's what we do now.
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.
DisplayBuffer should just focus on providing basic support for folding.
Scanning the structure of the code, looking at scopes, etc is more the
domain of the LanguageMode object.
Structural folding should really be handled at the edit session level
so that the DisplayBuffer doesn't need access to the LanguageMode. It
should only be concerned with the raw ability to create folds.
Since this is the more external method, having a shorter name
is more convenient. The former `buildEditSession` method took a
Buffer, and is now called `buildEditSessionForBuffer`.
This prevents the editor from synchronously redrawing in specs with
cursors in invalid locations. Markers are always updated under the
hood before a change event is emitted from the Buffer or DisplayBuffer.
We still wait to trigger marker observers, but if their position gets
read, it is up to date.
This is needed by the snippets package, which needs to know where the
cursor was previously when it moves to decide whether to cancel the
current snippet.
This is used by cursor to only autoscroll when the marker head is
explicitly moved, so that passive movements caused by buffer insertions
don't trigger autoscrolling.
Whereas marker methods on buffer take for granted that everything is
in buffer coordinates, methods on the DisplayBuffer offer both
screen and buffer coordinate versions of the marker API.
