Definitely, even now as I use emacs, I'm a 100% evil. It's just so natural (once you get it), that I don't know how other bindings (like ctrl-[whatever]) are prevalent in most other software, it's not like they are more memorable or intuitive.

Fun story: I was into Free/Libre software as a teen, when I learnt how to move around in vi(m) and in my first tech gig (as a sysadmin), I was interviewed by some greybeard who wanted me to do some maintenance and configuration tasks. I knew the basics of command line environments, but I had never setup LDAP, mail or DNS. So anyway he asked me to setup some repository on yum, and well, at least I knew how to do that. When he saw me using vi commands to quickly edit the file, he stopped the interview, arguing that anybody who was fluent on vi, was obviously a seasoned admin and I got the postion. I never had the guts to tell him otherwise.

It's proof enough that you'll figure it out.

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.

Indeed. Someone with the fortitude and discipline to get really good at their tools can probably pick up whatever you throw at them.

Its also a good sign that they might be into technology for its own sake, which also doesn't hurt.

Where I work we use a lot of jetbrains IDE's and I've been a massive fan of Intellij, I absolutely love it when I can show someone something that makes their life easier.

Whether it's how to implement an external program properly using all the expansions or how to use bookmarks (how people can use an IDE for years and not find that is a good question).

I've always RTFM of whatever tool I'm using as the first step then I go look at the default keybindings to see what else there is.

The one that blows people away though is the custom exporters you can write for data views, oh you want that result set in a PHP array for a test set, yeah Copy as PHP has you.

Intellij is absurdly powerful without writing custom plugins (which is my next step I guess).

... and Jetbrains IDEs support a plugin called IdeaVIM that provides pretty solid vi/vim emulation.

IdeaVim is the uncanny value of vim for me. It's so close to being actual vim, but every now and then it does something unexpected and it completely throws me off.

