Years of interviewing people for my own teams has shown me that understanding your tools (especially to the point of being opinionated about them) is probably the #1 indicator of success.

I frequently describe Spacemacs as a better vim than vim. Don't get me wrong, I've used vim for ages; I'll never stop editing server config with vi, nor will I stop getting mad when vi is actually vi and not vim.

But for a day to day code editor? Spacemacs is astonishingly good.

(Of course, Spacemacs is built on top of EVIL, as well as dozens of other packages. On the shoulders of giants, as we say.)

Personally I’ll sometimes use VSCode to browse big files or explore the codebase, but when it comes to editing them neovim with coc, fzf and a language pack is all you need.

Exactly my thoughts, you need vim and emacs these days if you want to munge through large amounts of text. The thing is in these days of Kibana and Elastic search. You don't do much of this kind of work anymore.

Code is text. But it's not that kind of text where you need your fingers and macros to do much work. Your tool needs to be at least to some extent aware and intelligent of code you are working with, or you end up doing too much work for nothing. If your language doesn't have this kind of tooling and you wish to maintain your application for long, you need to use a better commonly used language.

Much of the vim macro work I could put to use is done by black these days. If you are writing too much repeated code, you need to learn to write reusable code. Navigation is one more of those things which could improve if you use intellisense.

Bulk of modern day dev work requires working with 2 - 3 tech stacks. The use case for vim, which is writing few key stroke in one attempt to transmit them over super slow internet connections, doesn't exist anymore.

What IDE features do you think vim is missing that aren’t available via LSP plugins?

This is coming from someone who lives in vim for his daily work, likes it, but always finds annoying sharp edges that are hard to reason about and script away.

I don't know where I saw it, but the idea that "Code exists to be read" really resonates with me. I don't care how fast I can crank out code. I care about how efficiently I can hop around from place to place to grok what is going on and how it needs to change.

The killer feature of vim that I feel like very few people know about is it's remote editor feature.

Launch a long lived instance of vim with a `servername` set, for example I do: `vim --servername EDITOR`

Then set up a application shortcut that will open the file using the prefix `vim --servername EDITOR --remote <file>`

When you open a file, it gets opened in your single vim instance.

From there you can navigate between all your open files using `:b <file-tab-complete>`

It's really a joy to use. You don't have the mess of tabs where you run out of space super fast, you just have a bunch of open files that you can switch between super easily by name.

Then observe yourself doing stuff and whenever you think "there must be a better way to do X", find out and learn how to do just that. (You would ideally have a cheatsheet on your desk for quick reference. If it's not on there, search the internet.)

At this point, it also helps to know about the basic grammar of normal-mode commands: motions as subjects, commands as verbs. Full sentences are either only-motion, command-motion, count-command-motion or command-count-motion. So if you have already learned that "dw" deletes a word, you immediately know that "d2w" or "2dw" deletes two words.

There's not much more to it. Just do your actual text editing and if you ever find yourself thinking "there must be a better way to do this", that's another learning opportunity.

It's a lot like language learning, really. You can plow through 10,000 vocabulary words in your SRS if you want, but nothing beats actually using the language.

https://github.com/TheNaoX/vimtutor/blob/master/vimtutor

It's a great start.

Personally, I find most modern IDE features are overrated and not necessary for productivity. For example, context-aware autocompletion is not necessary -- simple autocompletion based on things you've recently typed or that are open already in another buffer covers at least 90% of autocompletions I need. For the rest, I just have to type it out myself once, and now it is remembered too.

The same is true for browsing a file tree of your project, using syntax linters or reformatters, etc -- all of these are pretty straightfoward to setup in vim or emacs.

It can get a little tricker when dealing with breakpoint debugging, though. But in those cases, I just open in another IDE anyway that has extensive profiling tools, which vim does not have. But that's maybe once a week at most.

This helped me back in the day: http://yannesposito.com/Scratch/en/blog/Learn-Vim-Progressiv...

*) US, not UK. UK QWERTY is trash.

https://github.com/andmarti1424/sc-im

This gave me a bit of a chuckle since any modern serious C++ work is really a different language since 2011. Most of the C++ prior to that are considered anti-patterns now. It's hard moving at a glacial pace; the language gets major evolutions every 3 years.

I’ve never used vim, mind sharing what it’s weaknesses are?

I do not use Vim as a daily driver at all, but I have to use it sometimes because I have no other choice (remoted in to a box). So if I had to say which editors I used, Vim would be there... sometimes.

For my part, when I answered the survey, I checked vscode, intellij, vim, jupyter, emacs, and rstudio. Most of those are there because they're my preferred editor for some task or other, but vim is only there because it's the only editor I can expect to have available on every server I ssh into. So, while I did say that I use vim in the survey, I would encourage you not to count me as a vim user for the purposes of any popularity debates.

> Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that."

If company policy is that "we use X", then probably you're not going to have many people stray from that. The bigger the organization, the more likely you are to have strict guidelines in place like that.

I would guess people on Windows are also less likely to reach for Vim than any of the many other alternatives. If you're using Linux, you probably have a different view on the world to begin with, and are more likely to go with vim over whatever is the "new hot editor". I've heard Mac users like to reach for XCode, but I don't actually know many developers outside of work, and none of them use Macs, so I don't know.

