[disconcision]

good questions! both will be addressed soon with david moon's new tylr version (tylr being the underlying syntactic engine for hazel). the new tylr is designed to take a grammar as a parameter; we have a javascript grammar and a partial rust grammar, and are planning editor integrations. the new model also eschews the backpack (the yellow thing that contains matching delimiters) in lieu of inserting missing delimiters as 'ghosts' in a way that always shows the exact parse that the semantics engine is using, but also doesn't prevent typing normally. the current backpack solution is the result of trying to balance natural text editing with mandated syntactic correctness and it definitely has proved to have some rough edges... more on the new system soon

[conartist6]

The homepage assures me that Hazel's mission is to take semantic editing and ensure that the core of the experience is text editing in the most literal sense, for example by allowing you to make selections that cross-cut the tree. I just don't understand why!!! Both the current UX and the proposed UX are less useful and less semantic than the editing tools I already use.

For example in VSCode if I type ( the editor inserts () -- it's actually not a text edit in the sense that the code I produced doesn't map 1:1 to the keys I pressed. No, what actually happened there was already a semantic edit. It was quick and efficient. One keypress. Having a busted document is a worse experience than that, and having a document which is in a sort-of-busted-ghost-mode is also a worse, less semantic experience than I already have. Why would I want either of those experiences for myself or others?

[disconcision]

re: the first: this is in contrast to traditional structured editors which actively prevent you from doing edits that break the tree structure, even if the next edit would immediately restore them. users tend to do these often when refactoring; we looked at some examples versus a trad structured editor (MPS) here: https://hazel.org/papers/teen-tylr-vlhcc2023.pdf

in general though i have mixed feeling about making structured editing more text-like; the above is just about trying to patch a hole in existing structured editors, which doesn't in-itself improve on text. i think we can do better than that; we're exploring more radical directions in a separate project. but i do think it is interesting to see how close to regular text entry we can stay while always maintaining a well-formed (though incomplete) parse state which we can use to constantly run type-checking and evaluation.

the current model partially succeeds in the above, but at some significant usability cost, including the fact the the backpack obscures what the actual underlying parse state is. the ghost model i'm describing can basically be thought of a generalization of the vscode parentheses insertion you describe; it just works for every multi-delimiter form (eg when you insert 'let' you get ghosts '=' and 'in', with appropriate holes inserted). the utility is (A) the same as an incremental parser in a language server (you get semantic feedback in every state), but because of the ghost/hole insertions it's crystal clear what the parse state is that you're getting feedback from. but yeah the current version doesn't live up to that standard

[conartist6]

If you have holes, I would think you should generally be able to make arbitrary structural edits without ever passing through any outright invalid states, not unlike taking Lego bricks apart and reassembling them in a different configuration.

Recovering from bad parses is the state of the art in the industry right now, but it suffers from the "garbage in garbage out" problem because the user's intent is lost. In point of fact it is never captured in the first place! When you say that typing `let` ghosts out should all that other stuff, that's based on pure assumption. The state of the editor would look just the same if the user was part way through typing out the word `letter` which they intended to use as an identifier. No technology in the world can make things right after the user's intent has been lost.

The real way forward, the direction nobody is looking, is how to make tools that are more like musical instruments. An instrument doesn't guess at your intention and then aim to please you, but rather it amplifies the importance of each decision and impulse that go into playing it, making the player more expressive then they could have been otherwise.