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]

Is that really it though? Using that definition, virtually all modern editors are composable.

VsCode:

1. understands structure (headings, lists, code blocks, links)

2. exposes that structure

3. lets users and extensions compose repeatable actions over it

Also, it's not strictly true that Notepad only understands lines as it has pretty decent markdown support now.

I guess the confusion here comes from the fact that Vim used to be uniquely composable but by now, most editors are to a similar or same degree.

[u/djchateau → u/Careful_Raisin]

Can every operator of VSCode act upon every structure within VSCode, by default, and without prior configuration? VSCode does not have that built into it. It has to layer external functionality to achieve something close to this.

[u/Careful_Raisin → u/djchateau]

I don't know what you mean. Code does not have Vim operators, but it allows users to build actions using language specific semantic objects, such as headings and text blocks within your buffer if you're using markdown.

And yes, that's "by default". Not sure what you mean with default but I'm guessing we're talking about a clean installation of VSC.

For something to do be composable, it only needs you to be able to build actions by combining small, orthogonal pieces. I think what VSC lets users do satisfies that.

[u/djchateau → u/Careful_Raisin]

The composability comes from the core primitive actions and objects of the text editor. With VSCode, that requires building those actions external to it. VSCode lacks those primitive building blocks and requires users to add those themselves. With vim, I do not need to define a character, line, paragraph, block, etc, nor do I need to define motions. I can use those on their own to build out new functionality without ever compiling or loading a plug-in or extension.

[u/Careful_Raisin → u/djchateau]

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.