I recorded a macro to change shouldBe([true|false]) to shouldBe[True|False](). Pretty simple: qqf(ds(~$a()<esc>q

But the vim-surround plugin emulation doesn't work properly with macros, so it'd get stuck and instead of just doing n@@ , I'd have to do n@@( , i.e pass the seperator I used for the delete surround command.

It doesn't have fold toggling, so z[a|A] doesn't work. The undo behaves weird, you usually have to do it twice UNLESS you've not moved the cursor since doing the last edit.

The git integration isn't as good as vim-fugitive and I constantly find my self reaching for the mouse to do anything git related, whereas in vim I could do it all with the keyboard.

The plugin gets brought up all the time when people talk about the JetBrains tools and no one seems to mention the short comings.

Some people are satisfied with the modal editing paradigm of Vim that they don't need its advanced features.

(intellij sometimes has recurring problems with lost keyboard input under linux+gnome. IdeaVIM is one of the first plugins i disable, when that happens. and it often helps.)

What a great test, and it makes sense - a craftsman cares very much about their tools, an average tech will use the first thing that they're taught.

It's also what's so hard about hiring junior candidates and why so many companies shy away from it.

Truly junior hires don't really know the tools yet. You can't really afford to wait for the rare junior who does, so unfortunately it's not as useful a test in that situation.

That's why I think OP's "seasoned sysadmin" line is perfectly valid. The junior that knows their tools has already cleared the hardest hurdle for most companies. Everything else is trainable through mentorship, but tools usage requires experience.

Indeed, I always advise people who want to be developers to build some stuff to show, to separate yourself from everyone else, and make it easier for the hirer. That is another reason to do it, an IT degree doesn't mean you can write code, as you say the rest can be learnt.

An IT degree is not about writing code. Perhaps you are referring to CS.

You become used to the first tool you pickup, its ways become "natural", and hence you become opinionated.

I don't know about that, my first tool was vi, I have strong opinions about it :-). I use an all singing IDE (Appcode) now, its not perfect either but works for now.

(Funnily enough ctrl-[ is one of my most used shortcuts in vim. It’s a convenient alternative to escape if you map caps-lock to ctrl)

Even better: map held Caps to Ctrl and a tap of Caps to Esc

I map held Caps to Super (so I can switch windows and use other higher-than-application-level shortcuts without leaving the home row in dwm), but yes, definitely don't limit yourself to one use for your keyboard's most convenient key without a use. In X11 it's as easy as

    setxkbmap -option caps:super
    xcape -e 'Super_L=Escape'

(where setxkbmap is built into X, and xcape is a one-command install away). And IIUC you can do this with ~6 clicks in a third-party GUI like https://karabiner-elements.pqrs.org/docs/manual/configuratio... in macOS.

I really don't like chord like shortcuts, while ctrl and [ are positioned in a way you don't have to contort your hand it kind of requires you to move away from the hjkl row or stretch your pinkies. Consider mapping esc to jk (as a sequence) it works surprisingly well.

  inoremap jk <esc> 

and

  inoremap <esc> <nop>

so that you never use esc again

not having chord like shortcuts was one of the main reasons that led me to try vim over emacs in the beginning, so I kind of think they're "anti" vim.

I've been using ctrl-[ for years, but have been experimenting with jj. Now I'm not sure which one I like better!

I switched back to vim+tmux (nvim) a few weeks ago from a number of years using vs-code with the vim keybindings.

I'm still trying to configure my plugins so that I don't feel like I'm repeating myself too often.

Having ctrl-[ in your muscle memory has the advantage that it also works in other readline programs that have a vi like interfacee, e.g. bash, zsh and many db consoles.

I recommend mapping jk to esc in insert mode (instead of jj), so you remain on the same line if you accidentally use it in normal mode.

Note, don't do this if you're Dutch, words with 'jk', or rather 'ijk' in them are annoyingly common.

This is now my muscle memory escape key since an embarrassingly cheap Bluetooth keyboard of mine only allowed escape == home button on my Android devices.

Pro Tip: Park the flesh of your left palm near the left ctrl key and use that instead of your pinky for ctrl. I admit this feels a bit weird at first but avoids the need to lift your fingers from the home row. Super bonus: use ^H for backspace. Try it out!

Note: Often Ctrl-3 does the same thing.

That's excellent!

That gives a left handed option for escape without leaving the home row. I really like having mirrored shortcuts like that, thank you.

Omg that is such a game changer for me. way more ergonimic than hitting esc

You may be using vim wrong. Good for you if you like it that way

You're going to have to explain that one because I generally switch back to command mode after every edit so I use ctrl-[ a lot.

I'd be VERY interested to hear why that's wrong and what you do differently.

my reasoning was : you could have mapped caps lock to ESC but you did not. So maybe you are using CTRL too much (CTRL-V maybe?) which is not the best way to use vim.

No your reasoning is way off. I map to ctrl rather than escape because I want to make use of the Insert and Ex mode ctrl shortcuts.

For example, if I want to insert a register into the ex mode command line I use ctr-r <register>.

Or if I want to pop out of insert mode for a single command I use ctr-o.

E.g. inserting opening and closing tags when a suitable plugin isn't present. Insert the opening and closing tag, jump back to command mode with ctrl-o, move backwards and you're ready to insert more text.

Can't speak for everyone, but I use this[1] keyboard most of the time, and it doesn't have a Caps Lock key to remap, but instead has Control where Caps Lock normally is. So using ctrl-[ is much easier than reaching up to the escape key.

[1] https://hhkeyboard.us/pro-classic/

Using Ctrl-[ is perfectly fine if that's convenient to you. Some people doe "inoremap jj <esc>" and double tap j to exit insert mode. If it's faster for you than pressing regular escape, it's an improvement, and thus good.

Politely, I'd consider rephrasing this in the future. Not everyone springs forth into the world with a 5kloc .vimrc. Everyone is incrementally learning from someone else at their own pace.

I'll do. Thank you. I did not realise I was mean because english is not my native language

Yeah, I think you got lucky. He sounds like a great boss. And, he was probably right.

Such a thing is a proxy character trade and probably told him enough. I'm in bioinformatics, if an applicant tells me they studied biology but have always run a Linux server at home, I can also stop the interview: hired.

Heh, I would fall for that!

Same here, and then i discovered EVIL, the vi layer for emacs. The best of all worlds: Vim text manipulation grammar over the emacs engine.

I've used Emacs for many years, and recently switched to Spacemacs, a set of configs that kind of takes over Emacs and puts a great platform on top of it.

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

The problem with Emacs and all its modifications is that it cannot match Vim's flexible system for custom keybindings. And because of that Evil mode has the same limitation, beside its insistence to prefer using builtin Emacs functionality over emulating Vim behaviour correctly.

And the other thing that I could never get used to is that Emacs' terminals can't handle ncurses applications. I usually like to run Vim in a terminal multiplexer and combine it with various terminal utilities when needed, and Emacs doesn't support that - unless you run it in a terminal, but then Evil mode stops working properly...

I'm fine with Vim, but I'm glad I tried Emacs for a while because it does have some nice ideas.

> The problem with Emacs and all its modifications is that it cannot match Vim's flexible system for custom keybindings.

Interesting, my impression was that custom keybindings was more flexible in Emacs + Evil than in Vim. It seemed easier to e.g. define new modes with separate keybindings, and if you use the GUI version, more distinct keybindings are available.

> And the other thing that I could never get used to is that Emacs' terminals can't handle ncurses applications.

It can now. The problem is that there are a lot of shells and terminals available in Emacs, so it's not always obvious which one supports what. But emacs-libvterm [1] is a "real" terminal inside Emacs, and supports ncurses apps well. (The website warns about being alpha level, but I used Emacs + Evil for about half a year, and it worked fine for me.)

[1]: https://github.com/akermu/emacs-libvterm

> I'm fine with Vim, but I'm glad I tried Emacs for a while because it does have some nice ideas.

I ended up with the same conclusion :).

> The problem with Emacs and all its modifications is that it cannot match Vim's flexible system for custom keybindings. And because of that Evil mode has the same limitation

Can you explain what limitations you mean? What keybindings has vim over emacs?

> And the other thing that I could never get used to is that Emacs' terminals can't handle ncurses applications.

libvterm seems to have solved this problem recently. Works well enough that I can use vim inside emacs.

I have to agree. Emacs w/ Evil is a nice solution and gets almost there, but there are enough edge cases that interfere with the elegance of pure Vim. Everytime you install a new emacs plugin, you have to consider that it will use Emacs keybindings, not Vim, and you jump through hoops to remedy that, or, more often, you find yourself having to mix the emacs ways and the Vim way, which I personally found annoying after awhile.

Emacs is awesome and more powerful overall, but actually using Vim is easier -- from setting up keybindings, configuring your vimrc file, it's all quite simple compared to what you can do, and often do, in setting up Emacs.

But to be honest they are much closer to each other than either is to a more conventional/modern IDE. They are spiritual siblings for sure.

M-x ansi-term

Wait until you find out about Doom, which I consider to be all the good of Spacemacs without the crust.

Have you taken a look at Doom Emacs? I liked Spacemacs, but I found Doom more performant, as well as not abstracting too much, which allows you to slowly learn Emacs as you go.

Probably in the minority - I have an extensive custom .emacs.d, but I've kept most of the default emacs bindings. Not only do I find them ergonomic (use the side of your palm for ctrl!), they're also the same bindings you'll find in most terminals. Additionally, emacs does so much more than editing, and having consistent bindings across tasks is really convenient (I'm super lazy :).

just

``` set -o vi ```

problem solved! no more emacs pollution!

Alas, the emacs install base is fraction of vi/vim.

I am also surprised by this. What are you basing it on? For arbitrarily comparable online communities, it looks like emacs.stackexchange.com is twice as active as vi.stackexchange.com

> ...the emacs install base is fraction of vi/vim.

> What are you basing it on? ... it looks like emacs.stackexchange.com is twice as active as vi.stackexchange.com

A couple of things about this. For myself and many others, the reason I started vi in the first place is it's been installed by default on many kinds of machines. On SCO Unix and AIX from my youth, for example, this was the editor you used on a vanilla install of a machine to get things going. So this is part of why the install base is larger.

Another part of why the emacs community is more active is that Vi is just an editor, while emacs is more of a programming language and I daresay nearly an operating system in its own right. Because of the amazing power and flexibility of emacs there's a lot more stuff to discuss for Emacs than Vi.

When I was teaching myself to program, I had a night job in a warehouse. It so happened that the inventory software was on a UNIX server, and we accessed it through a terminal emulator from our windows computer. I discovered one day that I could exit the inventory software and end up with a shell prompt, and that the server had Perl available.

My computer books convinced me that emacs was the better editor, but it wasn’t installed on the server. vi was. So I learned vi and Perl on my lunch breaks.

Stack Overflow survey (https://insights.stackoverflow.com/survey/2019#development-e...) has Vim at ~25% while Emacs is at 4.5%.

it also has notepad++ at 30.5% - I've seen one or two people who would use notepad++ when nothing else is available, but I don't think many people have it as their primary IDE.

Also, if you sum up all the JetBrains products (which you can get as IntelliJ Ultimate if you shell out the money), you land in the vicinity of 63% (not vim-related but a neat fact)

Emacs is more complex, and Emacs users do more in Emacs than just edit text. (think org-mode, debugger frontends, mail readers, etc.)

Well vi or vim is nearly always installed by default everywhere, but emacs rare is so.

Vi users RTFM.

I love emacs, but I taught myself to use vi because I know when I ssh into a remote server there will have a vi.

Emacs has an edit-over-ssh mode that's pretty useful.

Yes Tramp mode.

You can do that in vim via scp like this:

vim scp://user@myserver[:port]//path/to/file.txt

Even if it's a Cisco router and there are no text files other than a note.txt 'Here be dragons'

I've always assumed the opposite with how people say emacs is a nice OS and poor editor... What does Vim over emacs?

It's not a comment on quality or usefulness, and only indirectly its resource consumption (vi/vim consumes less than emacs in its default configuration), it's really about standards.

vi and the ex editor language are part of the POSIX standard and were around early in the history of BSD. See the history here: https://en.m.wikipedia.org/wiki/Vi

For a well worn joke on the subject, "Ed is the standard!": https://www.gnu.org/fun/jokes/ed-msg.en.html

I love Emacs and have been using it for years but whenever I want to make a really quick edit, i.e. writing a git commit I almost always reach for vi because by the time Emacs loaded I would've been done committing with vi, at least with a slower machine.

I know some people run Emacs in daemon mode, but it's not always convenient to do that

This and when I ssh into any machine, I know there will be a vi at the very least

> This and when I ssh into any machine, I know there will be a vi at the very least

You could use emacs for that. Editing over ssh using TRAMP works perfectly in every case I've used it.

1) vim is easier on your hands if you're on a high-latency connection (i.e. usable in a terminal) and/or get tired of chording (i.e. having to press Ctrl along with random keys).

2) I've found vim's plugin systems (Pathogen, Vundle, vim-plug) vastly more intuitive than Emacs' version with package-install and activating one of several repositories (Milk, ELPA, MELPA, whatever) - you install the same plugin regardless of whether you're using Vundle or vim-plug

3) vim and its packages are vastly easier to configure - this is subjective and may be much improved in Doom Emacs/Spacemacs, but in general vim packages have a bunch of global variables that you can set to a number or a string whereas most emacs packages need you to define elisp functions and/or nontrivial data structures, with no sane defaults to fall back on if you want things just to work

It’s composability is Vim’s killer feature.

This post is what got me started on Vim: https://stackoverflow.com/questions/1218390/what-is-your-mos...

this is huge flamewar territory, but this is a bit 'off' question wise - alot of the current state of things is due to historical precedent - some details:

- (original) vi was on most unices from the mid-80s onwards out of the box

- (gnu/lucid) emacs was an additional install (not getting into other emacs flavors - original teco emacs was fairly small i believe).

- original vi just had basic editing and at some point a hardcoded lisp mode, no addons vs gnu emacs which was a programmable editing environment running within a lisp interpreter - remeber in the early days, people built whole custom hardware to be able to run lisp with sufficient complexity (see also: lisp machines, twenex, etc), so using lisp for your editor was in some sense the definition of 'overkill', depending on ones view of what an editor should do

- Also, from late-80s->90s era if you wanted a GUI for your text editor you probably used emacs, and real vi never had a gui option - put another way emacs was the only one of the two linked to gui libraries.

- vim vs vi: most obvious difference (IMHO) feature wise is that vim adds vimscript, which is an interpreted programming language, so now editing modes are extensible, etc (as was the case in emacs before). detail: vim codebase is not based on vi codebase.

since vi was just about everywhere and emacs was a (fairly large) package, you had more general vi knowledge vs emacs 'in the culture' since even an emacs user might need to know vi but not usually the other way around, and so vi (later vim, as linux distros switched their 'default vi' to 'vim') gained more install base by default. Then, people hearing about emacs likely hear the 'vi vs emacs' arguments and never try it since there are now many more choices, they've learned vi, they prefer an IDE, etc (in the old days there was much less choice, main 2 were vi and emacs, and emacs was probably somewhere on your managed LAN somewhere if you wanted to give it a shot)

most of the 'vi vs emacs' arguments are rooted in the real-vi vs fsf-emacs era and are basically obsolete in a modern vim era, since everyone is using gui library vim with vimscript, which basically means the same thing in terms of 'bloat' (both editors contain engines to display text in cli or gui mode and embed a language interpreter). Basically what was once valid internet lore kept getting past down, and the 'minimalism' of vim was confused with being 'minimal' in terms of what people meant in the original vi-vs-emacs discussions. Emacs does contain 'non editor' functions e.g. networking, etc, so the core is probably a bit bigger than the core of vim, but when people are still using these comparisons and talking about 'emacs bloat' while their preferred editor is some electron based thing, we've lost a bit of the point/message..

> vim vs vi: most obvious difference (IMHO) feature wise is that vim adds vimscript IMHO, the most obvious difference is that in vim you can kinda just press "i" and pretend its a normal text editor. You know, the kind anyone coming from another OS would already be familiar with. Try doing this in regular vi, and you'll be cursing and pulling your hair out.

Today, I don't put much stock into anyone expressing an opinion in the "vi vs emacs" wars, because 90% of the people claiming a preference for vi seem to actually be vim users. Using vim is a much more pleasant experience than using good old classic vi.

100% concur with this. I learnt Vim many years ago and I genuinely don't know what I'd do without it. It's always just there when I ssh into a new server. And the JetBrains suite has an awesome vim mode meaning I can use most (but not all) vim shortcuts with an actual IDE. I don't think vim itself works well as an IDE substitute, and wouldn't use it for hardcore web dev for example - but for quickly editing random files there's nothing that comes close.

If one wants to do web dev on vim I strongly recommend neovim setup with coc.nvim. I know some people strongly disagree with transforming vim into and IDE, but this is a really productive setup for creating code (works like a charm for my current React project)

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.

Yep, neovim, coc and fzf has made me really productive in vim lately. After years of vim I was tempted to use VS Code until I found out about coc.

FWIW coc.nvim does not require the NeoVim fork, it also works with vanilla Vim 8.

>>I don't think vim itself works well as an IDE substitute, and wouldn't use it for hardcore web dev for example - but for quickly editing random files there's nothing that comes close.

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.

I'll argue that the IDE is Unix, not vim, I recently started and endeavour to vanilla Vim and I was baffled by what is possible even without plugins, granted I mostly work with C and a bit of Python, but one thing to consider is that most people using Vim come from an IDE background, so horse for course I guess.

https://sanctum.geek.nz/arabesque/series/unix-as-ide/

Edit: Link

IDE has syntactic understanding of your code, which allows you to navigate your whole codebase as if it's one big hypertext document (invalueable especially when learning new code). Also, the syntactic understanding allows you to do one-click fairly complex refactorings with guarantees that nothing will get broken (at least it works for sane languages, like Java. I don't know how well it works for C/C++, where preprocessor macros complicate things). I don't see how "UNIX as an IDE" delivers this.

Yeah, UNIX doesn't do that on its own. You can grep, or run find and do a bash loop and so on, which is cool. But it's language servers that give semantic understanding of your code. You can easily refactor, or go to definition from vim. So UNIX is a development environment, very flexible, yes, just not that integrated.

I have mainly used vim for development and I can navigate my codebase just as seamlessly with ctags-generated indexes.

I'd agree on vim being of limited utility when it comes to automated refactoring (it's a text editor after all), but beyond changing the names or extracting functions what can an IDE do for you in this respect?

