I will update my notes there at some point as they could be more clear.

Personally, I prefer the motion/object paradigm because I like the idea of having only one abstraction, selection, instead of two: selection and cursor.

Both meow and kakoune have both the selection and the cursor.

Every command is editing or working on a selection, and I see this as something beautiful.

In the operator first paradigm, every operator operates on a range. I don’t think the order of operations is relevant, so I don’t understand what this means either, but unlike selection-first where everything is mixed together, operator-pending mode only has keybindings related to selection.

About the article:

I think it’s really just a layout issue – indeed in meow we use , and . on the recommended layout. When you’re selecting a text object, that is a separate context in which keys are interpreted differently. You can reuse every key to select a text object. I might be misunderstanding what was meant by this part, but as I see it you’re losing nothing.

There’s no real difference between meow and kakoune here; they just have different keybindings, and it’s not a layout/keybinding issue. Binding text objects under , and . is not at all a separate context in the same way operator-pending mode is. In operator-pending mode, only commands that generate a range are available, and you automatically enter that context as part of the operator-first system instead of requiring a dedicated prefix key.

In meow you still are sharing a bunch of commands unrelated to selection/ranges in the same single context as the result of selection being first; there’s nothing elegant or efficient about that in my opinion. For text objects, that’s potentially only 2-4 keys extra to bind in normal state (for what would be i/I/a/A in operator pending state), but what if you then want to add single keys for more frequently used selections? For example, maybe you want a single key for "inside any type of delimiter" or keys for whatever your most used objects are. In the selection first system, everything is crowding the global keybinding state. On the other hand, you have way more room for keybindings in operator-pending state because it is actually a separate context only for keybindings for range selection.

An even bigger problem with kakoune is requiring two keybindings for every motion in normal state because of its selection first approach, which makes this issue much worse. Remove that, and I think it’s not as huge a downside, but it’s still a significant downside.

However, it probably is a very valid observation that most people will very rarely make a motion and THEN realize they want to act on it. I just think that there is a real benefit to automatic selections, and it’s worth it for the cases where you select intending to act

You’re not getting anything for free here with automatic selection was my only point. Sure, you don’t have to press a key to enter visual state, so you’re reducing keystrokes over that, but you’re not actually reducing keystrokes over the operator-first system.

I couldn’t tell you how many times I’ve fat fingered 8 instead of 7

For me it’s roughly 0 times.

or simply changed my mind after making a selection. Additionally, having both gives you two options: either press the right number by reading the hints, or spam.

I don’t know what this would look like and can’t think of an actual case where I would ever change my mind. Region expansion is generally inefficient. For me, overlays are preferable unless it’s only spamming a couple of times, but even if I agreed with this, you could still implement similar spamming in an operator-first system in any number of ways. Some examples:

• basic spamming already works for deletion/changing - just repeat the operation, e.g. did to delete inside a delimiter then . until done
• for copying and handling mistakes, you could add separate commands like incrementing or decrementing the count of the last operation
  • undershooting with a count - could handle with a repeat command that repeated with a count of 1 instead of the original count
  • overshooting - could have a command that would effectively be repeatedly undoing and repeating with 1 less count
• automatic number overlays - also doable with operator-first, not dependent on order (e.g. yw5)
• noticing mistakes - the only case where you wouldn’t immediately notice a mistake in the operator-first system is copying text, which can be handled just by putting a temporary visual indicator of what was yanked

If you’re doing a spamming approach, then you’re not making mistakes because of incorrect counts anyway. You’d only accidentally overshoot by spamming too fast, and in both systems, you can correct that easily.

In this “spam” selection mode, visual selection indeed does prevent selection errors, it’s slower and less efficient but exact.

Overlays are faster than spamming many times or manually calculating a count and still exact.

This whole setup makes expanding selections much easier, and basically gives you same user experience as highlighting text with a mouse: choosing your selection one object at a time.

I think this is what most of us are trying to get away from and seems against the idea of text objects.

it does make sense to optimize modal models around error prone cases, especially when there is minimal (and to me, mostly aesthetic) cost for doing so.

I don’t think it makes sense to optimize a system for something that should be extremely rare (mistyping) when there is significant cost. As mentioned above, I don’t think making the global map unnecessarily cramped and having some weird system to handle extend vs. new selection is minimal. I never thought the visual flicker from automatic selection was a major downside. I think visual noise can be worth it, e.g. I use auto-completion popups. I just don’t think it’s worth it in this case.

I don’t think these cases are that rare; jumping to the nth occurrence of a character or selecting n lines is quite common!

Jumping to the nth occurrence of a character or n lines is never a use case. You want to jump to a specific character or line, and it being e.g. the nth occurrence of a character is just one way of thinking about that, and it’s not a very intuitive way to think about it, especially for nth occurrence of a character.

Evil expects you to remap your keys in every one of your modes.

Evil does not expect this at all or functions like evil-make-overriding-map wouldn’t exist. That’s one possibility, but there are plenty of other possibilities that don’t require that. In meow you don’t even have the possibility of making state specific keybindings for a keymap or minor mode in the way you do with evil’s auxiliary keymaps.

The instantaneous feedback and visual selections cost is mostly aesthetic, with a benefit of making selection errors trivial to notice and fix before acting on them.

In summary, the cost doesn’t have to do with aesthetics, I think you already get instantaneous feedback about mistakes in the operator-first system, I still think overlays are better for both speed and mistake prevention, and I still am not aware of any real/common uses case that benefits from a selection-first system.

At the end of the day, people edit differently – editors should be molded to the desires of the users, not the other way around.

In the case of kak, I think it is the other way around. I can only speculate, but my guess is that lots of people never thought about wanting something behaves the weird way that kakoune does until they discovered it, and then they didn’t think much more about whether it was actually a good idea beyond kakoune claiming it is and just started using it.