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.
Previously, we were calculating the position preceding block decorations
for the row following the end of the highlighted range, but that's
actually wrong. We just want the position following block decorations of
the end of the highlighted range, plus one line height. This prevents us
from incorrectly rendering the end of highlight after block decorations
that immediately follow the end of the highlighted range.
When there are block decorations, we compute a `marginTop` style for
line numbers, so that they can be aligned correctly to the corresponding
line nodes.
This commit fixes a regression in the logic that calculated the
`marginTop` value, which was failing to correctly render line numbers
when block decorations were located right before the end of a tile, or
exactly at
the beginning of it.
This prevents the cursor from unexpectedly changing when approaching the
bottom/right corner of the editor with the mouse, even when no scrollbar
is being shown.
In attempting to optimize the performance of `isFoldableAtBufferRow` in
3c87b74, we mistakenly introduced a bug that caused lines that contained
a comment but didn't start with one to not be foldable anymore.
With this commit we are restoring the previous behavior, thus only
disabling folding for lines that start with a comment (ignoring leading
whitespaces).
Addresses issue pointed by out @nathansobo in #15277 where keybindings
for unfocusable nodes were being surfaced as accelerator indicators in
context menus.
When you right click in the DOM, your focus goes to the first focusable
ancestor of your click target. This change uses the ancestor that you
are actually focused on when looking for avaliable key bindings rather
than using the event target directly. This ensures that any surfaced key
bindings are actually reachable.
Previously, as soon as we decided to render linesToMeasure, we would
clear them out. However, if a second update interleaved with the update
that initially requested measurement, it could cause the requested lines
to not be present when the measurement phase from the first update
occurred. Now, any additional updates will only add to the set of lines
that need to be measured until the measurement phase actually happens.
Signed-off-by: Antonio Scandurra <as-cii@github.com>
When changing the editor styles, we force the component to remeasure
character dimensions. If they change, each line's height could change
too, causing the current scroll top position to not match the viewport
the user was observing. Thus, when detecting a line height change, we
try to show users the area of the screen they were looking prior to
tweaking the font size.
In trying to maintain the aforementioned logical position, however, we
were mistakenly scheduling a new update before actually finishing the
current one. This was problematic because if the first update detected
that the longest screen line changed and such line was off-screen, it
would try to render it. Before having the chance to measure it, though,
the new update would kick in and delete the new longest screen line
node, because it assumed it had already been measured. Finally, when
`measureContentDuringUpdateSync` fired, it would notice that the longest
screen line node did not exist and throw an exception as a result.
This commit changes the `updateSync` method to set the `updateScheduled`
flag only before returning control to the caller, as opposed to doing so
at the beginning. This prevents calls to `scheduleUpdate` made in
`updateSync` from scheduling new unwanted updates.
This avoids mysterious timing issues in which the editor gets a 'focus'
event in a state where `isVisible` returns false. If we always render
the hidden input, we can always focus it.
Signed-off-by: Antonio Scandurra <as-cii@github.com>
Previously, clicking on a block decoration to interact with it would
cause the editor to scroll to the line next to it. This is inconvenient,
especially if the decoration was designed to be interactive and
contained buttons or links. If the decoration was close to the bottom of
the screen, clicking on a button inside of it would make the editor
scroll down and abort the click.
This behavior regressed during the editor rendering layer rewrite and
with this commit we are restoring the original behavior by simply
ignoring clicks that land on block decorations.
I think this slipped through during the refactoring performed in
dc32018. With this commit we are fixing the regression and adding a new
main process regression test to exercise this behavior.
Electron allows us to pass an "accelerator" property for each menu item, which
is renders to the right of the menu item. We were already adding these for the
application level menus.
This pull request adds the accelerator property to regular context menu items,
which should make it easier for people to discover/recall key mappings for
actions which they usually take via a context menu.
Instead, if the measured line height equals 0, default it to 1 so that
the editor component doesn't start computing `NaN` or `Infinity` values
due to e.g. dividing by 0.
We should probably consider sanitizing line heights smaller than a
certain threshold, but that's non trivial because line height is
expressed as a multiplier of the font size. Also, users may style the
`line-height` property via CSS, which may still throw errors when using
small values.