But hjkl I need even in my webbrowser. (In Thunderbird I've send many mails to junk by accident.)

How is that these days? I used it a couple of years ago but it had issues at the time, namely some performance problems and getting stuck in a particular mode.

I ended up abandoning vim bindings because the JetBrains plugin was also buggy, and I straight up had no feasible way to get those bindings in Xcode, but I hold out hope for a glorious LSP-based future where I can just use vim and get all the benefits of my other editors.

Do you know who would likely "compromise a project"? The junior dev that is unable to stray outside their IDE when getting things done.

Line debugging becomes less and less valuable as you become more mature in you dev career. Sometimes you have a race condition bug, some times the target architecture just doesn't provide it (devkitpro/devkitarm or embedded) and sometimes bugs that are evident in production just cannot be replicated in your debugging environment.

In my experience it is more valuable to improve skills of building mental models of the system at hand, get effective with console logging for key info and troubleshoot issues that way.

1. Read the logs.

2. Read the code that produced the logs.

The ones I can't do directly, I can do via Search/Replace functionality that is also standard in most modern editors.

Your example about refactoring a function by using text editing capabilities is actually pretty bad unless you mean Vim can actually parse your programming language and perform the refactoring over all your code-base (not just a single file), like any IDE will do.

This list you gave me just convinced me I don't need Vim.

vscode has regex find replace, but I don’t use it very often. It does show every match highlighted in the current file while entering the find value, which is nice.

It does the same for multi files if needed and gives a nice preview of every change.

Word navigation I use a great deal (especially with multi-cursor editing). Ctrl+left/right jumps words, home, end to begin end of line.

Ctrl+f Z Enter would go to next Z value. (Which I don’t use, because I don’t think in partial words much, but rather jump to mouse if I need to navigate far)

That’s probably where I could gain in using that instead of going to the mouse every time.

How often do you really do things like this though? It seems like, sure you can do weird obscure things quicker in Vim, but only if you happen to remember how do to the weird obscure things, and it's only useful in weird obscure situations.

For 99% of tasks the built-in VSCode stuff does the job for me. Ctrl-D especially.

The way I would do that in vscode would be with a multi-edit, but it would get iffy at that many lines.

I‘ll record a video doing the same for comparison tomorrow.

This makes me wish there was a site for recording challenges like this where developers could race using their favorite tools.

Vim vs VScode would be an amazing way to learn tips from experts on both sides.

Just thinking out loud how to do that in vscode for comparison:

- I don’t think repeating actions a specific number of times makes sense in most use cases. Counting 10 lines would take longer than doing shift up/down n times (which would be exact with feedback) to select the desired lines.

- Multiple Copy Paste buffers sounds interesting, I might look up a vscode extension for that. (Had a copy paste queue in Visual Studio but it would break sometimes and would lose something important).

- go to start of function jnk, there are many ways to do that in vscode. Ctrl+f jnk enter would be one.

- Goto start of document is Ctrl+Home

- Indent 20 lines by 10 spaces, could do Alt+PageDown, then up/down to get to the right place (without counting or caring that it is exactly 20 lines), then with multi-line insertions could space,tab, etc.

That operation would probably justify mouse usage though, in which you simply hold alt, drag ~20 columns/~10 cells and hit space - which itself would be faster than counting 20 lines.

- find junk: ctrl+f junk enter

- select 15 lines (shift+page down,up/down to adjust) I can preview I have selected the correct area, other possibilities to select current function, etc.

- Ctrl+h to replace, a1 tab A1 Alt+L Enter

- of course in most cases, I am renaming a symbol, so “F2 A 1 Enter“ would do

I think the reality is that counts are not known before hand, so being able to increment/decrement with visual feedback is perhaps faster than a miscount, but I’d have to see it to know.

Anyway, thanks for the detailed examples! I can certainly see how it would be powerful if committed to muscle memory, but even with vscode there are many shortcuts I don’t use because of formed habits.

Nit pick: "q selects register q. A buffer is a different thing.

The real scenario is usually to replace, for example, in a function block. How do you do that? Counting function lines seems like a non-starter.

For example, let’s say I have a json object with variety of field names, one per line and I want to remove the quotes.

With vscode, I can alt select all lines, Home Ctrl+right del cntl+right del.

The trick is the field names are different length, does vim have multi-edit with the ability to navigate relative to each insertion point?

Edit: Here is a good video example (https://youtu.be/iomWEDMBlcE)

Can vim do something like that?

    V<count>j (3)
    :'<,'>norm A, (8 - The angular brackets are automatically added by vim)

    qq (2)
    A,<ESC> (3)
    q (1)
    V<count>j (3)
    <CTRL><Space> (2)

It even supports using a mouse over ssh.

I don’t know SyncTex so can’t comment on that.

Why would one be suitable for programming but not the other?

It just comes down to UI preference and whether you want to configure things yourself or not.

Both support plugins, so the possibilities are basically endless

These are vital features from my perspective, but completely orthogonal to whether an editor has a post 1980s interface.

And it's also nice to be able to handle large files.

I occasionally use a count (5j to move 5 lines down, especially good for moving ~4 lines at a time), sometimes use C-u/d, C-f/b, or H/L to scroll half a page up/down, a full page up/down, or move the cursor to the Highest/Lowest line on the screen (these are good for large movement. And you can use zz to recenter the cursor on the screen after H/L). But likely the most common vertical movement I use is curly brackets/braces to move a paragraph up/down.

In CUA editors to me the nicest shortcuts are Control[+Shift]+Backspace and Control[+Shift]+Arrow because they involve the editor understanding a basic construct of human language (words). Vi takes that to the next level.

Why? Just use the 'relativenumber' option and do 5j.

> the second way is more popular in vim too.

Maybe for moving down 5 lines, but (I hope) not for things like "replace the inside of the brackets with what's in my A register". Otherwise you're really better off using a different editor.