# molikto’s weblog

## Middle Grounds between Structural Editing and Text Editing

For editors of programming languages, where user manipulate some textual representation of the AST, users usually have some level of freedom to break out what is considered valid AST, and we list some of them from the most strict ones to least:

• Most structural editor only allow syntax-correct programs, like Hazel, Lamdu or Fructure. Sometimes they project to a lines-of-token presentation (Hazel), sometimes not (Lamdu)
• MPS is an editor that constantly performs syntax-directed and type-directed editing on the AST, but mimics text-editors. It allows some level of incorrect syntax. But in general the AST is not parsed, you cannot perform some complex editing, for example, wrapping some code by {} and hope it just works like in a text editor. Most of time the projection is lines-of-token, but they support two dimensional math expressions, and tables.
• Eco is an editor that works like a text editor when you are editing in a single language, but you can compose different languages and these language boxes works in a structural editor way
• text editors

I think editors more strict (including) than MPS has their problems (which I will not elaborate here).

Let's consider what's between MPS and Eco, remembering Eco's idea is based on incremental lexing & parsing:

• An editor where token is edited structurally like MPS but syntax is incrementally parsed like Eco. So the data format in this editor is not a syntax tree (like in MPS), or string (like in text editors, and to some extends, Eco), but is a sequence of tokens

• Escape characters is not needed, so you can have a keyword define and a variable define and they will be displayed in different color
• Color and font matters: for example in a cubical type theory 1 can means number literal or a constant formula, but in Cubical Agda you need to write i1 for the second case. In the proposed editor, they can have different font, and which one is selected is edited in a type-directed way