This prevents the parent tile from disabling sub-pixel anti-aliasing.
For some reason, adding `overflow: hidden` to the cursor container
element doesn't solve the issue, so we're adding this workaround
instead.
This change fixes an issue where users on Linux are able to paste into
read only TextEditors by clicking the middle mouse button. The fix is
to check for whether the TextEditorComponent's isInputEnabled method
returns true before pasting with middle click on Linux.
This only now became necessary because TokenizedBuffer now *always*
receives a reference to the Atom config on construction, and always
tries to read from it when isFoldableAtRow is called, which can happen
after test cleanup due to resize observers.
Previously, we used to prevent the user from dragging the selection
further when the buffer was about to change. This was problematic
because any change in the buffer, even one that was performed
"automatically" by a package, would cancel the dragging action and
result in a confusing experience for the user.
On the other hand, we want to prevent users from accidentally selecting
text when they perform an edit (see #15217, #15405).
This commit addresses both concerns by canceling the dragging as soon as
the user interacts with the keyboard, instead of canceling the dragging
when the buffer is about to change.
One downside of this approach is that it changes the behavior of
pressing a keystroke that does not result in a buffer change, e.g.
Shift, Arrow Keys, etc.
Signed-off-by: Jason Rudolph <jasonrudolph@github.com>
* Restate the folding logic to not *use* the TextEditor, but instead to
*return* ranges which can be folded by the editor.
* Convert the LanguageMode spec to JS
In https://github.com/atom/atom/pull/15503 we mistakenly assumed
`marker.isValid` accounted only for the validity of the marker. However,
that method returns `false` also for markers that are valid but have
been destroyed. As a result, the editor component was mistakenly not
removing block decorations associated with such markers.
With this commit we will rely on the local `wasValid` variable instead.
If its value is `true`, it means that the block decoration has been
accounted for in the `lineTopIndex` and must, as a result, be cleaned up
in case the marker or the decoration gets destroyed.
This prevents the dummy scrollbars from resetting their position to `0`
when the editor element is moved elsewhere in the DOM (e.g. when
splitting a pane item).
Previously, when trying to use block decorations on non-empty markers,
Atom could sometimes throw an error if such markers ended or started at
a position that was not currently rendered.
In fact, even if we already restricted the decoration query to markers
that intersected the visible row range, markers that were only partially
visible would still be considered for rendering. If, depending on the
`reversed` property, we decided to render the tail or head of the marker
in question and this was outside the viewport, Atom would throw the
aforementioned exception.
This commit addresses the above issue by explicitly ignoring block
decorations that are located on rows that are not yet rendered.
