Is the article true? That because emacs' editing functions do not have separate functions for operators(delte, copy etc) and motions(move to end of word etc), vim's composability cannot be perfectly implemented in emacs, atom etc?

https://medium.com/@mkozlows/why-atom-cant-replace-vim-433852f4b4d1 But can't we just write new functions in elisp which make it possible to have functions which only do the movements or operators and then combine them as in vim completely ignoring the emacs editing commands like "kill-region" etc? I guess evil already does this. But since this kind of "feature" is not built into emacs as such, does this cause an inherent limitation or difficulty?

>But now let’s look at delete commands. Let’s say you want to delete a word, delete to the end of the line, delete to the end of the file, or delete to the end of a paragraph. > >Emacs only has two of these functions: kill-word and kill-line. Perhaps I am nitpicking, but this is not true. There is `kill-paragraph`. It doesn’t have a default keybinding though, so it’s up to the user to decide if it’s important enough to give it one. And while there is no "kill-to-end-of-buffer" command, there is a `mark-end-of-buffer` command. So if that’s something you do frequently, you can give that a keybinding as well, then simply call that command and press "C-w" to kill the region you just created. And in the rare instance that there’s not even a command to create a region, you can create one manually by pressing "C-SPC" and then moving point. (Or my favorite, pressing "C-M-SPC" until the area I want has been selected.) And if you want to implement Vim-style editing, the built-in thingatpt.el library makes it possible to work on text objects, rather than rearranging the point and mark. Of course it’s a topic that’s been beaten to the ground. But it really depends on preference. Some people love modal editing. Some people don’t. As far "composability", Emacs's commands are composable too, just not in the same rigid manner as Vim. But you can change that if you like. It's as composable as you want it to be.

Good analysis but my question is that, is there anything in emacs lisp or framework that prevents implementation of vim properly wihtout constraints? Like to create functions for movements of cursor upto word, sentence, paragraph etc and then combining them with functions for operators such as delete, copy, mark, indent, upper case, fold etc. > operator + motion

It seems you are asking for some further clarification but not explaining what you want clarified. > Like to create functions for movements of cursor upto word, sentence, paragraph etc and then combining them with functions for operators such as delete, copy, mark, indent, upper case, fold etc. You already mentioned evil-mode in the original post. That is exactly what evil-mode and many other packages already do. EDIT: > But since this kind of "feature" is not built into emacs as such, does this cause an inherent limitation or difficulty? Maybe I glossed over the question, because I'm not sure what kind of limitation or difficulty you might be referring to. Note that Emacs itself is primarily made up of "packages" written in Elisp. That's where most of its functionality comes from. So when you install an external package in Emacs, it has the same capabilities to alter the way the program works as any of the built-in packages. But again, I don't think we're really talking about altering it in a significant way. You give it input in the form of keypresses. It gives you output in the form of alterations to your text.

All that is present in evil-mode which is pretty much supporting everything vim has regarding editing.

