Interesting viewpoint, but aren't there enough differences between programing languages to warrant mapping these concepts slightly? Clearly my Emacs origins sh

Interesting viewpoint, but aren't there enough differences between programing languages to warrant mapping these concepts slightly? Clearly my Emacs origins show here, because not having simple built-in motions to select "a function" or "a class" feels like a big limitation to me. I actually have a bunch of ad-hoc bindings for that. I also seldom use paragraph motion while coding simply because it doesn't really make a lot of sense to me. I think about code in lines or blocks, not paragraphs that is a rather weird concept when it comes to code. The fact that you can't easily add new motions to vim is a big limitation for me. >Vim feels like a complete set of high quality, manual woodworking tools. They're mostly reliable and predictable, I agree with that. High quality I'm not sure. The fact that the undo tree is effectively unusable without 3rd party plugin is weird. Tabs are at the same time over-engineered and under-featured. Nobody seems to really knows what they're for or how to use them (just make a quick search online for "vim tabs"). They're like Emacs frames except that you can't actually use them like a separate frame on a different screen. And you can't have them use a different working directories easily so they're useless to open two projects side-by-side. Some people coming from editors that open files in individual tab (an anti-pattern IMO, but that's a different discussion) expect them to work that way, but it turns out that they can't really do that either. Why even bother? You also need plugins to do very basic coding stuff like run "make" in the background without being locked out of editing. Which wouldn't be too bad if Vim's internal API made it easy to make Vim plugins work seamlessly like native code, but in practice all the plugins have tested needed to be super intrusive to offer basic functionality (like remapping literally half the keyboard to slightly tweak the kill/yank behavior) and it ends up breaking left and right in weird and unexpected ways. The visual feedback for commands is atrocious. Spacemacs' genius is that when you start typing commands it shows you what you can press next and what it does. You effectively navigate the bindings like menus, and you have this positive feedback loop where you memorize the bindings by using them. Sometimes I start typing a command in vim and I think I made a typo but I can't know because I have zero feedback on the current state of vim. Emacs almost always tells you what it's waiting for in the mode-line. Why does ":bdelete" also kill the window it's in, except when there's only one window left? Since elsewhere there's no 1:1 relation between windows and buffers, you'd expect to get the next buffer in the stack (that's what Emacs does in this situation, and that's what Vim does when you have one window left). Window and buffer handling is hard but Emacs is vastly more configurable and works better out of the box in my experience. I also often get performance issues that I don't remember ever getting in Emacs which is fairly ironic given that Vim is supposed to be the "lean" one.