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.
Previously, we were hiding scrollbars when their height/width was 0. On
macOS, however, users can decide to only show scrollbars while
scrolling, which causes Atom to detect scrollbars as being invisible
during measurements. As a result, we were mistakenly setting the
visibility property to `hidden` when this setting was on, thus
preventing users from seeing the scrollbar on scroll.
With this commit we are changing the dummy scrollbar components to only
become invisible when the content is not scrollable rather than when the
scrollbars have zero width or height.
As part of this, we have also renamed the
`is{Horizontal,Vertical}ScrollbarVisible` functions to
`canScroll{Horizontally,Vertically}`, to better express their intent.
This was fixed back in bac9922 and, due to the same reasons, not having
a separate layer causes the "Show scrollbars only when scrolling"
setting on macOS to not work properly.
Previously, when a marker became invalid we would delete the
corresponding block decoration from the DOM, without however removing it
from the `lineTopIndex`. Also, we had a similar issue when decorating a
marker that was already invalid: we would account for it in the index
without adding it to the DOM.
This commit addresses the above problems by ensuring that block
decorations are never added for invalid markers. At the same time, the
editor component will still keep track of changes on the marker that was
decorated, so that it can detect when its validity changes and render it
appropriately.
This commit introduces a change in the way we respond to mousewheel
events. In particular, if `delta * scrollSensitivity` is less than 1 or
greater than -1, we will round it up or down in an attempt to honor the
user's scroll intent.
As a consequence of https://github.com/atom/atom/pull/15378, we are now
able to render highlight decorations in a separate div, as opposed to
having an highlight container for each tile.
Code-wise this is much simpler, because highlights spanning multiple
tiles can be represented via a single region and don't need to be split
across the tiles they span anymore. As a byproduct, performance should
improve as well, because the number of nodes that need to be managed
should decrease significantly.
This also fixes https://github.com/atom/atom/issues/15449, and other
similar rendering artifacts, because highlight decoration DOM nodes
won't need to move between tiles anymore when their position changes.
This implements automatic focus management for modal panels using the
excellent focus-trap module.
Upon being shown, modals will have their first tabbable element
automatically focused, and shifting focus with the tab key (or more
correctly the core:focus-next command) will be limited to the contents
of the modal. If the modal does not have any tabbable elements, focus()
will be sent to the panel's root element (if it implements it).
I'm happy to update this to *always* calls focus on the panel's root
element, but then modal implementers would need to handle that and
focus things on their own. I'd argue the tabbable element behavior
is more accessible though :)
This has the effect of not automatically closing most of Atom's own
modals whenever the tab key is pressed, which was an odd nonstandard
behavior, IMO.
This also automates returning focus to the element that had focus before
the modal was shown, something up until now had to be implemented in
every modal in Atom.
This likely breaks a few contracts for existing Atom packages that
create modals, but I've found this doesn't conflict behaviorally with
well-behaved modals like the command palette which implement their own
focus management (which can be removed if this lands).
Released under CC0.
This adds support for listener objects which, in addition to the existing callback listeners, can optionally provide a displayName ahead of time to avoid a potentially awkward humanized displayName.
This was bootstrapped with running `decaffeinate` on both command-registry
and its spec, but involved a line-by-line eyeing and updating for idioms
and, in one case, correctness:
For some reason, copying the keys to the new dispatchedEvent in
coffeescript (command-registry.coffee:235) currently does not result in a thrown
exception, as it should when trying to write over the read-only property
`isTrusted`, so I added a check to ensure that the key did not already
exist in the new event. Moreover, other definitions of `preventDefault`,
`stopPropagation` and friends, which are also enumerable afaict, would
also overwrite the ones defined just prior (command-registry.coffee:220
and command-registry.js:325), so that check ensures we don't overwrite
those either.
Test plan: `./script/lint && ./script/test`, and a lengthy smoke test of
various commands through keybindings, command palette, and package
interfaces.
Released under CC0.