Refactoring in IDEA also allow you to for example also change function signature, safely delete an element (class, function etc.) - i.e. with full impact analysis, move code, extract interface/trait out of a class.

I've tried the ctags-indexes with Sublime and afair the basic navigation was not bad (I think I remember there being an issue with some delay though? It was a while ago). I'm not sure if things like "show code which access this variable" or "show all children of this class" are supported though?

Apart from those advantanges, I can think of two more:

1. IDE can import your build file (maven, sbt or bazel project for example), parse out the project structure from it and download the necessary dependencies. I don't think that ctags-like powered solution is as robust, which means you'd have to fiddle with it until it can understand the structure a complex repo.

2. IDE can run and show the results of unit tests. (just right-click on test you want and select "Run" from context menu).

My build tool spat out a 700MB compile_commands.json file, which the C++ language server turned into 25k files. None of the language server implementations were able to process even a go to file on the code.

it takes about 15 minutes for Visual Studio (well, visual assist) to generate the index for the project, and then the navigation is instant. I've tried a few times over the last few years with various language server and clients, and my experience has been the same pretty much every time.

You can use ctags/cscope to handle that, FWIW languages like C and C++ have a massive toolset built around Vim, so even for the most obscure use case, I'm pretty sure there will be a way.

> at least it works for sane languages, like Java.

