[galkk]

I don't feel that we thinking about it differntly. It is that editing source code is much more than just editing text. And vim severely lacking as an IDE.

We don't need to associate motion style navigating and separation of command and insertion modes as something very vim specific. It is that vim is installed on every machine that I work on in like 99% of cases, and it made sense to me to learn something that is always available. But the shortcomings are very clear.

I can give an analogy of gdb. I feel that anyone who says that text mode gdb is anywhere near convenience that you get using modern IDE is suffering from stockholm syndrome. Yes, obviously it is more powerful in some circumstances, but for day to day use it is just plain inconvenient.

And that's why I said in my first post - I settle on vim as text editor, but I gave up trying to set it as an IDE, so I will never code in it, unless I'm forced to (who knows, weird job that requires vim use etc). Life is too short for that amount of tinkering.

[Asooka]

Text mode GDB is very clunky, but it is better than any frontend I have tried. Whatever pain points it has, I can mostly work around with scripts, which isn't possible with a GUI. The worst part is that it's awfully slow for programs with a plugin architecture. If I set a pending breakpoint before starting the program, I can wait ten minutes until all plugins are loaded. I really wish I could tell it to preload some debug information at the start.