FWIW I'm using vim bindings in VS code.
An aside, as another poster noted - Vim's editing keys are the first thing I'd give up for a better Vim. I've tried Vim mode in VS and it's not Vim. Yes, you move with hjkl, but the editing keys and the entire rest of the IDE are two entirely separate worlds. E.g. I can't record a macro that jumps to a symbol definition as part of its execution. In Vim the entire experience is integrated and there is no separation between "editing keys" and "navigation keys", etc. At its core, Vim is a parser for a sequence of keystrokes where each runs a command. Any command can be bound to any keystroke or sequence of keystrokes. The entire system is based on a few basic principles that apply equally across all keystrokes.
Just embedding a Vim editing mode in your IDE is not at all the same as the real thing. It is still better, especially if you need to limit your finger movements due to RSI or other issues, but it doesn't recreate the reason for which I use Vim. To replace Vim, you'll need to do the inverse - rather than have the IDE as a shell and a Vim mode embedded in it, have a Vim interface as the shell and IDE functionality embedded in it.
I don't really feel like I'm too lacking in this department, but maybe the things I do aren't too complex.
https://github.com/sakhnik/nvim-gdb
GDB is also extensible as hell, and I can’t imagine vs code has something gdb doesn’t.
I press F12 in my IDE and I get dropped into a terminal or I can just open XTerm independently... I don't follow how this is a valid argument against IDE's.
I wasn't really providing advice on what the objectively optimal setup (lol) is, I was just explaining how I work. My point was just that vim keybindings are not a very big part of why I like this environment.
I'd like to have some of the refactoring facilities you find in IDEs, but I'd prefer to have them as separate tools, commands you run, rather than moving everything into one window.