I realized a few days ago that the `#is?` and `#is-not?` predicates — which
puzzled me upon first investigation back in February, and which I'd ignored ever
since — are exactly what I should've been using all along for scope tests.
They are counterparts to `#set!` in that they are two additional buckets in
which to store arbitrary data. And they remove the need to have both
`test.onlyIfFoo` and `test.onlyIfNotFoo`, since the presence of `test.onlyIfFoo`
in the `refutedProperties` bucket can behave opposite to the its presence in the
`assertedProperties` bucket.
This further means that a test called `test.onlyIfFoo` can be renamed
`test.foo`. The `onlyIf` was my way of making it clear through context that this
`#set!` predicate actually enforced a criterion — but that's implicit now that
it'll be using an `#is?` or `#is-not?` predicate.
I also took the opportunity to move `test.final` and `test.shy` to their own
namespace. `final` is an oddball in the sense that it sets criteria for _other_
captures as well as its own, and they're both oddballs in the sense that they
consider the effects of other captures on the same range. And I don't want to
introduce the idea that a predicate like `#is?` can have side effects.
So they stay on `#set!` and live at `capture.final` and `capture.shy`,
respectively.
To summarize, here's a before and after:
((string "\"" @punctuation.start)
(#set! test.onlyIfFirst true)
(#set! test.final true)
((bar) @baz
(#set! test.onlyIfNotDescendantOfType thud))
becomes
((string "\"" @punctuation.start)
(#is? test.first true)
(#set! capture.final true)
((bar) @baz
(#is-not? test.descendantOfType thud))
This PR changes all the built-in grammars. I don't know if there are any
third-party modern-Tree-sitter grammars out there except for mine, but I've
added a simple compatibility layer so that all of the old predicates should
still work for now. But I'm going to remove that code before we ship this stuff
for real.
…so that they can be scoped differently in themes.
The TM grammar already had the `meta.structure.key.json` scope, so
I've added it here. Further work would need to be done if we wanted JSON
keys to be highlighted differently in built-in themes.
Predicates were getting pretty chaotic. With the namespace, it's now clearer
where a predicate may be defined and what its purpose is. It also helps resolve
ambiguity — e.g., both folds and highlights can have an `endAt` predicate, so
now they're disambiguated as `fold.endAt` and `adjust.endAt`, respectively.
Namespaces:
* `highlight` for highlight-specific settings (of which there is presently only
one)
* `test` for scope tests (currently used by highlights and indents)
* `adjust` for scope adjustments (highlights)
* `indent` for indent settings
* `fold` for fold settings
Right now, only the `test` namespace will be used by more than one kind of query
file, but I could imagine that changing in the future.
For now, tests and adjustments still work without the prepended namespace, but
I imagine I'll take that out even before we ship this feature experimentally.
Much easier to make big changes like this before anyone depends on them.
This also draws a much clearer line between `#set!` predicates with special
meaning in Pulsar… and those which are being used to set arbitrary data for
later use. For instance, if you see `(#set! isOnLeftSideOfAssignment true)`, you
know it must just be arbitrary data.
…along with a temporary `core.useExperimentalModernTreeSitter` setting.
If we truly planned to keep three different language modes around indefinitely,
changing `core.useTreeSitterParsers` to an enum would make sense. But we don't,
so it'd actually just be a gigantic pain in the ass to migrate one setting to
another of a different type.
When we ship modern-tree-sitter experimentally, we'll make it opt-in via the
temporary setting. When we make it the official tree-sitter implementation and
remove the legacy node-tree-sitter version, we'll remove the temporary setting
and just change the semantics around `core.useTreeSitterParsers`.
Reverting the addition of the `core.languageParser` setting is a chore, but it
prevents a _gigantic_ future headache.
The `syntaxQuery` key in a grammar definition file is the only query whose name
differs from its canonical filename, and there's no reason why that should be
the case. Might as well change it now before we ship instead of going through
the pain of changing it later.
To make https://github.com/atom-community/atom/pull/386 reviewable,
that pr will be separated into many simpler prs. This is one of them.
This first commit does the following:
- update package.json
- update package-lock.json using `./script/build` which also seems to update `apm/package-lock.json`
- update packages/README.md
- clone all language packages. Specifically:
- `mkdir packages/language-<all of them>`
- `cd packages/about`
- For all languages:
- `cd ../language-<>`
- `git clone language-<>`
- Move all files except `.git` from `language-<>/language-<>`
to `language-<>`
- delete `language-<>/language-<>`
Since at first I accidentally updated `dependencies` then
`packageDependencies`, it appears that since the versions of language-c,
language-css, language-go, language-javascript, and language-sass don't
match, `dependencies` was reset for those versions.
[Those repos just happen to be precisely the ones that have tree-sitter v19](https://github.com/icecream17/atom-update-backlog/blob/main/Languages.md), (sans language-sass),
which [currently breaks atom](https://github.com/atom/atom/issues/22129). So even though their repos are now
in `packages`, **I've decided to not use them**.
This is done by updating `packageDependencies` only for non-breaking
languages.
