To me, the key commands are only half of why I stay on Vim, and the half I'd be most willing to give up. It's as much about living on the command line and 10-15 years of having Unix a ctrl+z or tmux split-pane away.

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.

Out of interest, how do you go about debugging code when you live on the command line? In an editor you have nice features like a visualisation of the call stack, and the ability to set watches and conditional breakpoints. Are there vim equivalents, or do you live without?

FWIW I'm using vim bindings in VS code.

Not OP, but having a good debug log is invaluable. I prefer it to using an IDE debugger. It's rare I need to debug in an IDE, because I can read my logs and see what went wrong and where. Then all I need to do is read the code to find the faulty logic.

Some language environments like Lisp or Smalltalk let you fix the code in the debugger, plus you have inspection tools available.

I just use either gdb's tui, or the new gdb integration in vim 8, along with a few custom pretty printers for types, but you'd have to write those no matter what debugger you used. One difference is that I do not debug in the same editor instance I write code in - it's possible, but I don't like having my editor switching state. It is possibly slightly suboptimal as far as debugger interfaces go, and perhaps using Emacs with its gdb integration would be better, but I haven't felt the need to do so yet. The backtrace, variable values, local variables, thread list, etc. etc. are all there, just not in floating windows, but behind commands you run to call them when you need them. Since it's all text, you can just copy and paste to a temp buffer if you want to take notes. I have never felt limited in my capabilities to debug per se, but a modern reinvention of DDD would be appreciated. Also since everything is text, entering and recording any information is dead simple.

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 imagine you use something like GDB which has different commands to do that stuff. For example quick Google search reveals [this](http://www.it.uc3m.es/pbasanta/asng/course_notes/debugger_co...) for conditional breakpoints (haven't used a command line debugger in forever tho)

Depends on the environment, but a lot of print/exception-based debugging as you'd expect, or use REPLs when they're available. I do a lot of web work currently and occasionally use the debugger in Firefox. I have also used GDB in other contexts.

I don't really feel like I'm too lacking in this department, but maybe the things I do aren't too complex.

It depends on what you're debugging. There are plugins for a variety of languages and if you're a web dev, none of that matters since debugging with the browsers dev tools is pretty comfortable.

I use this plugin for debugging. Works a treat!

https://github.com/sakhnik/nvim-gdb

GDB is also extensible as hell, and I can’t imagine vs code has something gdb doesn’t.

gdb for C, Firefox dev tools for JS, ipdb for Python. The Firefox dev tools are probably the weakest of these, but the other two handle everything you mention just fine.

cgdb is nice too, adds syntax highlighting and vim-like keybindings.

For any Eclipse users here (can't speak to any other IDE), many of Eclipse's features can be invoked headlessly. For a year or so I did most of my Java dev in Vim because I had to work on a remote server, and Eclipse was unusably slow over X11 streaming, but I still had a keybinding that triggered the Eclipse formatter on my open files. I'm sure many other options would work, though I'm sure some just won't. I just used ctags for autocompletion, and I was happy enough with it. Only works if you already have a good idea of what's available, though.

> It's as much about living on the command line and 10-15 years of having Unix a ctrl+z or tmux split-pane away.

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.

Maybe it isn't one.

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.

Vim has really good language server integration via multiple competing plugins (vim-lsp, ale, coc.vim, neovim). You can use the same language servers from VSCode, which give you autocomplete, code-formatting, refactoring, etc.

Not having to leave the terminal and vim's responsiveness are still a big pluses for me.

My experience with language servers in VSCode has been less than stellar (looking at you Golang integration).

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.

I never had much success in setting autocompletion in Vim. Jumping to symbols somewhat works but since the editor itself is not build-aware it always gets thing like include paths wrong. Maybe with editorconfig.json or something it would work better, but in the end I found completion in dedicated IDEs always much better.

Language servers are supposed to mitigate that - they're supposed to be build aware and know all about include paths etc. For the C family this is usually done by having CMake write out a compile_commands.json file as part of its configure step, which is then picked up by the language server. Other languages should have their own methods. I still use build-unaware indexing, i.e. ctags, because it's simpler, faster and lets me look up things that aren't part of the current build configuration without having to switch builds.

> - is trivial to set up (in stark contrast to configuring a untouched Vim/Nvim install from the ground up)

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 ~):

    [email protected]:kerkeslager/dotfiles.git
    cp dotfiles/.* .

This works fine for pretty complicated configurations, but if there's something that can't be configured in a dotfile, I imagine it wouldn't be hard to add a ./configure script that does the rest.

> 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.

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.

I generally find that whenever someone points out that a feature that a plugin implements is already present in vim, the vim native feature has atrocious UX. It feels like a personality thing, it just seems like a lot of vim users don't care very much about decent UX.

Ehh, UX is a pretty vague term.

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.

Vim binds are definitely great but using terminal Vim is more than just the mappings.

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).

