Having tried out Kakoune multiple times, I agree with the author. Especially the part about how it eats up keys and requires more modifiers. > With fundamental

Having tried out Kakoune multiple times, I agree with the author. Especially the part about how it eats up keys and requires more modifiers. > With fundamental errors like this it's no wonder design improvements are rejected by the author Except the author isn't rejecting the Kakoune model in its entirety. Nor is the argument based solely on the two sentences you quoted. As with all things, there are pros and cons. For some, the pros outweigh the cons. For others, the cons are a dealbreaker. Also, the examples you brought up are kind of extreme and doesn't point out a "fundamental error" in the author's reasoning. The part you quoted refers to the most common cases, indicated by the use of the word "often." And some of those edge cases can easily be mitigated. For instance, > you can have a long sentence that wraps multiple lines If a sentence is too long, you'd most certainly know before you try to edit it. So Vimmers would press "vas" if they require visual feedback. > includes quotes and maybe code snippets with . inside them or just ..., so you can't easily tell where a sentence begins and where it ends. This becomes obvious once you learn how Vim defines a sentence. It's not too hard a definition. https://vimhelp.org/motion.txt.html#sentence https://vimhelp.org/motion.txt.html#sentence > a valid function name is a single word even if it contains a comma in its name, so you have to keep in mind scope to guess correctly what a word motion will select Syntax highlighting should already provide a visual indicator in this case. If there's a mismatch, that's likely a bug.