…when an editor regains focus.
This used to happen until the change in <https://github.com/atom/atom/pull/20892>. But we still need this code, presumably because of built-in browser behavior that _implicitly_ scrolls the editor's container to try to move the hidden input back into view.
When a region of the buffer changes, we want to consider all injections that touch that range, even if they aren't fully enclosed by the range. So we need to be able to grow the original range when searching for injection layers.
This fixes a bug in which the candidate range could inadvertently _shrink_.
Older versions of node-gyp are incompatible with Python 3.12+,
at least out of the box, since Python 3.12+ no-longer ship with
'distutils' out of the box.
We can work around it by installing 'setuptools' package,
which comes with the required 'distutils'.
Newer versions of node-gyp should come with a fix for this,
but older Yarn or npm will ship with older node-gyp, so here we are.
Note that this isn't really needed on the ubuntu-based CI workflows
for now, since those are on the rather conservatively-updated
Debian/Ubuntu-packaged versions of Python (no newer than Python 3.11,
at present.) But being proactive means this won't sneak up on us later.
Built a new `tree-sitter-cpp` parser from latest master to fix a parsing error with variable assignment. Also added/tweaked scopes for some specific scenarios.
1. `master` isn't always true. We can use `HEAD` now and GitHub will automatically redirect to the main branch.
2. We already have the logic inside our markdown to correct links to use `blob` or `raw` depending on if directing to a link or image, and use `HEAD` like mentioned above
When determining the possible breadth of injection layers that could be affected by a buffer change, I assumed that `MarkerLayer#findMarkers` would return results such that I could take the first result's start and the last result's end and end up with a range that containd all the results.
#756 proved that not to be true, at least in the case of Clojure — the effect of which is that lots of injection layers were getting ignored during the step where we decide whether to reuse existing layers or create new ones. That led to an ever-increasing number of injection layers being created.
Instead, we need to find the minimum and maximum points in the set and use that as the range.
GitHub Actions was set to only build for branch pushes (only master
branch due to the branch filter), PRs, and manual workflow dispatches.
Now, GitHub Actions will also build for tag pushes.
This helps to ensure Regular releases
get signed binaries built for them.
(GitHub Actions is set to only *sign* the binaries for push events.
Tag creations/pushes will generate push events, so tag pushes should
indeed make signed binaries, not unsigned ones.)