I'd say the article is way off. That "composability" stuff only means that you separate each text editing operation into two parts: one part is to specify the text you want to act on, and the other part is to specify the editing operation. Every single text editor I've ever used allows that separation, usually specifying the text you want to act on is done first, with "selection" commands, and the operation is specified later. (This order is like Vim's visual mode, not like its normal mode.) Seriously, even notepad: I can use the single backspace command to delete text no matter how I selected it, whether by shifted arrow keys, double clicking a word, triple clicking a line, highlighting with the mouse, etc. Emacs definitely allows you do things in the Vim (visual mode) style too if you want to, and comes with lots of marking commands to specify what text you want to act on. But while Vim's default key bindings more or less force you to (almost) always separate each edit into selection and operation steps, Emacs also comes with many convenient shortcut commands that combine both into a single step. For example, to delete a word you can use the "composable" approach of mark-word kill-region (M-@ C-w), or you can use the kill-word command which combines the two steps into one. If you prefer Vim's two-step method, feel free to use it in Emacs. And for very common combinations, you can gradually learn the one-step commands available to be even faster. Notice that in Vim too nothing stops you from making your own mappings that combine selection and operation into a single step. Indeed it even comes with a few out of the box. For example, C-w deletes the previous word in insert mode. So, in saying every editor has this much lauded composability am I saying Vim is no better than notepad? Not at all, Vim is a fantastic editor, but it's not composability that makes it so (and it couldn't be since that is the basic design of virtually all text editors), rather what makes it special is its *selection* of motion, text object and editing commands. Here's a thought experiment: start removing text objects, motion commands and operations from Vim until you wind up with only things that have a direct equivalent in notepad; in this thought experiment the impoverished Vim is still composable and still has a grammar but it sucks because it's missing all the cool vocabulary that Vim has.

Vim composes the operations you describe as a single command, rather than two or more disparate commands, and that I would argue is what makes Vim's composability inherently more powerful than Notepad's, regardless of the size of the respective vocabularies. The real power of Vim comes into play with the dot command. Emacs has its own version of the dot command too, at C-x z, but due to the nature of the beast this is used more as a temporary rebinding of a command (that possibly had a long or awkward binding), whereas in Vim it's more like an automatic temporary macro. As an example, if I wanted to replace a word with "foo" in Vim, I could move the point to somewhere in the word, and then do `c i w f o o ESC`. Because this is a single command, I can then navigate to another word, press `.` and voilà, that word is also replaced by "foo". Or if I wanted to insert a semicolon at the end of a line I can do `A ; ESC`, and again I can navigate to another line, press the dot key, and that line too has a semicolon at the end. Trivial examples, but hopefully you can appreciate the convenience this provides.

The problem with text objects is you have to count them to be able to operate on multiple ones, which adds cognitive load. Packages like `avy` allow you to navigate in 2-3 keypresses anywhere on the screen (as a bonus, you don't need to enable line numbering) without extra thinking.

You don't have to count, you can just use avy with text objects like you do with motions. This isn't builtin for Vim or Emacs (though neither is avy), but you can do something like `dird` to delete inside any delimeter pair on screen ("delete inside remote delimiter"). Or something like `dirs` to remotely delete inside a sexp or string. Or `darf` to remotely delete a function.

You make an excellent point, which I almost mentioned but decided my comment was long enough. Two things about it though: First, inexplicably Vim bloggers tend not to mention this, and write blog posts that say "composability is great: no other editor let's you separately decide what text to act on and what action to perform!" without mentioning the vocabulary size nor the dot command. It makes me wonder if they have ever used any other text editor and also, if not, what they imagine other text editors do. It's very weird. That point was not about Vim, nor even about Vim *users*, but about Vim *bloggers*. But there is also something about the dot command in and of it itself that sometimes bothers me. Obviously dot is great and the usage pattern where you search for something, make a single edit and then use `n` and `. ` to make the same edit in other places is fantastic. What sometimes bothers me is that I have to stop to think, "can I really not do this in a single edit?". (Maybe I'm just a bit obsessive.) And you sometimes think of somewhat barroque solutions like going into insert mode, deleting stuff there, and pasting with `<C-r>` just so it is a single edit. I should have probably developed the habit of recording a macros as soon as I paused to think for half a second instead. There's a great package called dot-mode for Emacs which takes care of that (admittedly minor) annoyance. What it does is automatically make a keyboard macro out of the last consecutive stretch of buffer-modifying commands. It's great and I wish that were what dot did in Vim because you don't have to stop to think how to micro-optimize nearly as much. Maybe that issue with vim's dot is just me and if either I were better at doing things in a single edit or cared less about doing so, I wouldn't be troubled by it. But I really do find the dot-mode package more comfortable and it has really cut back on the number of times I have to bust out the big gun: macro recording.

> You don't have to count Vim/Evil users do, though (just check how many of them have line numbering enabled) > This isn't builtin I have an Internet connection > dird/dirs/dirs the problem is these aren't obvious neither unambiguous

> Vim/Evil users do, though (just check how many of them have line numbering enabled) No, I don't. > the problem is these aren't obvious neither unambiguous What do you mean?

I really like your comment, I think it really touches on something more concrete than the usual vi advocacy. There seems to be a kind of weird addiction in Vim usage, where users can be faced with an editing situation, solve the little logic puzzle to figure out the keypress sequence that does it, you type it and *flash* the screen gets updated and the result is exactly what you wanted, *woohoo!* And like you point out, if you solve it right, there is even an extended jackpot phase as you get to use the dot command to "clear the level" with your trick. The thing is that I find that most of my editing is just typing shit, and the few cases where I have a semi-repetitive task I often just manually repeat the Emacs sequence because it is ever so slightly less mentally burdensome than recording exactly the right keyboard macro or rolling an elisp command. For a while I made myself a post-it to remember the keyboard macro recording commands but I lost it a couple office moves ago. Anyhow, I feel like I use Emacs more for things like Emacsclient giving me persistent remote access to my multiple shell buffers, and dired to navigate my directories, and for a while org-mode to organize my work notes and TODO list. Which is less exciting than a text editing video game, but also highly functional.

Here's the thing. It is almost certainly possible to burn an Emacs implementation down to the ground and rebuild it as a Vi implementation. But at the end of that, you are left with a bare equivalent of Vi and you probably have to do even more work to try to build an extension mechanism like the one modern vi implementations have. Why do that? If you really want a good vi implementation, go find one. (Emacs has at least two vi implementations, but I don't know if they could be called "really good.") Emacs users tend to use some additional functions like dired or shell buffers or org-mode or Gnus or whatever, and those packages tend to be designed to work in ways that don't match to the modal editing "composability" fetish, so how does that radical vi rebuilding help?

> vim = "Text editing video game" Nice one lol.

You've made this argument before, but not many Vim users "count things" to edit in my experience. The only time I enable line numbers is when presenting something to an audience. I certainly don't think "Emacsers M-x everything!" because a few inexperienced users don't know every binding.

Disclaimer: I used vi for like a 3 month period decades ago, but I'm interested if actual vi veterans can agree that the psychic rewards of vi might be similar to a video game.

Vim actually makes for a very fun and addictive video game if you ask me. Try playing [The Viminator](https://www.theviminator.com/).

> because a few inexperienced users don't know every binding. nobody knows every binding > but not many Vim users "count things" to edit in my experience do they use `d2w`, `3k` and stuff like that?

> do they use d2w, 3k and stuff like that? In the same way a numeric arg can be passed to many Emacs commands. It's not as frequent or as burdensome as you think it is.

> It's not as frequent or as burdensome as you think it is. I used to use Vim for some years in the past, I'd say it's definitely burdensome.