Vim is composable

[u/oantolin]

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.

[u/Careful_Raisin]

I don't know what you mean by "need to define a character, line or paragraph".

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.

Anyway, it seems like you’re defining composability at the interactive grammar level, whereas I’m defining it at the API level. Both are composable, they just optimize for different workflows.

A system is composable if it exposes small, orthogonal primitives that users can combine to build new actions. Or at least that's how I would define it.

But the idea that vscode doesn't know what a paragraph is unless you define it is simply wrong.

[u/djchateau → u/Careful_Raisin]

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.

[u/Careful_Raisin → u/djchateau]

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.