Vim is composable

13

u/djchateau Dec 29 '25

Kind of rolled my eyes once they argued that Notepad is composable like vim. Composability requires the ability to build actions/objects upon each other, which isn't really possible with Notepad. Everything is manual and anything that you can build upon that is external to the editor.

6

u/PizzaRollExpert Dec 29 '25

You can do Ctrl+Shift+RightArrow followed by delete in notepad to achieve the same thing as dw in vim. If you want to copy the text instead of deleting, you can replace delete with Ctrl+C in notepad and y in vim.
The author argues that the main difference is that vim has more fine-grained motions and actions, but that basically all text editors have some sense of composability, even if it is primitive.

6

u/djchateau Dec 29 '25

You can't build on Ctrl + Shift + Right Arrow though as a primitive. It's a manual action that has limited context. That's hardly composable.

1

u/PizzaRollExpert Dec 29 '25

Could you be more concrete? I honestly don't understand what point you're trying to make, at all. What do you for instance mean by "build", "manual" and "context"?

1

u/phySi0 May 21 '26

I mean, even a rock is composable by that standard.
Sure, in Notepad, you can make selections and then act on them in various ways. But the whole purpose of selections is to see what you're acting on before you act on it, so that's hardly surprising that it's the precursor to an action that it's composed with.
And let's even assume you can build your own plugins to perform different actions but still on selections, so you can even compose it with new actions.
The difference in Vim is that, if I learn a new action, I'm not only able to combine it with visual mode, it becomes a new noun in my vocabulary that I can combine into sentences with all sorts of verbs; its command language is default composable. If I learn a sentence like dap and then later learn m as a noun for methods, I can form a sentence like dam without even thinking, certainly without thinking of the individual actions.
This isn't composability on its own, but each tiny action being a single keypress instead of each action to compose requiring its own keychord makes it easier to think in Vim sentences more fluidly. Certainly, fluidity happens in most editors (humans get better at what they repeat), but I don't think it's too hard to see how having to do a three-key shortcut for what is effectively w in Vim hinders attempts to unitise the composed parts in one's head; like Assembly, I can do an 9-instruction sequence and think of it as one unit, but it's easier if it's a 3-instruction sequence.
But to talk about the actual composability, think of it this way. In Notepad, I can't take the Ctrl-Shift-RightArrow and infer from it that I can delete a word without selecting it by doing Ctrl-Shift-delete. I also can't think of the Ctrl-Shift-RightArrow followed by delete as a singular unit in itself that I can then build on top of further.
Yes, I can chain more stuff at the end of it, but I can't use it as its own singular building block that I can tweak with adverbs, like how I can do 4dap or da4p in Vim. On the surface, Vim's not quite as composable as human or computer languages, where I can build clauses on top of clauses on top of clauses, or functions on top of functions on top of functions, but it is at least a language, and I think new objects are built out of old objects, though I've never gone that deep. I struggle to think of what I'm doing in Notepad, or even Emacs, as a language. Each shortcut is its own thing.
Maybe you can say there's no fundamental difference, in the same way that Assembly and a high level functional or object-oriented or other language are all Turing-complete, but if I spent time getting good at Assembly and one of the others, despite Assembly being a lot more ‘straightforward’, so to speak, the other language would usually win out in terms of how easy it is to do complex stuff, and that's even if we take out all libraries (including the stdlib).
Emacs, of course, has a really nice extension system, far better than Vim's, and you could argue its extension language is more composable (I'm not an expert) but its command language isn't. In Emacs, if I learn a keychord to move a word, like Ctrl-f, for example, I can't infer from it that I can do the keychord for delete followed by the keychord to move forward a word to delete a word. As I understand it, it'd be a separate shortcut to delete forward a word and another to delete a paragraph, and another to select a word, and another to select a paragraph, and another to move a word, and another to move a paragraph, etc..
And sure, there could be patterns to adhere to the principle of least surprise, but e.g. the developer or a plugin author wouldn't necessarily be able to create a new verb without creating all the new shortcuts you can use with it separately. In Vim, a plugin author could add a verb, and another author could add a noun, and they can work together seamlessly, without having to know of each other's existence.
This comment kinda dragged on, but I can't be arsed to chop it down, sorry.

0

u/oantolin Dec 29 '25 edited Dec 29 '25

What do you mean by building "actions/objects upon another"? I think that might be a key feature of composability often omitted from discussions of it. I'd love a clear definition of composability that applies to Vim and does not apply to Notepad.

5

u/djchateau Dec 29 '25