You lost me here.

> I don't see how "UNIX as an IDE" delivers this.

Have you read the linked series of articles? The author explains and provide examples with C and Perl, Iirc there's a book about working with Makefiles in Java, so it's totally doable, painful, but doable.

Unix is not an IDE. The I stands for integrated. Unix is just a good old development environment...

Fair enough

The use case of vim is not using an insane amount amount of arrows/ctrl/shift for everything.

It's like a mechanic using just one adjustable spanner and one screwdriver to e.g. replace a clutch. It's ok if you really don't have anything else, but any good mechanic will use a set of good tools. (sorry in advance for the car analogy).

BTW a modern vim setup with CoC is not very short of an IDE, but at lightspeed.

I’m always interested in this opinion.

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

I tried getting vim to match my favorite features in VSCode / Jetbrains IDEs and almost went crazy. Rather simple things like code completion or syntax highlighting were already moderately complex to set up. The command palette present in both Jetbrains and VSCode also has thousands of actions easily searchable in plain language, the most simple of which can be replicated with vim (ex: open file) but many of which would likely require some heavy extra configuration. I never even got into replicating things like live templates which are a massive productivity booster for me - I simply gave up.

For me it’s much easier to install the vim plugin in my IDE or editor of choice. I get the modal editing goodness of vim with a supercharged layer of utilities that work out of the box.

