/cc @zcbenz since we don't use sendMessageToBrowserProcess anymore
these specs aren't mocked correctly. Is there a method that we can
mock when calling remote objects?
Now packages can register custom handlers for different kinds of file
paths. If the function you register returns a resource for the given
path, it will be returned from Project.open instead of an EditSession.
insertText now takes these options:
* autoIndent will auto indent all inserted text based
* autoIndentNewline will indent a line when a '\n' is inserted
* autoDecreaseIndent will decrease the indent if the line matches a
decreaseIndent pattern (such as a `}` in javavascript)
If we remove a large number of screen lines when we are scrolled down,
the current @firstRenderedScreenRow may end up being larger than the
number of screen rows we now have. Setting renderFrom to the
@firstRenderedScreenRow in this case was causing the renderFrom to be
larger than the renderTo, which was causing problems downstream with
the new mapping code.
When we're creating folds that contain other folds, we'll need the
region based on the new fold's row mapping to overwrite the regions
from the old folds. This commit ensures that the new region cleanly
slots in, replacing any regions it completely contains and splitting
regions that it only partially overlaps.
If there are multiple mappings following the start row of the delta
that span fewer screen rows than the delta, we collapse mappings to 0
screen rows until we have removed the number of rows specified by the
delta.
Expanding positive deltas expands the first mapping following the
start row as it did previously.
Inserting a mapping should never change the position of any existing
mappings on screen or in the buffer. It's simply a statement about a
range of rows in the buffer mapping to a range of existing rows on
screen, but shouldn't add or remove any rows. Adding and removing rows
on screen or in the buffer is the job of the applyBufferDelta and
applyScreenDelta methods.
If 'foo' has not been set and has a default value of 1,
config.set('foo', 1) will not store the 1.
If 'foo' has been set to X and has a default value of 1,
config.set('foo', 1) will remove 'foo' from config
Lines that are all whitespace are considered trailing
whitespace and should display the indent guide.
But lines with leading and trailing whitespace should never
have the indent guide rendered in the trailing area.
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.
Previously any non-null value would be used as the target
column in the wrap guide and autoflow packages when really
80 should have been used if the value was non-postive.
Now config.getPositiveInt() is called with a default value
of 80 if the current value isn't already positive.
This event comes from initially setting the text for the current
config value on the editor and was causing the config to be
immediately saved multiple times when opened.
Previously if an integer or float field was empty it would
default to zero instead of undefined which made it inconsistent
with string value fields.
Now the config value is only set as a Number when it can be
parsed as one.
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.
Stop relying on setInterval to trigger the scroll events in the spec. Instead simulate the mouse moving at the top of the screen. I found
testing the setInterval approach required so much mocking that it
wasn't worth it.
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.
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