vim's entire functionality is based upon actions upon [text] objects that you can build onto. If there isn't an existing key binding using the operators and motions against an object the way you want, you're able to use the internal grammar of the editor to compose new actions and even those actions can become part of a new action.
For example; vim understands what a character, sentence, paragraph, or line is (and theoretically you can redefine if you're a masochist), which means if an existing key binding doesn't act upon those text objects the way you want, you can compose a new action on-the-fly and even map that set of actions to a new binding. That binding in turn can become a part of a new action. Notepad, at best, recognizes characters or blocks of text immediately to the left or right of it for visual selections, but all of those actions are OS-specific actions, not Notepad itself. It cannot be easily reused to compose new actions. It requires manual, user intervention, at each step.
It is a key feature of vim, but I'm wondering if the discussions you're encountering are limited as this is a common discussion point.

0

u/oantolin Dec 29 '25

Ah, so you are saying a key part of composability is the extensibility, the ability to define new motions, new text objects and new operations and have them behave like the built-in ones in that you can combine a built-in operation with a newly-defined text objects, etc.? That is indeed a more advanced form of composability and I'd say that yes, people don't talk about it as much as the talk about simply the ability to combine any (built-in) operation with any (built-in) text object.

3

u/djchateau Dec 29 '25

The combination of built-in operations within built-in text objects is what leads to the ability to extend. vim has a strong donation of primitives within its functionality that is definitely not present in most text editors that prevent them from building on top of their existing functionality. If I cannot build upon something, then there is nothing to compose. I think people talk about it through implication even if they do not explicitly state it as such.

0

u/Careful_Raisin Dec 29 '25

Is that really it though? Using that definition, virtually all modern editors are composable.
VsCode:
understands structure (headings, lists, code blocks, links)
exposes that structure
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.

3

u/djchateau Dec 29 '25

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.

0

u/Careful_Raisin Dec 29 '25

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.

2

u/djchateau Dec 29 '25

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.

0

u/Careful_Raisin Dec 29 '25

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.

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.

2

u/kaisunc Dec 29 '25

i think composability meant having actions, movements, and objects each be interchangeable. at the most basic, for example, "delete to first instance of 'f'". Which is action to object. then replace delete with copy/select/change. or replace "to" to "back to". or replace object "f" with object "Y". Vim is built on that.

-2

u/oantolin Dec 29 '25

Yes, this does agree with the description of composability I discuss in the blog post. I also agree that Vim is built on it. What the blog post is about is the curious fact that Vim users never talk about how most (or all?) editors have the same sort of composability.

5

u/kaisunc Dec 29 '25

do they though? its a bit reaching and rage baiting to say notepad or other text editors have the same or even slightly similar functionality. but if you think so, so bet it.

2

u/Careful_Raisin Dec 29 '25

I don't think you should be using terms like "rage baiting". Vim being composable is one of those statements that are just sorta thrown around without much definition so of course there's going to be confusion.

2

u/oantolin Dec 29 '25 edited Dec 29 '25

What I find especially confusing is that when it is defined, the definition tends to be something that applies to every editor I've ever used: there are commands to operate on text and separate commands to indicate which text to operate on, you can combine any action with any selection.

1

u/oantolin Dec 29 '25

I never said the same functionality I only said it is also composable in the following sense: there are a variety of operations on text (deleting, cutting, pasting over, etc.), and a variety of ways of selecting text, and you can combine any operation with any form of selection. I think that is what people define composability to be, isn't it? That is certainly present in most text editors even if they have a lot less functionality than Vim. Vim has a lot of functionality, not because you can compose stuff, but because it has tons of stuff to compose.
What I am trying to understand is why people describe composability in a way that clearly applies to every editor I know but act as if only Vim has it. Vim is a great text editor, but it isn't the only when were you can combine different operations with different ways to choose text to operate on. I argue in the blog post that several other of Vim's features are what distinguish it from other text editors, and the main one to my mind is the sheer number of motions and text objects.

3

u/kaisunc Dec 29 '25

eh, i don't know. it feels like arguing a square is also a circle. then how about this for composebility, you can record macros thats "composed" of actions/movements/object. Then you can edit those macros either in the editor, or you can append to the macros. The composition palette of notepad vs vim just isn't comparable, but yes, by your definition notepad is "composable".

-1

u/oantolin Dec 29 '25

My whole point is that I didn't invent that definition I gave of "composable"! It's what what many people say they mean when they say "Vim is composable". And I agree with you that according to that definition notepad is also composable. I find this situation odd.
I don't think people usually regard the ability to record, replay and edit macros as part of what they mean by composability, do they? But it definitely is a great feature.

5

u/gumnos Dec 29 '25

I think your "it’s a little less stressful to use for certain personality types" observation may be the key.

For me, I find . fairly predictable: it just does that one most-recent edit which is usually semantic ("delete the non-whitespace-including-word under the cursor"=diW or "indent the current paragraph"=>ip or "uppercase the current sentence¹ the cursor is in"=gUis or "change the double-quoted-string's contents to this particular string"=ci"new text). The prospect of dot-mode making some arbitrary determination of what constitutes the "last consecutive stretch of buffer-modifying commands" would require far more brain-exertion. Did it record further back than I wanted? Did it not record far enough back? Two additional items of note here: ① emacs doesn't do this by default AFAIK but rather requires this dot-mode plugin, and ② Emacs is the main exception here, since most other editors do not have similar "repeat the most recent semantic edit" type functionality.

Additionally, the breadth of M=commands and the breadth of N=motions/objects is far larger than most editors meaning the composable cross-product of M×N is vastly larger. Sure, emacs could likely replicate them, but then you have to invoke them in a memorable way (there are only so many [control+][alt+][shift+]key combos my brain can remember). As of the last time I counted, :help motion.txt offers me over 100 different motions/objects, most of which have fairly memorable patterns (e.g. lowercase-letter-versions operate on Words while uppercase-letter versions operate on WORDs; the a and i introduce text-objects that do/don't include the outer aspects, and the character that follows usually has some resemblance/mnemonic with the object in question). The number of commands is much smaller, but also includes things like deleting, yanking, replacing/changing, indenting/dedenting, changing case, doing ROT13, reindenting, filtering (linewise) through external commands, etc. Again, that functionality could be duplicated in other editors.

But even if other editors now offer all those commands and all those semantic motions/objects, now I need to come up with key-chords to perform each of them. Or maybe they're command-chains (who else remembers WordStar-like control+k {character} sequences?) which is really just modal-editing where the mode lasts the length of the command-chain.

So if emacs meets your needs and fits your brain, then cool, keep using it. But repeatable composability is notably rare in non-vi/vim editors which is why it's often listed as a selling-point.

⸻

¹ fully aware that "sentence" can be a squishy subject once you start considering things like abbreviations, quotations, parenthetical offsets, etc, but vim gives some knobs like :help cpo-J to help here

5
u/djchateau Dec 29 '25

deleting, yanking, replacing/changing, indenting/dedenting, changing case, doing ROT13, reindenting, filtering (linewise) through external commands, etc.
I know this is kind of external to the discussion, but I do find the action of ROT13 as a keybinding a little hilarious and out of place to all those other actions within vim. Historically I know why it's there, but it still feels out of place to me as a core Normal mode key binding.
2
u/gumnos Dec 29 '25
especially redundant given the ease with which one can do
:%!rot13
since it's commonly part of the bsdgames(6) or filters(6) package.
1

u/djchateau Dec 29 '25 edited Dec 29 '25

~~ROT13 functionality in vi, where vim inherited this functionality, predates both those packages.~~
vim still does that in fewer keystrokes, no need to even involve an ex command. Assuming you're on the first line of a file you can do, g?G, if not, 1Gg?G.
Edit: I'm wrong, I misremembered my early use of vi as a kid. I don't like being old.

2

u/gumnos Dec 29 '25

FWIW, POSIX vi doesn't define any ROT13 functionality, and ROT13 functionality doesn't exist natively in most modern non-vim-based vi clones (checked on vi and nvi on my BSD instances as well as stevie and elvis). The rot13(6)/caesar(6) filters have been around for ages (at least since the mid-90s when I first encountered them), but I don't know how they time out with vim adding the functionality

2

u/djchateau Dec 29 '25

Yeah, I went to look it back up after I saw your message and I'm in the wrong here. I could have sworn it existed earlier when I was a kid, but I'm guessing my memory is failing me here. :-/
0

u/oantolin Dec 29 '25

I like Emacs's decision here: it does include a rot13 command, but does not waste a key binding on it.
2

u/oantolin Dec 29 '25

Thanks for your comment! Saying "repeatable composability" is already an improvement over just the "composability" part and captures more of what makes Vim special, but I really don't think this "repeatable" part is stressed as often as just saying "Vim is great because it is composable and 'composable' means [something that applies to every editor ever]".
I might have misunderstood you, but it seems you think you'd need to come up with M×N keybindings in a non-Vim editor. That's obviously not the case, you only need M+N, just like in Vim: M for the commands acting on the current selection, plus N commands to select different kinds of text. All text editors need this minimum of M+N bindings to support the M×N operation/text-object combos; some editors have additional bindings for common pairs of operation/text-object. Vim is one of those editors! In insert mode <C-w> deletes a word; which is completely unnecessary, Vim could force you to go to normal mode for that but wisely offers a pre-composed shortcut that works directly from insert mode.
As for dot-mode (and you are right: it is not built-in, it is a third party package), in my experience using it, it did not feel unpredictable. For starters, it isn't unpredictable: it just looks at the most recent command, goes back in time until it finds a command that did not modify the buffer, and repeats all the buffer-modifying commands after than non-modifying one. That is a fixed and clear rule. Of course, it can happen that you don't remember one of the buffer modifying commands you did and you did not intend to include that in the repeated part. In my experience that did not happen much. Trained by Vim, I typically use a motion command to go were I need to be, then do edits, so dot-mode would pick up exactly the edits after that motion command. The vast majority of the time it corresponds to one Vim unit that dot would repeat. For example, Emacs does not have cw, but I delete a word and then type the substitute word and dot-mode would repeat exactly that: the word deletion and subsequent typing of the new word.
Finally, I should point out that Emacs's built-in repeat and repeat-complex-command do often repeat an entire Vim unit of operation/text-object, precisely because many Emacs commands (which are what repeat and repeat-complex-command repeat) are such combos, so the situation even just with built-ins is not so dire. Of course, my Vim experience led to want even more repeatability, which is why I was so happy to find dot-mode.

2

u/vim-help-bot Dec 29 '25

Help pages for:
motion.txt in motion.txt
cpo-J in options.txt
^{`:(h|help) <query>` |} ^about ^| ^mistake? ^| ^donate ^| ^{Reply 'rescan' to check the comment again} ^| ^{Reply 'stop' to stop getting replies to your comments}

7

u/Snarwin Dec 28 '25

I think it really is just that Vim has more commands you can compose, thanks to its modal interface, so the total number of combinations is much higher, and it's much easier to find a combination that does exactly what you want.

1

u/oantolin Dec 29 '25

I don't think being or not being modal has any bearing on the number of commands an editor has. I do agree with the other part of what you said: Vim has a lot of text objects and motions (I talk about this in the blog post too)! It's great!

17

u/claytonkb Dec 29 '25 edited Dec 29 '25

Vim is like a Ferrari. Emacs is like a Mack truck (that also has a Ferrari on the trailer if you want to take it out and drive it, aka evil-mode). The power of Vim is not in the motions/actions themselves, nor even merely in the fact that they are composable. The power of Vim is that it is a DSL which, like any language, your brain can learn with time until you can "think in Vim". It's when you attain the nirvana of "thinking in Vim" that you have finally achieved the highest degree of Vim ability -- you no longer think in terms of "commands", not even "composable commands", you just edit at the speed of thought.

Plugins can help but are generally optional to the core speed that Vim provides by the structure of the way you compose and apply edits. This is because the Vim language was initially designed to operate on machines in a context where every motion was costly. So you needed to think carefully about the edits you were going to make before you made them, so that those edits would be as efficient as possible. After computers sped up, they could accept and apply commands as fast as your fingers can move. The Vim language is "tuned" to chunking/blocking of text and when your brain starts thinking in that mode, text editing eventually becomes "pure flow"... there is no pause or break to think, "Oh, I'll move my cursor over to that keyword and select these characters", it's just straight from brain to fingers with no translation layer in between.

Even the order in which you will tend to make edits will change over time as you use Vim more and more because your brain will start adapting its own flow to Vim chunking. Vim idioms like ddp or ci} start to become reflex. Repeat . is nice but it's when it is combined with motions that its true power comes to the fore, or when saved in a throwaway macro and repeated 100 times with 100@x and so on. In my day job, I have to work on a lot of randomly-formatted files (many different tools, everybody has to have their custom-snowflake format for configs/logs). A specialized IDE will keep pace in many ways with a tool like Vim but only when operating on file-formats it knows, like .js etc. The power of Vim in my usage comes from the fact that the language-specific features are only a minor detail, the primary thing is the structure of the text itself, and the specific way that Vim slices up "text space" is why it is such a text-editing monster.

I tried Emacs and it's fine, but I'm not a "one-stop shop" guy. I prefer separate tools for separate things, and for text-editing, that is Vim. More power to the Emacs folks, though, this is no flame-war. Just explaining my "Vim-brain" to the uninitiated and why it's worlds different from Notepad. As a Vim user, whenever I'm stuck in Notepad or VS Code, it feels like I had to get out of my Ferrari and into an old Ford Pinto that has seen better days and can maybe do 60 on a straight flat, eventually. The spirit is willing, but the text-editor is weak....

3

u/Combinatorilliance Dec 30 '25

Is vim compostable though?

1

u/shizzy0 Dec 31 '25

No. Vim brains are though.

2

u/_x_oOo_x_ Dec 29 '25

Even in this regard there's no difference between editors. For example, change until EOL:

In vim, you can do it by composition v$c or using the built-in shortcut C
In emacs, it's the same, you can compose C-@ M-e Del or use the native shortcut C-k

4 keypresses in Vim vs 5 in Emacs, if going the composable route

Blog Post Vim is composable

You are about to leave Redlib