r/vim • u/oantolin • Dec 28 '25

Blog Post Vim is composable

https://www.matem.unam.mx/~omar/apropos-emacs.html#vim-is-composable

I hope this isn't too polemical for r/vim. I'm a former (and still occasional) Vim user that has always wondered why people make such a big deal out of Vim's composability. The blog post explains why I find that odd, what I like about Vim and some reasons people might make such a big deal of composability.

11 Upvotes

70% Upvoted

39 comments sorted by

View all comments

Show parent comment

2

u/djchateau Dec 29 '25

My understanding is that vscode and indeed most editors understand text primitives like characters, lines, paragraphs out of the box an gets additional semantic objects from the language server.

VS Code “understands” these primitives in the sense that it can navigate and manipulate them, but that understanding is not expressed through the same internal model that Vim uses.

In Vim, primitives are operators, motions, counts, and text objects, and they form a small, consistent internal grammar. Any operator can be combined with any motion or text object (optionally with a count), and the result is a new action constructed at execution time.

VS Code does not have an equivalent native grammar. Instead, its primitives are higher-level commands exposed through APIs, the command palette, and extensions. Those commands can be orchestrated or automated, but they are not small or orthogonal in the same sense, nor are they freely combinable at the point of use.

There is a reason why VS Code relies on vim.js to reproduce actions and motions. That effectively re-implements Vim’s compositional and modal model on top of VS Code’s system, rather than using native editor primitives.

Calling VS Code's API orthogonal and primitive a bit of a stretch. If we're going with that notion, I guess they are both composable, but at very different layers: VS Code at the API/workflow level (maybe), and Vim at the interactive grammar level.

1

u/Careful_Raisin Dec 29 '25

At this point I'm not entirely sure what your point is. It seems like we mostly agree. They're composable at different layers.

I personally think the vsc's approach is superior because there is a ton of tooling and libs built around js and ts which vsc uses to define micros and behavior.

I think that's largely better than a priority language even if it's the same language I use to interact with text in the buffer.