I'm not going to argue with your personal choice or that you should spend time configuring vim.

I'll just point out that the things you've discussed are possible in Vim if you want them.

E.g. live-templates (snippets) https://github.com/neoclide/coc-snippets

and that if you don't want to spend the time configuring yourself projects like https://spacevim.org/ exist.

Now there probably are some IDE features that vim can't replicate with plugins but it's very rare to see someone actually provide an example of one.

Something like a profiler with flame graph might be an example. Things like refactoring, completion or fast command search probably aren't.

The most important part of my point is not that I believe that they can’t be replicated, it’s that an IDE offers them with a time investment that’s nearly zero (I spend a couple hours per year fiddling with my IDE settings, tops).

I’d add that I am also quite doubtful that although they may be replicated, in many cases there aren’t going to be gotchas and UX problems not present in one of the popular IDEs. I can’t remember the specifics but I know that when I set up code completion in vim it wasn’t nearly as good as the one in my editor.

Never heard of spacevim but I have tried a few other “plug-and-play” vim adjutants like Pathogen and always ended up running into problems and spending more time on the issue than I had signed up for. Might solve some of the problems I mention, but I’m afraid it’s too late for me.

My IDE does everything I need and more, working out of the box on all machines I own (they’re not even that powerful) with fantastic UX and minimal fuss. I’m a Jetbrains guy so it costs me 6€/month but amortized per hour spent it might as well be free. If I wanted to save that nominal cost I’d go with VSCode, which I’ve worked with before and is nearly as good.

I’d turn this around and ask, why would I ever switch to pure vim?

> I’d turn this around and ask, why would I ever switch to pure vim?

I don't think that you should.

I'm only addressing the point that vim can't be used to do IDE like tasks, which with LSP support it clearly can

...but right now you will have to configure it if that's something you want. If it's not then you're good to go with your favourite IDE already.

There are things like refactoring which technically are supported by vim extensions, but are just utterly inferior to the dedicated IDEs.

For example - you know "extract method" refactoring. Pretty basic thing and I assume vim can do that. But on top of that when you extract the method, Intellij will go through rest of your code and try to figure out if some other parts could be automatically refactored to use this new extracted method as well. It will offer to change the method signature if needed to do that as well.

Intellij will - as you type - notify that the code you're writing is structurally duplicating an existing code and offer an intention to automatically refactor the code to remove the duplication.

Intellij offers an integration with databases - in my code I use a lot of SQL queries - intellij can connect to the data source and scan the schema. When you then type queries into strings, Intellij recognizes them as such, offers autocomplete to the tables/column and validates the query for correctness (also allows you to click through to the actual data view). It understands like 20 SQL dialects and things like JPQL as well.

Another example is the deep flow analysis which can point out logical mistakes as you type (things like NPEs). This is very helpful in daily programming, extreme example of that is shown here: https://blog.jetbrains.com/idea/2019/11/intellij-ideas-stati...

Most of the time when people showed me a "vim IDE", it looked like IDE from the 90s - highlight was that it showed you the list of class members, had a snippet manager and could sort of rename a variable. State of the art is much farther since the 90s though ...

That sounds very useful and it's not something that vim gives you out of the box but I'm not sure that anything you're describing is not possible via LSP plugins and extensions.

Running a server to automatically search for duplicate code sounds exactly like the kind of task that LSP can handle.

