- "everything is a graph": the problem (as is obvious from various discussions on the web on the topic) with structured editors is to allow seamless editing of code. the standard example being converting a for loop to a while loop. My idea is to treat everything as being part of a graph, with infinite breakdown. The default level will be at the "syntax" level, but if you want to break that further, press a hotkey, and the syntax-based placeholders and user inputs get reduced to text nodes.
Superficially, this is similar to the "hybrid editors" that have a mode to switch to text input which is then parsed back. But the key difference is that the conceptual graph is retained.
Combine this with the leaf based parsing should help keep the experience smooth.
Some more thought:
operations allowed by a text editor
Superficially, this is similar to the "hybrid editors" that have a mode to switch to text input which is then parsed back. But the key difference is that the conceptual graph is retained.
Combine this with the leaf based parsing should help keep the experience smooth.
Some more thought:
operations allowed by a text editor
- navigate text
- create, modify and delete text
- copy and paste arbitrary text, either in line mode or block mode
to emulate this, how about a structured editor has a "text grid" view
- at every text grid event, the structure model is notified, and it changes the model accordingly
- if a placeholder value is changed, no model changes are required, just the slot value has to change
- if a keyword is changed, a triage construct consisting of the following is constructed:
- the rest of the structure is retained in the anticiaption of rollback,
- a new structure is anticipated and candidates are stored, which through multiple events may get realized into an actual new structure
- if a new structure is realized, the old one is discarded
- the engine will aim for the quickest new structure that can be realized, given the language syntax