> My vim config is 600 lines. I have fixes for small annoyances. I have a bookmarking system set up in 45 lines. I have extra syntax highlighting for code snippets that are important to me because I’m doing things the original syntax maintainers never even considered. I create impromptu keyboard mappings and abbreviations and autocommands as needed for given tasks. I can move around in the design space at will.
I use VIM on and off, but I wanted to post the above because I think it exemplifies who might like using VIM.
VIM is ideal for people who find it worthwhile to spend the time building their configuration out. VIM is the productivity tool that gets better as you put the time and effort into building it out. If you aren't the kind of person who wants to put that time and effort in, it is still decent as a basic editor, but it doesn't really shine.
I don't disagree with your thesis, but I should point out that I have been using Vim almost exclusively for almost six years now (well, NeoVim for 4 of those years), and my config is only about 40 lines, and most of it is just installing plugins for whatever languages I'm using.
Despite me not hacking it like crazy, I still think it really shines as an editor; Vim macros were sort of life-changing to me once they clicked for me. I also just think that modal editing is superior once you get past the initial learning curve.
I use VIM for almost all basic editing. Its muscle memory.
But for code editing, I generally end up on VSCode because it seems to have better language support. I've spent a fair amount of time with configuring VIM trying to get where I feel it needs to be. But whenever I shift to a new stack, it always seems to take an investment of time and effort to get VIM set where it's better than VSCode.
Having to install node.js for a language server client is sort of a downer. For this reason I've been eagerly awaiting the built-in client in neovim, though it's definitely less polished and feature-complete than CoC today.
Fair enough. I've been using coc for a while now and can't say I've ever had any speed issues that I've noticed. But if the neocvm language server is built in and "as good" as CoC then that'll be one less plugin I'll need to install when it's ready.
Yeah I don't have any node.js speed concerns for it, I just would like to have the simplest editor microservice architecture, and putting the client to a service in a service was a bridge further than I wanted.
CoC looks neat (installing right now), but it's a perfect example of what I mean. Having to poke through and add several dozen lines to my config file to get it working.
I don't use vscode that much, but when I was checking it out I installed some extension which lets you edit text with true neovim (point it to a bianry) while vscode handles chrome and code understanding. Worked pretty well.
You're probably talking about Neo Vim[1] by Alexey Svetliakov. I can't recommend this one enough for a (neo)vim experience in VS Code. It is relatively new and deserves a lot more attention.
There are many ways to use vim and they're all valid! People who love barebones vim are cool. People who love configuring vim are cool. People who love embedding vim in larger programs are cool. We have way more in common than vim squabblers pretend!
Along with Evil, Emacs org-mode is the thing that eventually lures a number of people like you over from Vim. Evil makes editing in Emacs close enough (very close) to editing in Vim. Org-mode gives useful functionality that you can't get in Vim.
So, I am now a longtime emacs (and evil, love vim-ey things) user, and I've dipped my toes in the org-mode water a few times, but it's never quite stuck.
Have you got any suggestions? The number of people that recommend it makes me sure that there's value to be had there, but it's never really become a habit for me.
I've been using vim and before that other vi clones or actual vi as one of my main editors for 40 years, and my .vimrc is 60 lines.
20 of those are to automatically decrypt on read and encrypt on write .gpg or .asc files, which I copied from somewhere 20-25 years ago and haven't actually used in 15+ years, leaving only 40 lines I actually care about.
My problem is that some of that building should've been sensible defaults, and the community tends to outsource those responsibilities to extensions.
Which means your Vim experience now has some risk of rot. Once and awhile my configurations/extensions rot and I have to go and update myself as to what happened in the ecosystem, or what is interacting with what. One day I decided I'm too tired and switched to VSC.
Also the author failed to talk about the #1 killer feature of VSC, the reason for its meteoric rise in popularity — intellisense.
Thankfully, you can get LSP-powered completion with coc.nvim, just like in VSC. It's miles better than YouCompleteMe, plus it's much easier to install—you can just use vim-plug or similar to install it.
LSP is truly one of those "rising tide lifting all boats" projects.
FWIW, neovim's built-in LSP (nvim-lspconfig -- written in Lua, currently in beta) is _outstanding_ and I have already replaced coc.nvim with it in my neovim set up. Set up is super simple, there are 2 extensions to install. Configuration is simple, I think I needed maybe 8 lines added to my `init.vim`. With that I get completion and in-line diagnostics and it's very, very fast, at least with solargraph, clangd, and tsserver.
> My problem is that some of that building should've been sensible defaults
Vim suffers a bit from the design equivalent of tech debt. Much of the defaults and common behaviors were created based on the limits of software/ hardware 30+ years ago. Those limits still affect current design.
> Also the author failed to talk about the #1 killer feature of VSC, the reason for its meteoric rise in popularity — intellisense.
Given a fairly small amount of configuration, you can get autocomplete which is nearly as good as Intellisense in VSCode. For Typescript anyhow, the autocompletion comes from the same source background process.
If you take a step back and look at software development as a whole then IDEs like VSCode and PyCharm take the top down approach.
Whereas Vim is one of the solutions which do it bottom up.
With both approaches you can theoretically arrive at the same functionality but in reality, there will always be something missing.
Some people prefer the bottom up approach as that gives them the illusion of knowing their tool completely whereas people with the top down preference think everything is curated for them.
Over time, both kinds of people notice this isn't quite true.
This is one of the motivating forces behind nvim. While nvim supports vim script, it provides Lua as its preferred language for extension. In addition, the internal APIs are documented and are intended to be accessible from any language via RPC.
drawing from my own experience, i once found myself trying to work on a client website. thanks to a series of events i was using termux from a cellphone. i grabbed my vimrc from my dotfiles git repo and that was that. took all of 30 seconds to turn someone's cellphone into an interface identical to the one i use everywhere else
My .vimrc is around 80 lines including 15 plugins. It's mostly like that for last 8 years. And i don't have any problem using using unmodified vi/vim on servers, which is a big plus.
My vim config is empty. I use it periodically and know the basics. I prefer it over nano and pico by a mile.
600 lines seems pretty long to me. I don't even know what I would put in a .vimrc file. Obviously I don't use it enough to even have annoyances.
The nice thing about have no config is that I can hop into vim on any computer or server anywhere and be able to use the editor. I don't have to worry about having muscle memory of using keybindings/aliases that don't exist.
as much as I enjoy my current job, I really want to learn new programming language/paradigm, or new skills to let me have a job with vanilla Vim without vimrc as my daily driver.
While I understand why you may want an empty config, at the same time, I don't get it. It's not a criticism.
I knew a guy that not only had no config, he didn't even use syntax highlighting, which I can't live without.
All of that power and configurability is there for a reason. My config is about 250 lines; a lot of that is just to have Vim operate like it's 2020 and not the 90's.
I'm not a C programmer, so I don't want /usr/include in my search path, which it is by default.
I want to ignore things I have no intention to edit, so I have
set wildignore=*~,.DS_Store,.git,.hg,.svn,*.bmp,*.gif,*.gz,*.ico,*.jpeg,*.jpg,*.mp4,*.pdf,*.png,*.tar,*.webp,*.xz
Gotta have relative numbering while showing the absolute number for the current line:
Fabulous article that explains runtime files and why many modifications to most people's .vimrc should be in ~/.vim/.vimrc and other other runtime directories.
Lots of Vim users talk about using a minimal config because they need to access random machines that won't have their custom setup.
Or that it's some kind of badge of honor to not have any plugins, even if they could save you a ton of time and keystrokes.
Let's not forget:
1. Vim is great at remote editing, so you can use your config when updating files on servers, etc.
2. You could put your ~/.vim/.vimrc in a repo and install it anywhere you need it in like 5 minutes.
3. You could also rsync your local config to a machine if you needed to.
Of course I can use barebones Vim on some random server, but sometimes you need all the goodies with you.
The video Your Vim is only for you: (https://www.youtube.com/watch?v=6LPBpmkQdw8) reminds us that our Vim is just for us and if that means tricking it out so that it becomes our own custom editor, then so be it.
> VIM is ideal for people who find it worthwhile to spend the time building their configuration out.
I've been using VIM for over a decade and currently my customized config consists of a half a dozen tweaks, such as YAML-specific settings stashed in ./.vim/after.
The ability to customize Vim is precisely why I can't use Vim plugins for other editors. They never capture my customizations, and never offer the ability to replicate them. So I just live with non-modal editing when using other editors.
Speaking of modal editing, I'm really interested in Kakoune's model. With Vim, you type the action, then type the motion, and it performs the action immediately. This often means I have to repeat actions a few times if I'm unsure quite what motion I want, or I have to pause and count things (e.g. if I want to delete from the beginning of a token until a close paren, doing that with a single "d" command requires me to mentally balance parens to find what count I want to give to the motion). Kakoune flips this around, you do the motion first, then do the action. Of course Vim has its visual mode which is similar, but that puts you into a different mode entirely that you then have to exit if you change your mind, and not all commands work in visual mode. Kakoune also has far better support for multiple selection than Vim. The problem with Kakoune is just that I can't use it anywhere except in the terminal, which is a barrier to adopting it (whereas I use MacVim often). I'm also not sure offhand what the plugin situation is like (I know it supports plugins, but I don't know how powerful they are; I recall when kakoune first came out all extensibility was done by shelling out to external commands but I don't know if that's still the case).
Thanks for the mention of Kakoune, which I hadn't heard of. This page on its site makes a pretty interesting case for the power of its command model over vim's (though I haven't been a regular vim user for many years):
Vim is a tool. The more knowledge you have, the more powerful it becomes.
Vim was my first editor in Linux. Before that I used Borland, VS(Visual studio) and MASM(Microsoft assembler) editors.
After learning regular expressions, I felt superman with Vim. I started doing incredible automated work that was impossible or very hard to do in anything else like VS, netbeans or whatever.
Then I learned Lisp, so I forced myself to master eMacs. It happened again, I felt super-superman once you understand Lisp and can use it to automate everything on the editor.
IDEs are great for starting to program. But if you plan on being a serious programmer I recommend that you download anki and start memorizing Vim or emacs or regular expressions commands.
That will make you also a super human, able to do things in way less time that everybody else.
“IDEs are for beginners” and “IDEs are not for serious programmers” and “Vim/Emacs make you superhuman” are myths we should not perpetuate as programmers.
I like Vim/Emacs, but they succeed in making programmers feel like magical wizards more than they succeed in making them super human.
I've also paired with vim/Emacs users who are fast at manipulating text, but terrible at all the things you can do in a couple of seconds with an IDE (rename a file/function/class/parameter and have all references update, jump to a failing test, jump to a definition of library code that isn't stored under the working directory path, structural search and replace[1], extract JSX code from the render method to create a new component etc. etc.).
For many, it's easier to add vim emulation to an IDE than it is to add the IDE features they care about to vim/Emacs. You can still be a passionate, professional, productive developer and use an IDE.
We all start out with the same equipment; the only automation we get is muscle memory. We add software, and multiply that. If we add automation to the software, we multiply it again.
There are reasons why some people can do more than other people. Some people have natural advantages, in certain directions. Nobody has them in all directions, but automation can often compensate in the other directions.
If you don't have ambition to excel, you can stay with the minimum. If you have enough natural talent, you can play to your strengths and excel only there. It's a choice of where to invest your time and effort. It should be a conscious choice.
IDEs are a trap because they automate only certain things the IDE author thought was important, and do not reward impulses to improve in other directions.
>There are reasons why some people can do more than other people.
Yes. 80% (or more) of that is them perfecting their technique (whatever this means in each case). 15% is them spending time on what is really matters. And 5% is for the rest, including crafting or customising their tools. And in many cases you don't really need these 5%.
>IDEs are a trap because they automate only certain things the IDE author thought was important
No, human mind is a trap. IDE is just another piece of software that can be extended just as much as vim or emacs and tailored to your needs. Maybe not that easily or extensively but still.
>things the IDE author thought was important
Modern IDE's are crafted by great number of people with constant communication with their customers and industry. Obviously mass product can't be tailored for each person but you can safely say that a generalised IDE will have all things that are actually important. Everything else can be added via plugins
PS: I'm writing this as a neovim user by the way. Still think that IDEA and VSCode are the best pieces of dev software aimed for mass market out there.
Can you give an example of "super human" regular expressions?
I use regular expression search/replace (even across all files in the project) frequently in WebStorm. I'm really curious what functionality I'm missing out on.
I can boil my preferences for Vim down to a single thing that I can't find anywhere else: it's fast. I can open stupidly large files and not worry, or mash page down and have no lag. It's a pretty much invisible part of my daily workflow and any time I have tried another editor the speed is the first difference I notice and find immediately frustrating. Every other editor I have tried, even including Emacs (sorry), has at least a slight, but perceptible, difference in speed.
Yes I probably shouldn't open massive log files and hold page down, but it's nice to know that I can.
Try nvi. It'll open files vim chokes on. Try Ni string esc where N > 1000000 (insert 1000000 copies). Or however high you need to go to watch vim choke and gasp and wheeze and make you think your computer hung. Then go do the same thing in nvi and watch it happen in one second.
Likewise, find the file of size that vim can't handle on your machine, then open it with nvi.
For those virtues, speed and opening large files, nvi eats vim's lunch.
I love vim for quickly looking at files, but when it comes to working in a large codebase, I like to have a lot of information visible at once, such as having a Find panel with results, multiple files open in multiple panes, a file list, list of currently changed files, etc.
Aside from the last sentence, I do all of those things with a combination of emacs + tmux. My workflow would easily be translated to vim. I split my screen into multiple windows each with multiple panes. Then use things like fswatch to trigger automatic execution of various things like the test runner and the build system.
What can I say, I use the mouse a lot. Despite using i3 I still rarely use shortcut keys to change focus. Then again, I shouldn't be apologetic for being a mouse user. It's just another tool.
I find moving around tmux panes kind of annoying and scrolling them even more annoying, but that's probably more of a lack of comfortability with it than anything else.
I'm not trying to convince you to switch at all. Choice of editors is just a matter of personal preference.
I'm just pointing out that all the features you've listed as lacking in Vim are built-in, widely used, and documented. And of course, these features can be used at the same time, there's nothing preventing you from doing so.
Maybe discoverability is the problem. GUI IDEs make discoverability really easy with lots of menus, settings, modals, etc. which lowers the barriers to entry and learning curve.
Haha yeah that's probably close to my experience too. But I wouldn't even dare try in other editors.
My experience with vim always seems atypical when I read blog posts like this. For me it's a hard-to-kill, reliable text editor. I barely know any of the commands (despite using it for a decade) because I've honestly never felt like I was missing anything. Just having something reliably fast lets me get away with inefficiencies that are problems elsewhere. I can't stand hjkl navigation, or remember anything more complex than how to find/replace strings. But I'm perfectly happy with it just like that.
For files that big I often find myself switch back to vi. However, vi also has its limits. If the files are really huge, then grep, head, tail and awk are my best friends.
My favorite code editor by far is Vim. But I've tried newer ones over the years: Sublime, Atom, VSCode, etc. None of them seem to stick with me and I always go back to Vim. I think I've developed some sort of dependency to Vim shortcuts and on every new code editor I try I immediately install a Vim shortcuts plugin to make it feel more familiar. I still find the editors mentioned above to lack the "ease" of customization you can have with VIM. I put ease in quotes because learning vimscript is not simple, I highly recommend taking a look at https://learnvimscriptthehardway.stevelosh.com/ to learn how to do it. Thanks to that guide I was able to write my first simple plugin https://github.com/ElHacker/vim-gitstatus
I'm working on building VR applications with Unity and C#. For that task I have to say that VSCode works pretty well, it has a ton of really nice features I regularly use: like debugging unity code, autocomplete/snippets from the unity API, and my favorite Zen Mode. My biggest complain with VSCode is how slow it runs sometimes, I can type faster than VSCode refreshes which adds noise to my flow, note that I don't consider myself to be a fast typist. If they would only fix that I would be very happy with it.
To be fair I only resort to IDE's when I have to jump into a new and unfamiliar project. Once I know it well enough, I switch over to vim. Recently I got told that I might have a Stockholm syndrome. Jokes aside and all, the truth is once you learn the basic 20-30 commands, nothing will be able to match your speed.
One of the best and extremely productive programmers I have known had cerebral palsy. He typed slowly, with one finger, while holding the right hand steady with the left.
Vim and vi before it are like QWERTY keyboards: ubiquitous and productive once you memorize a 30 or so commands. I use IDEs for editing languages like Java that have a lot of dependencies but vim works for just about everything else. I don't see a compelling reason to change.
I started learning Vim in February after using VS Code/Sublime for a long time.
I wish I started learning Vim ten years ago. There's not many other things I can say that about.
Sure, someday I might switch to another primary editor or split time between a few, but learning Vim changed the way I think about editing text forever (and it's really fun).
Anyone wanting to learn vim should probably start off by learning how to use vi, and then get into vim configuration. For learning vi, you can't do better than Linda Lamb's book, which you can pick up for peanuts: https://www.amazon.co.uk/Learning-Editor-Nutshell-Linda-Lamb...
Drew Neil’s “Practical Vim” is absolutely fantastic, and really explain the mindset and way of thinking to use Vim. It’s probably the best technical book I’ve ever read...
EDIT: I use Eclipse and Visual Studio code on any sort of larger project. Learning to use code completion, embedded debuggers, and embedded test tools is what makes some programmers way more productive than others. But, vim is my tools of choice for any other text editing (oh and TextMate I guess if I have to).
"Why" is removed from posts by default, the submitter (or a mod) has to edit the title to reinsert it if it's correct. Same thing happens to numbers (10 Ways to ...). It's a quality of title thing, I vaguely recall but can no longer describe well the rationale for why "Why" is removed but I think it was to do with it being superfluous for many titles.
Funny enough, when I used a news aggregator I eventually decided to hide posts with titles that start with "Why" (along with a few others; I don't think I missed much).
I looked in Wikipedia and saw this: "In discussing the origins of vi and why he discontinued development, Joy said: I wish we hadn't used all the keys on the keyboard... I think as mode-based editors go, it's pretty good. One of the good things about EMACS, though, is its programmability and the modelessness. Those are two ideas which never occurred to me."
So the popular qualities of vi came into existence by accident...
Joking aside, I could never be efficient in vi or vim because I need to edit simultaneously as I type. In vim, I'm slowed down by the fear "not to mess up", since I have to switch to normal mode to edit before switching back to editing mode and continue to type. Or, for instance, in languages without a function composition operator (or pipes), typing out nested functions in order of application (which is not left-to-right) requires A LOT of switching between editing and normal modes just to complete the thought.
I've never been able to figure out how others find this desirable.
I hopped on the Vim train about 2-3 years ago and haven't looked back. That said, I do use VSCode with Vim key bindings more than anything. It doesn't have everything Vim does, but it does have Tim Pope's almighty surround plugin, out-of-the-box. https://github.com/tpope/vim-surround
ys2w) will put brackets around the next 2 words. That is a beautiful thing.
I'm still amazed that someone wrote a TECO macro for TECO (a line editor from the 1970's) that turned it into a screen editor. I used that macro for many years.
> The IDE can be the “Swiss Army Knife of features” and I’m glad it’s there, just like the Victorinox I keep in my backpack.
I feel like it's the opposite, vim is my swiss army knife for working with rust or cpp or python whenever I want whereas the IDE is something I open to work on specific, more complex projects where I just care about getting something done (like my homework).
IMO neither of them are really "Swiss army knives". Multitools are pretty bad as actual tools, we just use them because carrying around an entire toolbox is nuts. It's not the versatility that makes them good, it's the form factor.
If I had to compare tech to real life tools, then IDEs would be food processors: heavy, extremely good at what they do, make some things possible and other things trivial, best at scale. And vim would be, I dunno, a really nice chef's knife? But you can't serrate a chef's knife. Whatever, analogies are dumb.
(Emacs of course would be a smart fridge running emacs as an OS.)
I only recently switched (not completely) from vim to vscode while learning a bit of web dev and rust.
I like simplicity and granular control which vim provides. At some-point I had a mouseless linux box with vi-like keybinding for everything (vimperator, muttator eg).
That said, the instant compilation and error feedback developing in rust in vscode is amazing, especially while learning.
To me the biggest power of Vim is modal editing which you can now get emulated to varying degrees of completeness in your favorite editor. Whether or not a command line editor is your bag, learning modal editing and Vim keystrokes can be a huge productivity improvement and applicable to a large number of different editing environments.
Hard disagree. Modal editing makes no sense in current year. It and vi were designed for terminals without Pg Up/Down keys.[0] Looks like no End either, although there's a Home.
Times have changed. It's so awful to get used to, and the alternative is just reaching for Home/End/Pg Up/Pg Down. Gimmie a break, fam. (What's ironic is that most people I know who love vim do use those keys, so they're paying the speed penalty of not having to reach for them for nothing -- plus the million penalties of using a terminal editor, and a byzantine one at that.)
Also, ever wonder why the movement keys are HJKL and not the home row's JKL;, which would be far better and more intuitive? Glance back at that picture; for no good reason, the manufacturer of those terminals decided to put arrows on HJKL. And so, in inertial carryover of dumb design, vi's creator decided those should be the movement keys.
Sorry, time to eject from this fossilized ride from the '70s and into the 21st century.
Many many things that are important in life have little to do with computers. But the important things which involve computers are usually text based. You edit them with a text editor.
IDEs, at their best, edit one family of languages. At their worst: Java. They do that very well, but general purpose text editors they are not.
I recently saw Gary Bernhardt's video on Typescript(so not related to Vim) but I was astounded at his Vimfoo skills. Looks like magic.
https://www.youtube.com/watch?v=GrnBXhsr0ng
I'm a new gen vim user, defined as in having lived a shorter time then vim itself.
the learning cliff is significant, I've spent a whole month doing everything in vim to burn everything into muscle memory, and once that period is over, it becomes self reinforcing.
The payoff is significant, I don't leave the terminal to go to some graphic IDE anymore, unless it's Java. And my vim setup started to look more like an IDE - but an IDE that comes with the full power of vim and it's different modes. Once you get over the initial excitement over keystrokes, you'd realize that modal editing is actually the biggest draw.
People have different preferences, but for me, vim has been absolutely worth it.
How can someone learn how to use/how to tweak Vim to its full capabilities? Coming from someone who does minimal tweaking on their environment beyond theming, I enjoy using Vim but always feel like I'm barely scratching the surface.
Regarding usage, you should start with the built-in vimtutor tutorial (separate binary which was most likely installed alongside vim). From there, read the manual and start looking at resources like vimcasts.org, /r/vim, _Practical Vim_, etc. _Learn Vimscript The Hard Way_ is also a great resource, but heavy on Vimscript, which you may or may not need on a regular basis. I'd argue it's worth taking a crash course so that you can try to debug third-party plugins or write your own. Really, though, the best way to learn is to jump in with both feet and search for solutions when you want to do something that you don't know how to do.
As for "tweaking" Vim, I'd suggest checking out open source vimrcs, like ThoughtBot's or Steve Losh's. You should also browse vim.org/scripts and check out plugins by people like Tim Pope and Junegunn. I can't think of any at the moment, but I know I've seen analogues to ruby-toolbox.com and clojure-toolbox.com which index plugins and let you search by topics and are a little more curated and user friendly than vim.org. You may also want to consider an opinionated Vim distribution (Janus, Space Vim, etc.), which comes with non-standard .vimrc settings and plugins.
Speaking from experience, you force yourself to use it for a period of time, preferably in a time where the task load is slightly smaller than usual. After a full month and half of this, vim commands has more or less burned into my muscle memory. This did result in many useless :wqa being typed on other software but it was absolutely worth it.
The next step is to pay attention and note when you are doing something that seems to take a lot of commands or just generally be inefficient. When you notice this happening, search docs and articles to see if there is a better way to do it.
Over time, you will accrue the things you need to know to use vim effectively.
I'd start with `vimtutor` and then there are some tutorials I wrote that start from the very beginning. (I'd greatly appreciate feedback from others).
A big tip I have is watch youtube videos and search new tweaks. While learning commands add a few on a post-it note and use that for a week. After the week is over you either learned those commands or aren't using them and don't need them.
Run through the tutorial a couple times, so you learn the basics. Once you've internalized them, then start exploring the plugin ecosystem. A lot of people dive right in to customizing their vim, completely reinventing the wheel or copy/pasting configs without understanding what they do.
https://vimways.org/ is also a great resource. 'Death by a Thousand Files' in the 2018 edition is one of my favorite vim articles.
Continue like this for a few days (maybe even map the arrow keys to hjkl, like a heretic), then I'm sure you'll think something along the lines of "hmm, I wonder how you do X in vim" learn that and continue along.
one thing i love about using Vim, may only apply to using it in a text based terminal, is that the input cursor is not the text select cursor. This may also apply to emacs. Useful in many instances to select text from one portion of a document file for copy, and to paste into another, without losing the insertion point.
Over the years I've been trying different editors but they're either overly complex to configure (yes I'm aware of the irony here) or I just can't make them work the way I want. I always fall back to vim, but I never top giving them a chance.
If you're looking for multi-cursor support, you might want to take a look at https://github.com/martanne/vis. It doesn't support ctrl + click, but I find ctrl + n and ctrl + j go a very long way. For anything more complex, vis supports structural regular expressions.[^1] Those work for both replacement (as is customary) and for multi-caret text selection.
[^1]: These structural regular expressions took me a bit to get used to, but by now I really like the concept.
I use VIM on and off, but I wanted to post the above because I think it exemplifies who might like using VIM.
VIM is ideal for people who find it worthwhile to spend the time building their configuration out. VIM is the productivity tool that gets better as you put the time and effort into building it out. If you aren't the kind of person who wants to put that time and effort in, it is still decent as a basic editor, but it doesn't really shine.