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.
…and remove a bunch of dead source maps handling. Source map handling
for stack traces is now built into Chromium so it shouldn’t be needed
here.
Original event properties maintained for backward compatibility with the
1.0 API. Can be deprecated for 2.0 once we transition
exception-reporter.
Closes#7306
We started noticing that when a `TextEditor` pane got split, the same view for
`Gutter` was being shared amongst several models, thereby making the same DOM
element accessible simultaneously by more than one object. This made us
experience *orphaned line numbers*, caused by two instances of
`LineNumberGutterComponent` mutating `.line-numbers` at the same time.
This is a typical race condition which I would normally address by understanding
and possibly locking the correct order in which operations should happen.
However, I believe in this situation we shouldn’t actually care about ordering
at all, since I think views should be kept “local”, thus avoiding to expose them
to the world and/or reusing them across other views (either accidentally as in
this case or on purpose).