other than a notepad replacement, I don't really use Vim.

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.

> 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.

For me it's i3 as a linux desktop wm that uses Vim bindings - really handy.

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?

Vimium is available for Firefox [1]. There are actually quite a few others too: Saka-key, Surfingkeys, Vim-Vixen (as a sibling has mentioned), VVimpulation and, last-but-most-janky, Tridactyl [2]. It'd be remiss of me not to mention Qutebrowser which is a standalone affair.

[1]: https://addons.mozilla.org/en-GB/firefox/addon/vimium-ff/

[2]: I can slag Tridactyl off as I wrote a lot of it. It's still my favourite one.

Thanks so much for working on Tridactyl, it significantly improves my quality of life and saves my wrists! I'll be sure to donate once I have a full time income.

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

General jank that gets on my nerves:

- `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`

- our mini-language is dreadfully inconsistent (e.g. `winopen -private` but also `hint -qb`). Corollary: composite commands steal semi-colons from JavaScript.

- 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.

The best thing about Qutebrowser is that it's not only standalone but also it's 100% controllable via keyboard.

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.

I agree, but I don't really use Tridactyl to replace the mouse - I use it for operations that would otherwise not be easy or possible (e.g. `b` and `B` to search through the titles of open tabs) or a favourite of mine, cloning a repository from Git{Hub,Lab} and opening a terminal in that folder.

Some of this lack of concern for using the cursor is probably because all of the keyboards I use have trackpoints.

And Vimari for Safari!

R# == JetBrains ReSharper, a Visual Studio plugin that adds a ton of functionality.

For firefox I am using https://github.com/ueokande/vim-vixen

I've tried the IntelliJ vim plugin and it was lacking some features that I use regularly (I forget exactly what at the moment. Registers? the 'q:' menu? folds? quite a few plugins I now can't live without? (surround)).

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.

I like this approach and used it for some time but I ended up going in the other direction ultimately and configured neovim to be a customized IDE. The setup isn't for the faint of heart but I find tinkering with it quite relaxing and enjoyable.

I use both vim and vscode, and I find that the vim keybindings in vscode are lacking. I particularly run into problems with substitutions, for example in vim I can do :sno... when I want to change brackets or something whereas that doesn't exist in vscode. I then have to use the native find and replace menu stuff which breaks the flow.

I'm not sure what `:sno` does, but changing brackets e.g. from [this] to (this) is `cs])`.

Unrelated, but do people on HN have a different definition for the word "trivial?" It's used so frequently that I wanted some clarity.

Where I come from, trivial means "of little importance," ex: The Kardashians' drama is frequently over trivial matters.

In a mathematical/academic sense, we usually use 'trivial' for a thing that's 'easily' solved. For instance 'X is a trivial consequence of Y' or 'proof of this is trivial'.

I do the same, however, there's one thing annoying and that is the lack of macros for these ported vim bindings. `norm` command also doesn't work for intellij (along with many other more obscure vim commands)

I tried, but I missed a lot of thinks like being able to click a random line instead of down down down down. Or selections. Commands are good but I pretty much just use find and replace in vim.

You don't have to click down multiple times. If you want to go somewhere specific there are too many ways to list tbh but they're all faster than arrow keys or mouse clicks. I'm a big fan of the EasyMotion https://github.com/easymotion/vim-easymotion approach myself but the built-in search functionality + tag navigation is also good.

It's also a great way to learn Vim in the first place. One motion at a time, without getting stuck when you can't recall it, or slowed down when you're in the flow.

I completely agree. I still keep vim nearby, as it’s everywhere, fast on large data files, and has some power tools for editing plain text that «code editors» just don’t have.

Same here, but IJ does sometimes fubar when updating VIM :(