Since VSCode has tools for deep flow analysis (although I can't say how they compare to Intellij) then I'm pretty sure I can access them from neovim.

Maybe if I was a Java developer something like Intellij would look more attractive but I've never really been impressed with the rest of the JetBrains IDE family.

Horses for courses I guess. If there's some tool you want that's only available in Intellij then that's what you'll use.

All of that is of course theoretically possible with LSP or other vim extensions. It's just that nobody did it.

Another thing is the level of integration. There are many tools which offer static analysis, duplicate detection etc. But it's completely different level of usability when you see this info immediately as you type.

People already use LSP in vim/neovim. Realtime feedback as you type is a thing in vim.

Here is an example for typescript users.

https://thoughtbot.com/blog/modern-typescript-and-react-deve...

Again this does require you to configure things and that may not be what you want to spend your time doing but it's perfectly possible.

Also I'll add that I'm not arguing that vim is better than any other particular IDE or editor, just that IDE like features can easily be added.

Yeah, I know that you can use LSP in vim. But LSP for most languages is a far cry from what you can get in "real" IDEs.

It's always "LSP could be just as good" or "support for that can be easily added" - but it's just not happening - nobody does the work to make that just as good.

I've used vi for 25 years now, starting on a m68k based BSD machine. It's an adequate editor, handy in remote shell sessions and good to know how to use, but I'd MUCH rather use an IDE or a windowed editor with menus and mouse and hotkeys like Sublime. I mean real hotkeys, not emacs.

At the end of the day, it takes a certain kind of mind to like vi, and if you're not of that mind, you probably never will be.

My argument isn't that vi/vim/neovim are not superior editors but the editing grammar is a superior way of thinking about text. This grammar can be reasonably replicated in any environment, and confusing the grammar for the editor is what makes people make such claims.

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 think it depends heavily on what you're doing. My world is full of YAML/HCL/cnf files, and if I'm writing code, Go, where code is for software that runs from the command line, a daemon, or a no frills API/web service. Atom/VSCode and other IDE's were wasted on me, so I found myself gravitating back to Vim for its ease of use for those use cases. That said, vim-bootstrap did save me effort of getting a pretty solid editor out of Vim without having to think too hard about it.

Of course IDEs are wasted on Go - there’s literally not a single IDE in the world that can find all implementations of an interface in Go.

Hated Vi at first. Absolutely loathed it. I was all about emacs.

But I gave vi another shot, and I'm so glad I did. The learning curve can be steep, and it's really unintuitive at first (or it was for me). But once it clicks a little bit, and you settle in.. Wow. I felt way more productive using it than any other editor.

I've been using vim for ~8 years now as my editor at work. I don't even use the "fancy" movements that everyone always brags about. It's still way more convenient to move around in than any other editor I've used.

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.

This just sounds like a nightmare to me. I can't stand it when I have a terminal program with an unseeable list of files/panes that have to be opaquely navigated through. I very much want to be one of those vim/emacs ninjas but I just don't see how this is more ergonomic than Jetbrains where any file - not just 'open' ones - is readily available with all sorts of search methods with a single shortcut. And then I can visually see what files I'm working with instead of groping around through one file at a time in the dark.

> I just don't see how this is more ergonomic than Jetbrains where any file - not just 'open' ones - is readily available with all sorts of search methods with a single shortcut.

I would guess the difference is that I use a separate terminal window for all of that stuff. I have my desktop split into three main workspaces. The first has my terminal, the second my browser, the third my editor. I have two more workspaces just in case, but they rarely get used. I have shortcuts set up to hop between workspaces using `<super><workspace number>`.

If I want to track through where something is used or defined, `git grep` usually gets me what I want. From there, if there is a file I want to look at, I use my shortcut `go <filename>` to open it. This used to be an alias for `gnome-open`, but a couple years ago they switched it to `xdg-open` . It opens the file with whatever program would open it when opening it from the file browser, which for any text file is my vim instance over in workspace 3.

I don't pay much attention to which files are open or not. Usually I build up a working set of files I care about pretty quickly and then I can hop between them from within vim. Otherwise I can easily go back over to my terminal and open it by name directly.

It may not be for you, but it's far from a nightmare in my experience.

> It may not be for you, but it's far from a nightmare in my experience.

Right, everyone has their preferences. As was said in another comment, merely paying attention to and adapting one's personal tooling is a huge differentiator between software developers, regardless of which particular tools those might be. Your setup has a lot of conceptual similarities to mine. I use terminals heavily, but ultimately I personally like a GUI as the 'root' of my working space. I'd rather start from a place where I can navigate everything visually/spatially and then add shortcuts on top of that to automate the most repetitive/tedious paths that naturally occur in that environment.

Vim can operate like that if you want. Most people use NerdTree to have all of their files visible like most IDEs: https://code.tutsplus.com/tutorials/vim-essential-plugin-ner...

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

Now this is dope, I used to rely on a trick I discovered in a conference[0], append to the `path` variable in your .vimrc so you can recursively fuzzy find files in the directory where you opened Vim, and more recently setting global marks[1] in the files of interest.

0: https://youtube.com/watch?v=XA2WjJbmmoM

1: https://vim.fandom.com/wiki/Using_marks

(Helpful tip) map caps lock to escape: https://vim.fandom.com/wiki/Avoid_the_escape_key

Strongly agree -- I mapped my whole keyboard to always have caps/esc swapped. It didn't take long to get used to. My left hand feels way better, not needing to reach very far.

Biggest downside is using someone else's keyboard. I've grown a nasty habit of hitting escape instinctually, every time I finish typing something. I turn on their caps lock so regularly! Still worth it though

I still use caps lock since I regularly code in POSIX shell, C, C++, and Perl, which all have naming conventions that use all-caps names.

Also, as a VIM user, I only have to use Alt when I’m dealing with GUI apps, which is definitely common, but a time when I don’t mind moving my hands around.

So for me, Esc is Alt. Alt is caps lock. And of course caps lock is Esc.

And I swap Super key and Control, since the Super key is easier to press with my palm on my ergonomic keyboard. And Ctrl does have a lot of uses in Vim.

I also map the Windows Menu key (not the Super key, but the other one which is used for showing context menus) To underscore. That helps me type C identifiers with multiple words in them. This one remapping is a huge benefit, almost as important as mapping caps lock to Esc.

Map caps to ctrl and you can get access to a world of convenient insert mode shortcuts.

ctrl-[ (for right hand) or ctr-3 (left hand, thanks teddyh) => escape

ctrl-i => tab

ctrl-h => backspace

ctrl-m => return

ctrl-w => delete prev word

ctrl-u => clear line

ctrl-o => cmd mode for 1 cmd

...and many, many more, including all the completion options.

Still wasteful. Map Capslock to both Escape and Ctrl and never look back

https://github.com/alols/xcape (for linux)

https://apple.stackexchange.com/questions/132564/how-can-i-r... (for macOS)

https://github.com/ililim/dual-key-remap (for windows)

What's the advantage to having control on it as well? Do people have trouble reaching the control key?

Try it (or swap caps and control for day, to make sure you don't accidentally "cheat"). On most keyboards reaching the control key is very unergonomic compared to the capslock key. I wonder how many cases of RSI could be avoided by this simple tweak alone.

I strongly agree, but would go one step further and just remap caps lock to escape for the entire OS. Caps lock is a relatively useless function that takes up extremely prime real estate.

Or if you're on a locked-down computer because your office hates people, ctrl+[ works as well (and is portable to other people's computers)

You can also do the remapping in hardware. Programmable keyboards are quite popular these days (I built one out of a $3 stm32f103), and they don't rely on the OS to help you do what you want to do.

(This is a blessing and a curse. You never have to worry about OS-level hacks to make caps lock a control key, but on the other hand, there is no way in the USB HID protocol to say "send an !". Rather, the keyboard has to synthesize a shift + 1. And what character that actually maps to depends on your OS, because of course it does.)

I still get some mileage out of my caps lock key and use "jj" and use paste mode if I have to insert an uncommon string with "jj" in it. Usually pasting it anyway.

I tried that `jj` or `jk` thing for a while and it just did not click with me at all.

I tried it because I was having a bunch of wrist pain. The actual solution to my wrist pain was easy: Don't code on a laptop keyboard. The ergonomics are terrible.

I went one step further and swapped escape and caps lock keys on all my machines and haven't regretted it so far.

I cannot remember the last time I wanted to use CapsLock--more than 30 years ago, anyway.

By far the most irritating thing about others' keyboards is they have not disabled it yet. Second most is that Ctrl isn't there instead.

How do you TYPE_A_CONSTANT for the first time, or an ENUM_VALUE (perhaps somewhere you don't have autocomplete)?

I keep a caps lock on my programmable keyboard for this (Fn+K).

I also like SQL to be formatted with capital letters for keywords.

Either using shift keys or:

  type_a_constant ctrl-[ vawU

That sounds more than it is. Really I just touch type it without thinking consciously about it.

Probably don’t even need visual mode that’s just how I work.

I prefer Ctrl on Caps Lock and Escape on the original Ctrl. Works pretty well too.

One thing I like about vim is that the defaults are more sane than emacs. Almost no one uses emacs out of the box without extensive customizations. People customize vi too, but out of the box it is already pretty close to being there on its own, which is really nice.

This is really interesting.

I'm quite the opposite. I keep trying to make vim my main devtool but I just can't stay away from a fully fledged ide. At the same time, having heard from literally everyone that once you do get used to it, vim is way faster to do everything in.

What advice do you have for someone like me to proper get used it once and for all? Are there any good resources you used to learn all the vim shortcuts?

My advice would be to start with the bare minimum: Using [i] to enter insert mode, [ESC] to get back to command mode, arrow keys to move around in either mode. With this you can use vim like Notepad.

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.

There are a number of vim plugins (like YouCompleteMe [https://ycm-core.github.io/YouCompleteMe/]) that can turn Vim into an IDE. If that isn't enough, you could try Emacs (yes, I know) with an evil-mode based distribution like DOOM Emacs [https://github.com/hlissner/doom-emacs].

install vimtutor on your system, or just open this in vim:

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.

You don’t learn Vim that way. Once you get the Vim grammar, you just flow. Verb-adverb-noun.

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

Same as you. I've ended up accepting that whatever the features or the plugins, the UX constraints in terminal editors (1-character unit of space, colors, graphical plugins...) will always be a huge limitation. That's reason enough to convince me to use VSCode or Webstorm with a vim plugin

MacVim uses the Mac’s graphical goodness to make a pretty slick interface for Vim.

If you like vimium, you may also like qutebrowser. It's built with keyboard bindings from the ground up, and is keyboard-first. I can browse most sites without taking my hands off the home row.

I use both QuteBrowser and Firefox with Vim Vixen, one of the thing that make me reluctant to switch completely are mostly addons, Multi-Container, cookies auto delete, ublock origin, Privacy Badger, ... I can't browse the Internet without those, and the built-in adblocker of QB is unfortunately not that performant. Also, you can't use the keyboard everywhere (thanks to the modern web) Random example off the top of my head: https://questions.wizardzines.com/event-loops.html

> and the built-in adblocker of QB is unfortunately not that performant

With "performant", I assume you mean "how well it works", not "how fast it works"?

FWIW a better adblocker is in progress: https://github.com/qutebrowser/qutebrowser/pull/5317

> Also, you can't use the keyboard everywhere (thanks to the modern web) Random example off the top of my head: https://questions.wizardzines.com/event-loops.html

Yay... You can always customize the hints.selectors setting to add selectors for those (for websites you use a lot).

There are also some thoughts on how to add hints to all elements with a JS click handler, but I haven't had a chance to take a closer look yet: https://github.com/qutebrowser/qutebrowser/pull/4817

> With "performant", I assume you mean "how well it works", not "how fast it works"?

Exactly, sorry, not a native speaker.

> Yay... You can always customize the hints.selectors setting to add selectors for those

Didn't know about that, thanks

The way I use qb is I've switched javascript.enabled to false, and occasionally session-enable it for some sites (by default, this is done by typing tsh)

I have also written off a portion of the web as not being worth mytime, however.

never heard about qutebrowser and it can even play netflix, impressive, it's a little memory hungry though, with just netflix running I saw memory is used almost 1GB, while 30 chrome tabs use 4.5GB

I was in the same boat. First real gig out of college (well besides the stints during college) and I saw how fast my boss flew on his keyboard while editing files in vi/vim. Here I was painfully editing config files in nano while he was flying by with vim.

I took the time to learn it and have been using it since. I now try to pass the torch by showing folks on my team the neat things vi/vim can do. People are amazed how much you can do it with just few short keystrokes.

I was interested in programming, don't really know why but the thought fascinated me to be able to instruct a computer to do things you want it to do. So I had tinkered with QBasic and Pascal. A friend of mine went the C/C++ route which lead to us arguing like cat-and-dog (surely out of boredom) about the various benefits.

Then we mutually tried out linux and editors. He picked Emacs, so I went with vim. Haven't regretted it ever since.

What has always kept me from learning Vim is my non-English keyboard layout. Many of the default key combinations are impossible or require some serious finger acrobatics.

Sure, I could try figuring out a new set of easily reachable and non-conflicting keybindings for my own machines, but much of my motivation for learning it in the first place was being able to work on remote machines more comfortably.

Try out a US* QWERTY keyboard for a few months. I grew up with non-English keyboards, but then some years ago I got stuck with a US keyboard for half a year, and after that I didn't want to go back. I can easily type the few non-English characters I need with the X.org compose key, so I can easily write in my native language. I assume it would work equally well for any language using a Latin-script alphabet.

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

Interesting point, and a good reminder of how anglocentric the computing world is in some ways. Do localized IDEs typically take this into consideration?

I like vim, it's efficient.

This comes from an emacser. Emacs who shares this trait a bit (albeit rarely installed by default) .. when sublime text was all the rage I saw how emacs had 50% of it builtin and the rest was absorbed in a few monthes. I felt emacs would never fade at that point.

Same experience here. Before learning vim I never expected its interface to make such a difference (it seemed daunting and unergonomic). I think the only other software that has made me feel that way is i3.

I think this is the truth for me.

I have learned hundreds of tools and IDEs over the years, and nearly every one is defunct and not used any more.

Every minute I've invested in learning vim has remained relevant and useful.

> And since, almost nothing else (save for maybe git) beat learning vim from a return on investment perspective.

Interesting. I generally use IDEs Pycharm or Eclipse, or VSCode depending on the language. Do you think I would gain a lot from learning VIM?

No. It's like when somebody wants to learn how to fly, people tell them first to learn how to run really fast.

Nowadays Vim isn't just Vim the text editor but rather a specification for text manipulation. All of the popular IDEs have Vim plugins and the benefits of learning both are perfectly additive.

I think your timeline is inverted. vi-style text manipulation has been a thing long before Vim.

I don't think I've claimed otherwise? Still, in my timeline those plugins aren't called IdeaEd or VsEm.

I dream of the day when Excel will have a vim mode... My life will finally be complete.

Perhaps you should give sc-im a go. It's no excel but a good enough spreadsheet with vim like keybindings.

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

Thank you!

> And since, almost nothing else (save for maybe git) beat learning vim from a return on investment perspective

Same here. Love high ROI tools where the rug doesn't get pulled from underneath me ever year or two. Linux console tools, bash, vim, etc. My vim config dates back 20+ years, with only small modifications. I can log in into just about any *nix machine made in the last 30 years and be able to edit text at least somewhat comfortably. It takes me 30 seconds to set up a fresh Linux machine to my liking: clone a repo and run a script to symlink things to the right places in home dir. Done. I can also comfortably work from anywhere in the world over a crappy SSH connection.

C++ is the same. Glacial pace of change, skills from 20 years ago are still good with minimal modifications. 20 years from now it'll still be in use and it'll still be about the same. Which is exactly how I like it.

Another good thing about these gnarly old tools is that they weed out the dumb and impatient. I strongly suspect Rust is the same way - the learning curve and feature set look formidable. Lesser engineers are unlikely to ever learn it to the extent required to enjoy working in it. There's value in that, so I might learn it as well once they stop screwing with the core libs. I have work to do, I have no patience for such things.

> C++ is the same. Glacial pace of change, skills from 20 years ago are still good with minimal modifications. 20 years from now it'll still be in use and it'll still be about the same. Which is exactly how I like it.

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.