You don't have to make that choice and can have "the best of both worlds": For the last few years I've not been using Vim itself, but Vim bindings in VSCode and Intellj. I enjoy the trade-off of this this approach because it
- is trivial to set up (in stark contrast to configuring a untouched Vim/Nvim install from the ground up)
- gives me simple access to powerful extensions
- allows me to use modern editor/IDE features (find usage, refactor) without forgoing "the essence of Vim", rapid code editing through the combination of motions & commands
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.
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.
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.
Not having to leave the terminal and vim's responsiveness are still a big pluses for me.
I just haven't found anything as responsive as IntelliJ's custom embedded autocomplete/code-formatting/refactoring capabilities yet... everything else is just inferior feeling.
1. Part of the joy of vim is not configuring it. A ton of the plugins out there exist because the creators didn't know that a feature already existed in vim, and many of them break existing keybindings. Beyond a few small configurations, I use vim as my daily editor largely untouched. A big upside to this is that I can log on to almost any server and have an editor that is pretty close to what I use anyway.
2. My configuration process is (assume you're in ~):
cp dotfiles/.* .
Maybe for sysadmins that are always doing a ton of text editing on remote servers, but I haven't run into this. Even when I do work on servers though I don't have any problems using vanilla VIM even though my workstation has 70 plugins. I do take care not to override any of the base keybindings though. If you are overriding core bindings you deserve what you get hehe.
If you're talking about traditional UX values like intuitiveness, sure, vim UX is terrible.
But vim features tend to do very simple things, which are composable into very powerful mini programs in a lot of contexts. There's a sort of "discoverability" to them as well, in that if a key does something in one mode, it likely does something intuitively similar in another mode. All this adds up over time. I've got about 9 years using vim every day now, and the combined learning over that time has added up in a way that disposable learning like "how to use the X flavor-of-the-week plugin" would not have.
Another thing here is that the UX improvement of most plugins is only surface-level. vim features tend to be very simple, which means that when you understand it, you understand it. But vim users with a lot of plugins rarely understand what is actually going on when they use a plugin feature, because the features do too much. This means that they can't really use those features in, for example, macros, which loses you a lot of the editor's power.
Everyone uses Vim differently but I tend to combo it with tmux. For example I often have 8+ active tmux sessions (1 for each freelance contract I'm working on + personal stuff). Each tmux session has 1 or more Vim instances running, so switching between each session is 1 key stroke away. It's effortless to jump between them and the state of those sessions are always around (even persisting across reboots with tmux-resurrect). It also takes up close to no resources (a few megabytes per Vim instance).
But I do use VsVim in Visual Studio and also have a guide on how to do that with R#, I use Vim emulation in all the Jetbrains products as it's really well done, also in VSCode, Vimium in all my browsers. Also use AutoHotKey to add Vimish type navigation to windows controls.
I attempted to create something like this some years ago: https://github.com/mihaifm/vim.ahk
It's pretty difficult, applications have vastly different behaviour even in regard to simple commands. Still, it was a fun experiment.
Agree on Vimium in Chrome - I have to check whether it's available on Firefox.
I've never heard of R# (and it's hard to Google) - what is it?
: I can slag Tridactyl off as I wrote a lot of it. It's still my favourite one.
Why do you say it's janky? I love it and it feels pretty polished!
The only issue I have is when selecting the HN upvote/downvote arrow links with 'f' the letter hints overlap :D
- `gi` doesn't work reliably on enough pages for it to be useful, ditto for `g;`.
- we outright break a handful of websites unless you `seturl [url] noiframe true`
- most importantly, entering stuff into the command line is not a pleasant experience compared to our competitors due to lag and various things that block input but shouldn't (this is worse on Windows and generally gets worse the bigger and older your Firefox profile is)
I still like it, though. I'm glad you do too!
For your problem, I'd suggest making site specific binds: e.g. `bindurl news.ycombinator.com ;u hint -Jc [title="upvote"]` and, as a guess, `bindurl news.ycombinator.com ;d hint -Jc [title="downvote"]`, but I'm not cool enough to have downvote buttons so I don't actually know if that last one will work.
This is simply not possible with other browsers where the UI outside the actual website was only designed with a mouse cursor in mind. And that contradicts the idea of not constantly needing to switch to the mouse and back.
Some of this lack of concern for using the cursor is probably because all of the keyboards I use have trackpoints.
Another key thing is the responsiveness. Vim is just more responsive (or it feels that way to me, you may have different experiences).
I am developing Java using vim + tmux at work and it for certain took a lot of time to get tweaked how I want it to be, and there are some things I've had to give up: debugging is a big one (but that's what log messages are for!), but I 've managed to cover quite some ground:
I wrote a plugin to automatically add import statements based on dependencies you have listed in your build.gradle
Yeah I know the image (ooo that guy thinks he's sooo l33t because he uses vim and the command-line all the time... doesn't even need intellij installed!), but I know my setup works for me and it allows me to work as fast, if not faster than my peers and get. crap. done.
To each their own - I make sure that new engineers I'm on-boarding have tools they need to get work done and don't fall prey to some tool-cult.
Where I come from, trivial means "of little importance," ex: The Kardashians' drama is frequently over trivial matters.