…with one based on a better parser.
The `ikatyang` parser is great… until multi-byte input comes into play, or some other construct it doesn't understand. It doesn't have any way to recover when it hits those cases; it just throws exceptions, and WASM can't catch them.
The `MDeiml` parser for Markdown had one deal-breaking issue (https://github.com/tree-sitter-grammars/tree-sitter-markdown/issues/92), and once that got solved, it emerged as the clear victor.
Several people have been using this grammar as `language-markdown-alpha` on the repository, and none of them have encountered any problems of the sort they did with the `ikatyang` parser.
If it throws the Exception, other valid uris such as atom://teletype/...
will not be evaluated in the else branch
The old fs-plus did not throw.
Newer versions of fs.lstatSync allow for option parameter to control if it throws.
* When set to `true`, `hideDuplicateTextMateGrammars` will hide all grammars except whichever one the user has indicated a preference for — via `useTreeSitterParsers` and `useLegacyTreeSitter` settings, whether global or scope-specific.
* When set to `false`, `hideDuplicateTextMateGrammars` will show all grammars, even Legacy Tree-sitter.
…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.
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.
There's a hard-to-grok setting for language injections that allows a deeper layer to monopolize the scope application for a range. In most cases, an injection is placed into a node that the parser doesn't know much about (like a `script` block in HTML); but Rust and C parsers needed a way to inject themselves _into themselves_ so that they could add syntax highlighting to macros. Because they were applying highlighting to a range that the base layer _already_ had plans to highlight, they needed a way to block the shallower layer from acting.
This mode has never worked briliantly, but it's been made smarter in several ways since the invention of modern Tree-sitter. And here's another one: if the highlight iterator is at a position where an injection range is _about_ to begin, it shouldn't be able to stop any other layer from _closing_ a scope; and if the highlight iterator is at a position where an injection range has just _finished_, it shouldn't be able to stop any other layer from _opening_ a scope.
Because of this, we can now fix a bug that I think might've been present for a while in the application of scopes to rust macros like `println!` — the position after the exclamation point is one of those injection-layer boundaries, to the effect that a scope name was opened that would persist until at least the end of the screen line.
* Revert JSDoc tags to use the `keyword` namespace
* Ensure we always apply `meta.tag.jsx.js` to the area surrounding a JSX opening/closing/self-closing tag element and its punctuation.
