4 ms·
Having made my own forays into making a structural editor, I'd like to sing the praises of plain text: storing something that has been created by pressing butto
by penteract 2y ago
Having made my own forays into making a structural editor, I'd like to sing the praises of plain text: storing something that has been created by pressing buttons at a keyboard as something very close to the sequence of buttons that have been pressed is a great idea.
The magical ability of plain text is to go back in time and ask "what if I pressed a different button a minute ago/yesterday/last year?". This lets you see and fix mistaken keypresses, and even shapes the kind of mistakes you can make in a moment of confusion into ones that are quickly fixable.
The direct representation of buttons pressed also really helps with teaching/learning: With plain text, for mechanical questions on the level of "What buttons do I press to make a program that looks like that?", the answer is obvious for anyone who knows how to type. Try the editor discussed in the article to appreciate how different answering that question can be in a structural editor. Seeing and explaining how someone got where they did is also straightforward ("you missed a semicolon", "you misspelt a variable name"). Ideally, those are problems that don't happen in a structural editor, but people who press a slightly wrong sequence of buttons will probably still exist.
These arguments get much weaker when you aren't using a physical keyboard; I think this is the reason the article starts by talking about writing programs on a phone and a TV. In those environments structural editing has much more to offer.
- WillAdams 2y agoI've tried to use LEO (Literate Editor with Outlines) a couple of times, but have never found it comfortable enough to stick with. That said, the concept of Literate Programming has been one which resonated with me, and which addresses some of the same problems in a fashion which matches the way I work.