* 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.
The Rolling binary upload script gets the version from
package.json in the repository files, not from the binary
itself. So, we need to set this value in the repository's
package.json file, regardless of what version the binary itself has.
The version string in package.json is used by the Rolling upload script
to decide what the tag name will be when creating a new Rolling release.
We want timestamped version strings so they are unique,
and older releases are not overwritten/clobbered/won't have conflicts
(whichever would have happened, not worth finding out).
Besides that this restores the convention we had been uploading
the Rolling release tags with so far.
Set a version timestamp just before building the binaries, like on
the other two platforms. Add this to the outputs of the "build" job
if on Linux. Then read this output in the "test and upload, Linux" job.
Now we have synced timestamps again (as much as we did before building
Linux binaries in a Debian 10 Docker container, anyway).
The script could be updated to check the binary itself,
but this way is easier.
When enabled, will use the selected text in your editor as the search query in the symbols list.
Prefers an empty string if the setting is disabled, or if the editor selection spans more than one buffer line.
…no matter how deeply they’re nested.
Also highlight `?` in an incomplete ternary.
(Also fix a lot of final segments in the TypeScript highlights file; I’ve been lazily copying-and-pasting and forgetting to change them.)
We are crossing the Rubicon.
https://github.com/orgs/pulsar-edit/discussions/249 is a discussion of specific ways that indentation is different in JavaScript because of the new grammar. We intentionally didn’t try to preserve the indentation decisions in the old TextMate grammar, but this is (predictably) disruptive to some people. We don’t want to punt like legacy Tree-sitter did and rely on the TextMate grammar’s coarse regexes to decide what gets indented, but we can at least make the new indentation system granularly configurable.
This commit makes practically every indentation decision configurable in JavaScript and TypeScript. It groups these settings under a new “Indentation” section in each package’s settings.
I might decide that this goes too far and roll back the granular settings for `{`, `[`, and `(`, but the other indentation hints are absolutely matters of taste, so it’s only proper that users can choose to disable them.
In the long run, we could _consider_ allowing users to swap in another indentation engine altogther, much like #895 proposes for folds. That would let us legitimately offer users a way to opt into “the way the TextMate grammar does it” without affecting other users.
Another stopgap option would be to add a way for a user to disable indentation hinting altogether for a given grammar.
…when a project-specific config is present.
Most people don't use a project-specific config, which is why this bug has been present for ages. Read the new spec for an explanation.
