4 ms·

I wonder why there aren't more tools to allow structural editing like Lisp has. This way the file can never be in an unparsable state.

by aeonik 3y ago

ghosty141 3y ago
This is what treesitter enables!
nequo 3y ago
You may be aware but the author of TFA also has a tree-sitter based minor mode called Combobulate for exactly that: https://www.masteringemacs.org/article/combobulate-structured-movement-editing-treesitter https://www.masteringemacs.org/article/combobulate-structure... There is also evil-textobj-tree-sitter for tree-sitter based text objects for Evil mode: https://github.com/meain/evil-textobj-tree-sitter https://github.com/meain/evil-textobj-tree-sitter
rprospero 3y ago
I spent a couple of months working with a tool along those lines. Unfortunately, it's one of those issues where it won't work specifically without the galactic emperor mandating these tools under pain of death. A colleague using VS Code would commit code with unbalance parentheses. The tooling was smart enough that it could load the file, even though it wasn't parsable, but there was no structural was to fix the missing closing brace. Adding a closing brace automatically inserted another opening brace, leaving the original mismatch.
taeric 3y ago
This is not fully correct. You are right that lisp has very regular atoms that you can read, but the full parsing is different. Consider (let (a 0) (1+ a)) is not valid syntax. Such that if you were to add color for the different parts, it would fail. Indeed, if you want to label the parts of the program tree, you have to parse it more than just "lists of atoms."
Barrin92 3y ago
because in most languages there's a level of abstraction between the syntax of the language and the actual data structure of the program. To use the much maligned term, most languages aren't homoiconic, the internal structure of the program is hidden away from the programmer. Lisps essentially have no syntax, that's why it is trivial to manipulate a lisp program structurally.
- vidarh 3y ago
  You can do this with most other language too, but I think the challenge is that a lot of us have habits that we'd need to change. E.g. with structural editing I couldn't easily decide I want to add exception handling around a block in Ruby by writing "begin", then moving down, and writing "rescue ..." and "end" - I'd likely need to mark the block first. That may well end up being faster, but it's a fairly big change. I wonder, though, if a "semi-structural" editor with a keypress to "complete what is otherwise an error" would work well. E.g. I write "begin" and so imbalances an expression, and the editor looked at what I typed that changed the parse from successful to an error and puts up options to insert "rescue ... end" or just "end". Maybe coupled with a warning on save if the file does not parse.

I wonder why there aren't more tools to allow structural editing like Lisp has. This way the file can never be in an unparsable state.

by aeonik 3y ago

I wonder why there aren't more tools to allow structural editing like Lisp has. This way the file can never be in an unparsable state.

ghosty141 3y ago

This is what treesitter enables!

nequo 3y ago

You may be aware but the author of TFA also has a tree-sitter based minor mode called Combobulate for exactly that: https://www.masteringemacs.org/article/combobulate-structured-movement-editing-treesitter https://www.masteringemacs.org/article/combobulate-structure... There is also evil-textobj-tree-sitter for tree-sitter based text objects for Evil mode: https://github.com/meain/evil-textobj-tree-sitter https://github.com/meain/evil-textobj-tree-sitter

rprospero 3y ago

I spent a couple of months working with a tool along those lines. Unfortunately, it's one of those issues where it won't work specifically without the galactic emperor mandating these tools under pain of death. A colleague using VS Code would commit code with unbalance parentheses. The tooling was smart enough that it could load the file, even though it wasn't parsable, but there was no structural was to fix the missing closing brace. Adding a closing brace automatically inserted another opening brace, leaving the original mismatch.

taeric 3y ago

This is not fully correct. You are right that lisp has very regular atoms that you can read, but the full parsing is different. Consider (let (a 0) (1+ a)) is not valid syntax. Such that if you were to add color for the different parts, it would fail. Indeed, if you want to label the parts of the program tree, you have to parse it more than just "lists of atoms."

Barrin92 3y ago

because in most languages there's a level of abstraction between the syntax of the language and the actual data structure of the program. To use the much maligned term, most languages aren't homoiconic, the internal structure of the program is hidden away from the programmer. Lisps essentially have no syntax, that's why it is trivial to manipulate a lisp program structurally.

vidarh 3y ago
You can do this with most other language too, but I think the challenge is that a lot of us have habits that we'd need to change. E.g. with structural editing I couldn't easily decide I want to add exception handling around a block in Ruby by writing "begin", then moving down, and writing "rescue ..." and "end" - I'd likely need to mark the block first. That may well end up being faster, but it's a fairly big change. I wonder, though, if a "semi-structural" editor with a keypress to "complete what is otherwise an error" would work well. E.g. I write "begin" and so imbalances an expression, and the editor looked at what I typed that changed the parse from successful to an error and puts up options to insert "rescue ... end" or just "end". Maybe coupled with a warning on save if the file does not parse.