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.
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.
I deleted a bunch of documented methods. I haven't added any new
undocumented methods, but now there are fewer overall documented
methods, which is breaking the docs threshold spec. I don't think it
makes sense to start documenting non-related methods in this branch
right now.
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.
Previously if the --dev flag was used and no resource was
specified or found in ~/github/atom then the app would
crash trying to add a null resource path to the node paths
list.
Now the bundle resource path is the fallback whenever the
dev resource path cannot be found or does not exist.
