Opinion: Structural editing is superior to the Vim grammar

5 pointsrishflab3y ago8 comments

I tried switching from jetbrains to various modal editors (neovim, doom-emacs, kakoune, helix). The fast startup time and continuity when working in a terminal environment was very appealing, as was the promise of increased code editing effeciency.

I liked the fast startup time and having the same keybindings to edit system config files but I am not impressed with VIM style text editing. First of all programmers don't really edit text, we edit code. VIM's grammar does not acknowledge this. It is centered around lines, words etc. Code is a tree. A grammar/keybinds designed around traversing, selecting and modifying this tree would be superior for editing code IMO.

Of course I can install tree-sitter and setup structual editing based bindings but am I really using VIM at this point? I don't think the VIM grammar is the future of code editing. I think it is a bit overrated. I think editor designers should work on developing a grammar/keybinds that center around structural/tree based editing. I have found that IDE's tend to acknowledge this tree based "reality" better than VIM.

I think this concept could even be applied to source control ie. git stores an tree-sitter like representation of code instead of text. Your text editor handles formatting.

8 comments

nequo3y ago

I agree with this sentiment. Line editing is to ASTs as a 4-speed automatic transmission is to a CVT. It is limited only by historical baggage and the power of habit.

> Of course I can install tree-sitter and setup structual editing based bindings but am I really using VIM at this point?

Why would this mean that you are not using Vim?

You are using Vim with a Vim extension that gives you better keybindings. That extension happens to pull in Tree-sitter, in the same way as Atom would. But your setup is faster and consumes much less memory.

Or to put it differently: Vim and Emacs both link to libpcre for regular expression parsing, but that doesn't mean that if you use regular expressions in Vim, you are using Emacs.

cookiengineer3y ago

As a long time VIM user, I tend to agree with you in your points. VIM and its concept was built at a time when text was green, and when you had maybe 30 lines of code in front of you.

My hopes for NeoVIM were that they changed the concept in the sense to find a new grammar that is based on the AST (sentences could be statements, for example). Sadly NeoVIM kind of underdelivered, syntax highlighting and AST/linters were always completely broken for me when I tried them out.

No idea why, there might be still some issues from me there that were closed due to inactivity (as if time would fix bugs magically).

I kind of hope that the LSP revolution will lead to better IDE concepts that can bridge the gap between navigation and repetition efficiency and the code's AST insights.

linsomniac3y ago

LunarVim might get you closer, I haven't explored any enhanced structural editing features with it, but it does have TreeSitter integrated and has a lot more IDE features integrated. The idea of structured editing seems interesting, but I've never really been able to wrap my mind around what that would realistically look like.

https://www.lunarvim.org/

samwestdev3y ago

What's `Structural editing`?

rishflabOP3y ago

Code can be parsed into an abstract syntax tree. Structural editing is editing code at the tree level. You probably already do it using expand/shrink selection.

If you have a selection eg. a node on this tree, expand selection would move up one level on this tree and select the higher node and everything underneath it.

You can play around with this concept here: https://tree-sitter.github.io/tree-sitter/playground. Click the blue elements in the tree section and see how it affects what is selected.

Now imagine a grammar/keymap which is optimized for traversing, selecting, mutating code at this level. I think this is the future, not the VIM grammar. Many IDE's already do this style of editing to an extent.

gigatexal3y ago

The point and power of vim or neovim and the others is plugins in my opinion. It can be customized to make you faster at what you do. I love my setup. It works great for me. I can’t use a full IDE, I’m broken in that way.

rishflabOP3y ago

Most VIM proponents mention the power of VIM's editing grammar as a selling point. I think the idea of having an editing grammar is good but VIM does it at the wrong level; text, instead of syntax aware tree.

swah3y ago

So you want the up and down arrows actions to move to the next statement instead of line?

j / k navigate · click thread line to collapse

Opinion: Structural editing is superior to the Vim grammar

5 pointsrishflab3y ago8 comments

I think this concept could even be applied to source control ie. git stores an tree-sitter like representation of code instead of text. Your text editor handles formatting.

8 comments

nequo3y ago

I agree with this sentiment. Line editing is to ASTs as a 4-speed automatic transmission is to a CVT. It is limited only by historical baggage and the power of habit.

> Of course I can install tree-sitter and setup structual editing based bindings but am I really using VIM at this point?

Why would this mean that you are not using Vim?

Or to put it differently: Vim and Emacs both link to libpcre for regular expression parsing, but that doesn't mean that if you use regular expressions in Vim, you are using Emacs.

cookiengineer3y ago

As a long time VIM user, I tend to agree with you in your points. VIM and its concept was built at a time when text was green, and when you had maybe 30 lines of code in front of you.

No idea why, there might be still some issues from me there that were closed due to inactivity (as if time would fix bugs magically).

I kind of hope that the LSP revolution will lead to better IDE concepts that can bridge the gap between navigation and repetition efficiency and the code's AST insights.

linsomniac3y ago

https://www.lunarvim.org/

samwestdev3y ago

What's `Structural editing`?

rishflabOP3y ago

Code can be parsed into an abstract syntax tree. Structural editing is editing code at the tree level. You probably already do it using expand/shrink selection.

If you have a selection eg. a node on this tree, expand selection would move up one level on this tree and select the higher node and everything underneath it.

You can play around with this concept here: https://tree-sitter.github.io/tree-sitter/playground. Click the blue elements in the tree section and see how it affects what is selected.

gigatexal3y ago

rishflabOP3y ago

swah3y ago

So you want the up and down arrows actions to move to the next statement instead of line?

j / k navigate · click thread line to collapse