Here are some problems faced by semantic editors: 1. Bias. A lot of people think that if good ones haven't been built already, there must be some reason they c

Here are some problems faced by semantic editors: 1. Bias. A lot of people think that if good ones haven't been built already, there must be some reason they can't be built 2. You really want the parser to report not just what types of nodes it found at particular locations, but what types of nodes it could have found at that location, because those are the types that will be valid for insertion there. A semantic editor needs to know because it should only be able to create programs that the parser would be able to parse. 3. Extensible parsers: To make a huge number of parsers that exactly match languages, you need to be able to quickly define parsers that are closely related to each other, and what's more the cost of using the derived parser must be closely related to the cost of using the original. Tree-sitter can derive languages at compile-time, but not at runtime leading to three major problems: - 3.1 Runaway storage costs: the Tree-sitter grammar for JS is ~4mb, and the grammar for TS is ~12 MB and the grammar for TSX is also ~12mb and these grammars have things they shouldn't have in them like Ember's glimmer syntax, because that syntax is too poorly supported to justify paying the costs of copying the JS, TS, and TSX grammars (causing 28MB of new code duplication, in git no less). - 3.2 Failed semantics: Because the JS runtime grammar is just code copied into the TS runtime grammar, tree-sitter can't distinguish which parts of TS programs are really just plain JS. - 3.3 Umbrella languages: Because the grammar defines languages that are bigger than what you can actually use, the JS tree-sitter grammar will happily parse JSX even when it's invalid, which is to say a semantic editor would suggest inserting JSX even when it would break your program, which is clearly bad.