Better to receive future minor/patch updates than pin exact,
considering this dependency used to be totally unbounded ">= 0".
We probably won't remember to update this in the future,
so best to specify a range rather than an exact arbitrary version.
This indirect dependency has a newer version that requires
Ruby 3.0 or newer. We're on Debian 10 "Buster" for now, which is
still on Ruby 2.5.
Pin to dotenv 2.8.1, the latest version compatible with our older Ruby,
per the error message from CI:
> The last version of dotenv (>= 0) to support your Ruby & RubyGems
> was 2.8.1. Try installing it with `gem install dotenv -v 2.8.1`
> and then running the current command again
>
> dotenv requires Ruby version >= 3.0.
> The current ruby version is 2.5.0.
* A new predicate called `fold.invalidateOnChange` that can be used when a change should automatically invalidate the fold cache for each row in a node's range.
* The ability to use custom predicates in `folds.scm` files. (Previously, captures from `folds.scm` did not consult an instance of `ScopeResolver` in the processing phase.)
…such as in multi-line self-closing tags and multi-line opening tags.
Also fix an issue in fold handling that made it impossible to use `@_IGNORE_` captures in `folds.scm`.
Changes:
* `#define FOO 1` and `#define FOO` will _always_ scope `FOO` as `constant.other.c`, even when `FOO` is mixed-case or lower-case.
* `#define FOO()` will _always_ scope `FOO` as `entity.name.function.preprocessor.c`, even when `FOO` is mixed-case or lower-case.
* Usages of bare identifiers in other contexts in preprocessor directives should always scope them as `constant.other.c` — unless I’m made aware of any counterexamples where that shouldn’t happen. For example: in `#if TABLE_SIZE > 200`, `TABLE_SIZE` should always be `constant.other.c`, no matter its casing.
* All-caps variable declarations and assignments (`int FOO = 0`, etc.) should scope `FOO` as `variable` rather than `constant`. We should only scope an arbitrary identifier as `constant` if we think it’s been used in the context of a macro definition.
However:
* When deciding whether something outside of a directive refers to a macro constant, we have no choice but to use the `ALL_CAPS` heuristic. Ideally we’d be able to determine that from some sort of analysis of the source code files — but even if we could keep track of that sort of thing in a single buffer, it’d fall down when macro constants _defined in other files_ are used. All we can do here is make a best guess.
This code snippet sets up logging so that a worker process can call `console.log` and its siblings and have them show up in the renderer process’s console… but it’s trying to destructure the antiquated magical `arguments` collection (which is like an array, but isn’t an array!) and the engine doesn’t seem to like it.
Logging didn’t work for me until I changed this.
This is such a tiny fix, and I don’t have the energy to shelve everything on this branch just to make a separate PR.