These events will only be fired a single time at most, so we should clean up the listeners after that.
This should help minimize accidental memory leaks.
Also, remove some barely used public APIs around cursor visibility that
don't make much sense and are not ideal for performance. We don't want
to subscribe to the visibility of each cursor.
As part of the test fixes, I’m honoring the `autoscroll: false` option
in `insertText` and `insertNewline` to avoid inadvertently scrolling the
editor during tests when the editor is modified.
Previously we were storing a {type: ‘selection’} property, probably
leftover from the “pre-marker-layer” world. We were also storing
`Selection`’s `goalScreenRange` on the marker, which is now just an
instance variable.
This ensures we correctly restore the last cursor when handling a cursor
destruction event. It fixes an exception that occurred when undoing
after splitting an editor.
Signed-off-by: Max Brunsfeld <maxbrunsfeld@github.com>
Currently there are only two regexps that can influence the indents.
Those are `increaseIndentPattern` (which tells Atom the indent of next
line should be increased) and `decreaseIndentPattern` (which tells Atom
the indent of the current line should be decreased).
But I found that a couple of languages would need a 3rd regexp in order
to support their use cases. This 3rd regexp should be a mixture of the
existing two so it tells Atom that the indent of the next line should
decrease.
I’ll add a screencast to show a use case for this 3rd regexp which I
would like to call `decreaseNextIndentPattern`.
Previously, we allowed a mix of tabs and spaces to be counted toward the
indentation of a line. This caused problems when auto-indenting lines in
a hard-tabbed file that contained “alignment spaces”, such as occurs in
aligned comment blocks. For this case, it makes more sense to assume
that the line is indented via tabs only, and consider the subsequent
alignment space as part of the line’s content. Since it’s hard to
imagine actual source code in which a mixed treatment of tabs and spaces
is desirable, I’m going with this over any more complex approach.
This is better behavior for alt-del/backspace operations, is less
"greedy" and doesn't eat up excess characters.
Also set default key mappings to these, feel free to trash my changes
to keymaps/darwin.cson. Though I do feel this should be default
behavior, personally.
When clipping a screen position, callers used to have to pick between
clipping to the left edge or the right edge when the position was in the
middle of an atomic token. This change allows them to choose the closest
edge, and makes this the default.
This makes selecting hard tabs (or any other atomic tokens) work in a
similar manner as in other text editors; that is, when clicking near
the middle of a tab, the insertion point will move to the closest edge
rather than the left edge.
Rather than when the selection’s marker changes. This is simpler than
suppressing autoscroll via state when we don’t want it. It also captures
the intent to autoscroll when attempting to move the cursor at the
beginning or end of the document.
Signed-off-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
