You missed all the cursor movements (whether by mouse/keyboard) needed for the plain text editor:
1. Position cursor before the call from wherever it is right now (might be quick because your editor already allows some form of structure in it's movement commands: words, parentheses, visual jumps, etc or you might need 10+ presses of the left arrow)
2. Type "(if flag "
3. Position cursor after the call - maybe just a press of "End"/$/shift-A/...
4. Type ")"
Your two ways of structural editing seems to be an artifact of Lisp - I agree that most programming languages have issues when editing structurally - especially when using an abstract/concrete Syntax tree as the structure as compared to a non-syntactic representation (e.g. expression graphs where only types need to match).
So when this weird difference does not exist, you can always use the second strategy you listed. This already includes necessary cursor movements/selections and is one step shorter than the commands necessary for textual editing.
I think that any editor will always have to deal with partial programs - it's just the holes/errors are in different parts. The right UX can make dealing with that possible, just as auto formatting, syntax highlighting, inline type display, etc help somewhat deal with parts already in existing editing systems.
I think there's plenty of ways to make the UX work - for a programming language and ecosystem designed for it. So I think that structural programming should be a complete environment - programming language, editor with a good editing meta-language mapped to keys/auto complete/etc, language server equivalent, structural version control, build system, code sharing/review (diffs!) and legacy interface to textual tools. There'll be a tipping point where one has enough benefits from the structure in each of these to overcome the unavailability of many existing tools like grep/etc. A single structural editor experiment likely isn't at that tipping point unless the UX is really a significant improvement like github.com/cursorless-dev/cursorless is for many folks.
1. Position cursor before the call from wherever it is right now (might be quick because your editor already allows some form of structure in it's movement commands: words, parentheses, visual jumps, etc or you might need 10+ presses of the left arrow) 2. Type "(if flag " 3. Position cursor after the call - maybe just a press of "End"/$/shift-A/... 4. Type ")"
Your two ways of structural editing seems to be an artifact of Lisp - I agree that most programming languages have issues when editing structurally - especially when using an abstract/concrete Syntax tree as the structure as compared to a non-syntactic representation (e.g. expression graphs where only types need to match).
So when this weird difference does not exist, you can always use the second strategy you listed. This already includes necessary cursor movements/selections and is one step shorter than the commands necessary for textual editing.
I think that any editor will always have to deal with partial programs - it's just the holes/errors are in different parts. The right UX can make dealing with that possible, just as auto formatting, syntax highlighting, inline type display, etc help somewhat deal with parts already in existing editing systems.
I think there's plenty of ways to make the UX work - for a programming language and ecosystem designed for it. So I think that structural programming should be a complete environment - programming language, editor with a good editing meta-language mapped to keys/auto complete/etc, language server equivalent, structural version control, build system, code sharing/review (diffs!) and legacy interface to textual tools. There'll be a tipping point where one has enough benefits from the structure in each of these to overcome the unavailability of many existing tools like grep/etc. A single structural editor experiment likely isn't at that tipping point unless the UX is really a significant improvement like github.com/cursorless-dev/cursorless is for many folks.