Hacker News new | past | comments | ask | show | jobs | submit login
Vim Anti-Patterns (2012) (sanctum.geek.nz)
385 points by lelf 38 days ago | hide | past | web | favorite | 238 comments



Here is a trick that I used to use when I started learning VIM:

- Write down 2-3 tricks/shortcuts in a piece of paper. Put that piece of paper in front of you (ie: tag it to your screen).

- Code with Vim. You'll eventually look at the piece of paper and find some of these shortcuts helpful. So you'll use them.

- After a while, these shortcuts will get into your muscle memory and you'll no longer need the piece of paper.

- When you are coding with VIM, detect annoying patterns: For example, I need to jump code, I need to replace often, I need to be able to select some text this way, I need GIT integration. You get the point.

- Put these observations on a list. Pull 2-3 items (shortcuts) from this list and tag another paper to your screen. Pull 2-3 items (plugins/functionality) and enhance your VIM.

- After a few years, your VIM will become extremely customized. You'll actually have trouble writing code on any other IDE.

- Here is mine: https://github.com/omarabid/vimrc

Other bonus tips:

- Use GIT to keep track of your VIM configuration.

- Write a README file for your configuration. Other things that I should do: Update the README often, and add screenshots.

ps: in case you haven't noticed, I'm a die-hard VIM fan.


It's important to note the context these articles are usually presented in, and also most the responses, which is Vim for developers (or at its most general, Vim for sustained local use). The reason I bring this up is that there's a whole other set us use that is often overlooked, which is Vim as a standard tool for sysadmins.

Any system you connect to will have Vi, and probably Vim. This makes it an ideal tool for sysadmins that might need to connect to tens or hundreds of systems to know how to use, and to have a fairly standardized behavior. In those cases, having a customized config can actually be more of a hindrance, because switching from a highly customized local Vim instance to a stock remote Vi/Vim instance can be jarring.

For anyone who is primarily a sysadmin, I would recommend sticking with the default behavior (which is rich, and lends itself to being more and more useful and they become familiar with more an more commands), and making a minimum of local config changes and plugins to suit their needs (it's a trade odd. Just choose wisely). This makes life easier when you spend a significant portion of time on random stock Vim instances (and even if it only saved a modicum of time, it saves a lot of aggravation as you don't feel like you're working with missing limbs).

Then again, I've always been one to do develop scripts remotely to help with tasks (all the easier to test int he correct environment), so other people's experiences may differ. I'm primarily doing software engineering now, so I load main vim instance with a fair amount of specialization (but probably less than most).


> I load main vim instance with a fair amount of specialization (but probably less than most)

Perhaps it's just that the people who diligently curate their .vimrcs are more prone to talk about it than people who use stock or minimally configured vim. I can tell you my .vimrc right now without looking at it.

    se sm
    se hls
    se number
    se ts=4
    se sw=4
    se expandtab
It's not very exciting. Nobody ever writes a blogpost on the virtues of a vimrc that looks like this one.


Ha, I see that your .vimrc is almost identical to mine in functionality, even if mine is riddled with mostly superfluous additions and lots of comments. What you've got there though is probably what I would consider the core things I would need to set in vim to get my desired experience on a new workstation if I didn't have my own .vimrc to download, all the way down to the number of spaces for expanded tabs.

The rest of the stuff I have boils down to history size, a fixup for backspace in insert, default paste mode and quick key to toggle it, how far from margins to start scrolling, and turning off swap files so editing very large files is easier. Oh, and the Pathogen init stuff, for which I have usually have no modules installed (but I test out stuff occasionally), but there it sits.


The minimalism reminds me of http://openbookproject.net/pybiblio/tips/elkner/vim4python.p... , which was written by my CS teacher from high school, and has survived me ~10 years.


I've got a decade-and-a-half .vimrc that I stopped using last year. I used to rsync it up to other machines before I would SSH into them.

Now that I've gotten out of it, I see that there are only a few small customizations that I really enjoy, but none that I need. And I can now use VIM on any machine.


Just to make it more efficient :)

"instead of se number

se nu


I thought that this would be the case and initially stuck mostly with defaults, but it didn't really turn out to be true. You won't forget how to use vanilla vim unless you really go crazy and replace all keystrokes. Turns out you don't forget how to play clarinet after learning saxophone.


I thought that this would be the case and initially stuck mostly with defaults, but it didn't really turn out to be true. You won't forget how to use vanilla vim unless you really go crazy and replace all keystrokes.

I’ve found this to be true. I’m getting a little annoyed with the narrative that it’s best not to customize Vim much because you won’t have those customizations on the generic boxes you’re working on.

You don’t forget vanilla Vim; to me, that’s kind of the point. You’d be surprised how much of generic Vim becomes muscle memory and you do things you haven’t thought about in a while. When you become a proficient Vim user, it kinda just happens.

However, I hardly ever read anything advocating for a different approach: using Vim’s netrw support for ssh, scp and several other protocols from your main machine, allowing you to use your fully configured Vim to edit files on those machines you’re performing sysadmin tasks on.

Once you’ve configured things, you can just

    vim scp://[user@]machine/path
Obviously this won’t always be an option, but when you can, why not? Netrw is a plugin that comes with Vim, so even Vim minimalists can use it even if they have zero 3rd-party plugins installed.

It’s even in Vim’s docs:

http://vimdoc.sourceforge.net/htmldoc/pi_netrw.html#netrw-ss...

http://vimdoc.sourceforge.net/htmldoc/pi_netrw.html#netrw-tr...


I didn't mean to give the impression that you forget vanilla Vim, more that it becomes somewhat painful to use as you deal with the absence of what you've come to expect.

It doesn't really matter much whether you use tabs or spaces, or how many spaces a tab key (or tab character) represents, but having to swap between them multiple times a day gets... tiresome. There's a fluidity that comes with your tool behaving how you expect, and a time of acclimation when it changes. Whether the benefits of either keeping your config close to stock to reduce this acclimation period or highly customizing your personal Vim to be as efficient as possible is the better solution probably depends on the individual and the relative amount of time spent in each environment.

I'm not really urging one approach over the other, but rather noting that one should be cognizant of this, as it may allow for better decisions at different times. I, for one, found certain Vim customizations to be not worth the effort at one point when I was doing a lot of remote Sysadmin work, but worth investigating more when my time in Vim shifted more towards being used in one main instance.

As a simple example, if you spend 80%-90% of your time on remote servers, how useful is it to install Nerdtree on your main instance and spend the time configuring and learning how to use it well? Are the keys to Vim split windows and resizing better, or perhaps figuring out how to do that in screen/tmux is more effective a that time (can that be assumed to be on the servers?).

If nothing else, I think it helps explain why some people are so enamored of some Vim plugins, while others try them and consider them "meh".


I’ve always found it rather trivial to scp my config onto the server, initialize the package manager and have it available everywhere.


It's a matter of scale. With a small amount of servers and people expected to be on them, it's not much of a problem. Once you scale to tens or hundreds of servers, and if you have multiple admins, if they don't each get their own account, you run into problems where pushing your config may conflict with someone else's config (or you must remember to set or push ENV vars on or after login).

1 admin with 1-10 servers is not much of a problem. As the number of admins and/or servers scales up, it starts becoming much more of a problem. I've worked in environments with 1-2 admins and <10 servers, and in environments with 20+ admins and hundreds of servers. In the latter environment, if you left an altered Vim config on a shared admin account, that's likely something you would be called out for, and rightly so. If anything doesn't look right when you're called onto a server at 3 AM to fix some random malfunction that's hard to diagnose, you start grasping at it as something that needs to be ruled out as part of the problem. Irate early morning emails from annoyed sysadmins over inconsistent server state are common.


> and if you have multiple admins, if they don't each get their own account

You really should have your own account on each machine. Deploy them via some push method like ansible, or some pull method like a daily cronjob. You can push a .vimrc out with them too.


You state that as if it's a given, but I find that any increase in deployment complexity should be carefully considered. Rarely have I found "we can do this, so let's do it." a useful strategy in the end.

As a very simple example of one of one possible downside of multiple accounts, consider an admin team with a high level of account additions and/or deletions (this does not mean quick turnover, it's also easily achieved through a large enough team). How robust are your routines for removing accounts when unused? How easy is it to check that every server is in a clean state? How much does it complicate and reporting of accounts on servers that have shells assigned to them or allow login?

Simplicity has it's own benefits. Sometimes additional features are well worth the complexity cost, other times they are not. This is basically the same theme I initially stated with regard to Vim customization itself. Another way to look at it is as the Waterbed Theory of Complexity.[1]

1: https://en.wikipedia.org/wiki/Waterbed_theory


> How robust are your routines for removing accounts when unused?

For our main corporate server list (about 1000 servers and 50 users), disable account in ldap and password authentication no longer works (so they lose sudo). Takes about 5 minutes to replicate I believe. If they have a .ssh key they can still log on until the local account is disabled, which runs daily.

The 100 or so servers outside the corporate walled garden, with 10 users, simply have to wait for a day for the account to be disabled - or run a bash script from rundeck to kick it off earlier. The CRL cache-time on their client certs is longer than that in any case so it's not top priority. I last did this 3 weeks ago. We didn't want central authentication for non-walled-garden machines as there's a good chance many of them may be used offline, both via ssh and local access.

It's far easier and less error prone than having to change credentials and authorized_keys for generic accounts everytime someone leaves. You've also got the benefit of knowing who's logging in to each server, as I assume your auth.log is also fired off to syslog.

How do you prevent an ex-employee logging in without a generic account, other than changing credentials and authorized keys? I'm assuming it was a mutual termination and you don't need to worry about backdoors (because if you do, you're screwed regardless)

But forget nefarious purposes -- if you have a problem on a machine and you see that "admin" was logged on at the time the problem started, how do you know who "admin" was so you can work on the fix?


> It's far easier and less error prone than having to change credentials and authorized_keys for generic accounts everytime someone leaves. You've also got the benefit of knowing who's logging in to each server, as I assume your auth.log is also fired off to syslog.

I can write a system (and have, multiple times) that takes public keys from people in a file named by their users, aggregates them into a single authorized_keys file, and pushes it to the admin account on all the servers in a list in 5-10 minutes. Access removal is removal of their key and running a command that uses scp to upload a new authorized_key file for all servers. Using xargs and parallel jobs, than can complete within a minute or two even for 1000+ servers, errors are easily visible, any problem in the process is easily troubleshot, and if worse comes to worse and the system isn't functioning, you can manually update the authorized_keys on a few servers that need it ASAP. No LDAP config, requires, and anyone with basic SSH understanding can diagnose and understand what's required to fix an error within a minute or two. Give me another 30-60 minutes and it would support a config file with user groups and assigning group or individual access to servers.

There are features you don't get with that, but it's dead simple and very robust. LDAP is good, but if all you need is to set up admin access to Linux/BSD servers, it also might be overkill and cause the occasional headache. There's a huge range between manually configuring every server for every change and using LDAP for account access.

> But forget nefarious purposes -- if you have a problem on a machine and you see that "admin" was logged on at the time the problem started, how do you know who "admin" was so you can work on the fix?

SSH allows environment vars to be passed along with the authorized key file. You can set your default EDITOR for example, but your push system can also append a specific variable that denotes who the actual user was that connected, and your login config can log it to a file as you connect. There are simple solutions for most things you would want in this space. Once there isn't a simple solution, then maybe the value of a centralized authorization system might show itself.


> I can write a system (and have, multiple times) that takes public keys from people in a file named by their users, aggregates them into a single authorized_keys file, and pushes it to the admin account on all the servers in a list in 5-10 minutes.

The modern way to do such a thing would be using ansible, which just as easily allows you to create/delete user accounts.

While custom vim settings per user are nice to haves, the biggest benefit is AAA. I'm not sure what type of auditing you can realistically do with, you'd have to trace through machine logs to find the IP of origin for a given pts, and hope that the dhcp server still has.


Yes, any Unix-like system will almost certainly have vi available. I'm a emacs use for 3 decades but I know enough vi to make small changes to config files.

Was never able to adopt it as my main editor. The bifurcated input/command modes always trip me up.


FWIW this article specifically is mainly for common traps (e.g. spamming arrow keys) in vanilla vim.


Yes, I changed my initial sentence slightly (you can see the difference in the quote of the original that vram22 included in their reply) to reflect my real intent is to call attention to the context many Vim articles and comments, and not necessarily this specific article. I didn't append an edit note as I often do (even though it was more than an hour after initially commenting) because I considered it a small clarification of my intent, but one was probably warranted. I'll consider your comment and this reply as that edit note now. :)


I agree. I prefer graphical IDEs which plays well with my operating system for software development. However, you still need to know just enough vi in case you are remoted into someone else's computer


Ubuntu 1804 comes with vim 8.0, rather than 7.4

Not sure if it's ubuntu or vim, but it comes with some really annoying changes that haevn't been this jarring since moving from solaris-vi to the vim bundled with ubuntu (vim-nox) over a decade ago.

The two most annoying things I really noticed and massively reduced my efficency

  1) Get about 6 lines from the bottom and the cursor no longer moves.
  2) Search moves the window as you're typing
It really pissed me off


1) That’s scrolloff, `set scrolloff=0` to remove this function altogether (I keep mine set to 2)

2) That’s incsearch, `set noincsearch` to turn it off.


Oh sure, but it means having to have a .vimrc for consistency.

My own desktop's vimrc has a few useful shortcuts (F5 for example to "compile" a graphviz file to dot -T x11 -- my VB3 roots showing), but the majority of vim use across the estate has never needed it before.

Fortunately I do have a facility to distribute .vimrc to undo these disastrous changes, but changing the default behaviour was rather annoying for an editor that is so ubiquitous.


I had the same initial reaction to 2) (incsearch) at first after having to work in a shared environment with it enabled. After a little while getting used to it I found it actually sped up my workflow quite a bit! YMMV, but you may find it worth the time to leave it on a little longer and see if it works for you.


I do a lot of sysadmin stuff and go crazy when I need to do anything except copy/paste, and insert. I really want to sit down and learn vim for those tasks but usually just end up opening nano and going about my business.

One problem I've found with vim is some weird character buffer thing happens where my text stops displaying or something. I've never investigated it but its probably SSH itself.


Do you accidentally press Ctrl+s to try and save? That tells the terminal to stop sending text (eg if a long command output was scrolling by). Try Ctrl+q to fix it next time it happens.


It is entirely possible. I'll have to be more cognizant next time it happens and catch myself if that's the case.


I believe this fixes that behavior while vi is open: https://github.com/fiddlerwoaroof/dotfiles/blob/master/zsh/z...


Newer versions of Nano actually do save the file on CTRL+S.


Didn't pico as well?


I do not understand the:

"don't customize your VIM, what if you have to use vi/vim on a server?" trope.

I submit that if you're having to log into individual servers enough to make those kinds of changes, you're already engaged in a systems management anti-pattern.

Code up some CM/automation to handle that.

You can probably write that code from your workstation, with your more customized Vim. :-)


Well, part of the reason you are having trouble understanding it is that you've simplified it all the way down to a trope, which necessarily misses a lot of the nuance of what I sad. I mean, I don't even agree with "don't customize your VIM, what if you have to use vi/vim on a server?", so why would I expect anyone else to?

If I had to distill my point down to a sentence, it would be "be cognizant of your tools and their usage paradigms, and whether large customizations to one paradigm and how it might affect the overall usability, or your perception thereof, of the others."

Yes, it's wordy, but that's simply because not everything is easily reduced to a pithy one-liner, at least not without a large loss of context.


I don't think I'm missing any nuance.

You wrote:

> For anyone who is primarily a sysadmin, I would recommend sticking with the default behavior

Am I reading that wrong?

"Don't customize the default behavior if you're a sysadmin"

Do you not agree with what you wrote?

I'm simply arguing that, as a sysadmin today, you're far better served eliminating the need for N node access to make changes, and using your customized local config to push changes to a repository that is applied by a CM-esque system.


The entire sentence was (including typo of "trade odd" instead of "trade off"):

For anyone who is primarily a sysadmin, I would recommend sticking with the default behavior (which is rich, and lends itself to being more and more useful and they become familiar with more an more commands), and making a minimum of local config changes and plugins to suit their needs (it's a trade odd. Just choose wisely).

The key (corrected) part you're missing is "it's a trade off. Just choose wisely." I go into more detail on that in subsequent comments to other replies.

> I'm simply arguing that, as a sysadmin today, you're far better served eliminating the need for N node access to make changes, and using your customized local config to push changes to a repository that is applied by a CM-esque system.

That good for many things, but not really an adequate solution for diagnosing a problem under stress.


>It's important to note the context of this article, and most the responses, which is Vim for developers (or at its most general, Vim for sustained local use). The reason I bring this up is that there's a whole other set us use that is often overlooked, which is Vim as a standard tool for sysadmins.

>Any system you connect to will have Vi, and probably Vim. This makes it an ideal tool for sysadmins that might need to connect to tens or hundreds of systems to know how to use, and to have a fairly standardized behavior. In those cases, having a customized config can actually be more of a hindrance, because switching from a highly customized local Vim instance to a stock remote Vi/Vim instance can be jarring.

That's a great point. I had mentioned something to the same effect, briefly, in the blurb for my vi quickstart tutorial, here:

https://gumroad.com/l/vi_quick

I first wrote that tutorial at the request of a couple of Windows system admin friends of mine (at a company where I worked earlier), who were tasked with managing a few Unix boxes, without knowing Unix. They used the tutorial and later told me that it helped them to quickly start using vi to do their work on those boxes, including editing config files, simple shell scripts, etc.

Edit: Since vi is mostly a subset of vim, the tutorial works for vim too.


Regardless of customization points, I find using Vi after Vim quite confusing.


if you dump your customizations into github you can customize on whatever server pretty quick. or at least some subset of your settings that would be safe to pull down on the servers you work with.


> - After a few years, your VIM will become extremely customized. You'll actually have trouble writing code on any other IDE.

How is that a good thing? That's the major reason I typically do as little configuration as I can to the software I use.


Because it’s your flow. I’m an emacs user and it’s the same sort of thing. At the end of the day I’m just a lot faster at the things I want to do because of the practice (learning what it can do) and customization (making it do what I need to do). Learning random IDE #25 for an employer just slows me down. Imagine if I made you use Dvorak (or QWERTY if you already use Dvorak) just because. You’d crawl. Unless the IDE brings a lot to the table, the thing I need most is the editor part. So I want it to fit me and my flow.


I think specialization can be a good thing. With tools, specialization can make you faster and more effective for a variety of reasons. It is, however, a tradeoff with flexibility as you've pointed out. I think the balance we strike here is very personal and might have a lot to do with ones daily workload.


> After a few years, your VIM will become extremely customized. You'll actually have trouble writing code on any other IDE.

This would actually be a significant detriment to many Vim and vi users who do system administration, because they can't rely on any customization when the drop into a terminal on a random server.

The one thing I really wish the browsers would adopt is a reliable vi/emacs toggle for text entry windows. Vimium, vimperator, etc, they're never reliably available, always at the mercy of the upstream browser.


If you just want a vi/vim toggle for your browser, wasavi[1] is what you're after.

https://github.com/akahuku/wasavi


On the other end, here's my plugin-free vimrc: https://github.com/hoffa/dotfiles/blob/master/.vimrc

I work on a bunch of servers from various devices and want zero friction when moving around. It also conditions me to be efficient and comfortable, even when everything is not perfectly aligned to my sensitivities.


This is almost exactly what I did while learning to use Vim over the last month.

I ended up having 7x sticky notes around my monitor with around 80 commands and motions written down after the first week.

Now 1 month later, I don't use them and have about 80% of the most used things memorized. It's not 100% brain dead automatic yet, but most come to me in a few seconds.

Current vimrc[0] is sitting at about 40 plugins and every single one of them came from a direct need.

[0]: https://github.com/nickjj/dotfiles


Another tip: For ed commands (the ones that are like :something) spell them out initially, for example use :substitute instead of :s.

It's much easier to remember and you can use autocomplete anyway. Once you have the command down you can start to abbreviate it.


I am more an nvi than a vim person but unless there was a significant change the : commands are ex not ed.

I mean yes in principle their roots are in ed but ex is the command line editor mode of vi since it's inception


> - Use GIT to keep track of your VIM configuration.

My question is: Why?

I use git quite exhaustively for my daily job, I also have my vimrc git-tracked on github, but TBH I cannot really see the point anymore :-)


Does anyone know of any good refactoring tools for Python? I've been casually looking for a bit and haven't found anything that I really like yet.


After ~2 years of switching between using and not using vim you have convinced me to try and make my own config


2 biggest things for me were vimplug (or something to make plugin installation easy) and NERDtree, which lets you open a window for directory navigation, set bookmarks, and change your current directory path for other vim commands.

I'm also super partial to Hydrangea scheme https://vimcolors.com/690/hydrangea/dark That site is good for browsing for something you'll like.


I recently made my own vim config. It was very easy and wish I had done it earlier.


Try github.com/amix/vimrc to start off. It has a nice look. You can then add more shortcuts/customize further as you gain more experience with vim.


Any tool you need to use more than a few times is worth learning properly. And any superior tool is worth switching to and learning if you would use it frequently.

I suppose it depends on how one's mind works. If the mind moves slowly and holds onto ideas and abstractions easily, then the slower motor movements of moving the hand back and forth from arrow keys to home keys, and to mouse and back, are not really a problem. But if you're like me, and your mind is constantly racing, you need to be fast to get your ideas out before they're gone/replaced.

It's not just the time cost of moving the hand from home row down to find the correct cursor key, do the presses, and then move back to typing position - it's also the likely visual/mental cost of looking away from your screen to aid in positioning the hand, then looking back at the screen and finding what you were looking at before. All those movements and recalibrations take time and involve mental context switches.

If you're spending a lot of time using a certain set of tools, there is no reason to avoid learning those tools well. Refusing to do so is choosing to be ignorant and subperformant.

Now, if you'll only use the tool once in a while, perhaps it's not worth the effort. But chances are, there's some other tool you use often that you could master for your long term benefit.

If you program, Vim (behavior) is very difficult to beat for getting whats in your head out and into your computer VERY quickly. As a bonus, using a full featured IDE like one of the JetBrains products, but with the Vim plugin, is win win. You get the code editing speed of vim, plus the project navigation and other benefits of the IDE. Totally worth the time investment.


> ... But if you're like me, and your mind is constantly racing, you need to be fast to get your ideas out before they're gone/replaced.

I write extremely fast and use arrow keys (and all kinds of vim shortcuts).

> it's also the likely visual/mental cost of looking away from your screen to aid in positioning the hand

I never look at my keyboard when using vim.


There is absolutely no way you can move your right hand to the arrow keys faster than I can hjkl move in Vim.

I don't even have to move to reach the ESC key because I use ctrl-[ instead. Even if you have perfect memory and perfect motor control to enable hand repositioning, just the act of moving the hand from one location to another and back will cost time that "power" vim users don't waste.


So what? How does saving a few seconds or even minutes per hour while writing code really make an impact at the end of the day? I spend way more time reading code than I do writing. As a vim user who uses hjkl sometimes and the arrow keys other times I am still well employed, my boss has never complained I waste a fraction of a second reaching for a key. If you work an environment where every second matters to that degree I feel sorry for you son. We're programmers, not elite athletes. A tenth of second doesn't matter here IMHO.


Using vim is not at all about the number of milliseconds saved, it's about lack of interruptions. An expert vim user can get into a flow state and be moving and jumping around the file, adding and deleting text, without stopping to think about how to do a command in their editor or worse, having to reach for the mouse and figure out where the cursor was left last time.

For some people, having your flow state disrupted can cause a very long delay as you have to figure out what you were doing all over again.


I should count my lucky stars that my flow state is not interrupted by having to move a mouse an average of once a minute.

I'm all for people using the tools they want, and I can see the appeal of a highly customized environment you know well, but I struggle with this logic I always hear treating the mouse like some sort of world ending interruption to text input.

At that point does a sneeze interrupt your flow state?


Looking at it from another angle, I've got a suspicion that continually moving your hand from a typing position to use the mouse with a different (more of a claw) hand shape probably contributed to the rise in RSI.

When I started my career, it was the tail end of the era of the Typing Pool in large companies... when a room full of clerical people would be hammering away on electric typewriters for a full working day, but not dropping like flies with cases of RSI. So perhaps staying near the home row perhaps has other advantages.

I try and use Vim keymaps whenever possible with the dev tools available to me, and to keep hands on the keyboard whenever possible. I certainly notice less fatigue than the old days when I used to type, mouse, type, mouse.


> Looking at it from another angle, I've got a suspicion that continually moving your hand from a typing position to use the mouse with a different (more of a claw) hand shape probably contributed to the rise in RSI.

On the other hand, I always thought the opposite.

My hands fly around everywhere. My right hand goes from the main keys area to the home/end/arrow keys and the mouse pretty frequently. I keep my forearms perfectly parallel to the ground with close to 0 resistance, then I mostly use my shoulder and elbow to move my forearms, which leads to my hands being in a different spot.

I also never strain to reach any combo because I just move my hands instead of trying to break my wrist to press something like tilde + g with my ring / pinky and pointer fingers.

Been doing this for 20+ years and I have no arm, wrist, hand or finger pain and this is with years of gaming abuse where I was clicking and doing repeated key presses for 12+ hours for entire summers back in the day.

But if you ask me to type with my hands on the home row, I feel a very unnatural strain on the top of my hand when I move my fingers. After a minute it's painful. I dunno how anyone can do that without injuring themselves.


I suspect that’s better addressed by looking at the ergonomics of your setup.

Typing can also cause RSI, and in fact if you look at the risk factors for RSI, way more boxes are ticked by keeping a mostly static position on a keyboard than with occasional movements of a mouse (especially the parts about leaving pressure on part of the body)

I’d also imagine typewriters are very different from normal keyboards in usage, and typists were very focused on ergonomics

There’s also the fact that RSI probably wasn’t as commonly diagnosed as it is today.


"At that point does a sneeze interrupt your flow state?"

Given that it is an involuntary spasm, then yes, it does.


I mean I can usually tell if I'm about to sneeze, it doesn't just sneak up on me like a seizure... I even cover my nose in anticipation subconsciously, I don't think a normal sneeze has ever interrupted my conscious thought...

But alright, just sounds dreadful I guess, to be unable to stay in flow due to the most minute actions or occurrences.


When making code changes feels quick and effortless, I think you become more willing to try out different things and experiment, which ultimately enables you to learn your languages and frameworks faster and make better choices. When code changes feel arduous and time-consuming, you're less inclined to experiment and more inclined to tolerate unknowns and best-guesses. I think vim helps push things towards the former scenario.


Ok, I edited a file in a meaningful way and tried to decipher the process (actually it become more of a normal workflow more than editing a file).

The thing is I switch all the time between vim and my terminal (it's complicated by let's say I mainly use one terminal tab for everything I'm currently writing) so using the home row I would have to switch all the time between home row and arrows when using the terminal (and other programs) (I guess I could add vim bindings to every single thing I use: web browser, terminal emulator, pry, irb, tmux, etc etc. but doesn't seem appealing to me).

The escape key isn't an issue either because I don't use the home row, so no need to remap that too.

I think this misconception comes from the manual pushing people to use the home row.

I don't claim I'm the fastest writer ever, but there are a lot of compromises I'm not willing to make (I could use vim tabs/windows, I could use Ctrl-D to switch files, I could use GVim, have the main files always open, etc.). I'm pretty sure everyone works differently and this workflow works very well for me.

What I don't like is this constant shaming of arrow vim users and people that keep saying it's only for beginners (and the manual pushing people to use the home row).


It might be worth learning the readline keybindings. They are supported rather ubiquitously in all terminal shells (including REPLs and SQL prompts and such). If you use MacOS they are supported across the entire OS.

You can also adopt these keybindings inside vim with the tpope/vim-rsi plugin. This approach has been quite effective in my experience.

http://readline.kablamo.org/emacs.html


> The thing is I switch all the time between vim and my terminal (it's complicated by let's say I mainly use one terminal tab for everything I'm currently writing) so using the home row I would have to switch all the time between home row and arrows when using the terminal

Starting with version 8.0, vim has a :terminal command which will open a new split window with a terminal. You can switch between the terminal and other vim windows using ctrl-w j, ctrl-w k, etc. You can enter normal mode in the terminal using the ctrl-w N key combination. In normal mode, you can scroll back and copy text into a vim register of your choice (default is "). Then you can either paste it in another window like you normally would, or you can paste it in your terminal by pressing i to return to terminal insert mode and pressing ctrl-w " " (where the second " is the name of the register that contains the yanked text you want to paste).


Are you a touch typer?


It's just micro-optimization that doesn't matter.

Thinking that you require perfect memory to use arrow keys while programming is just hyperbole.


> As a bonus, using a full featured IDE like one of the JetBrains products, but with the Vim plugin, is win win.

I refused to use Visual Studio for code editing until ViEmu came along. These days I use VsVim. vi is fantastic for editing/writing and using the other niceties of Visual Studio is a win-win, as you said.


This cannot be overstated. 90% of the advantages of VIM is the modal editing interface, which can be used beautifully in Visual Studio, Visual Studio Code, IntelliJ IDEA, and other nice IDEs.

The VIM way is a very good way of editing text. IDEs offer a lot more than editing text. Faking an IDE within a text editor with random plugins is terrible. Emulating VIM text editing within a real IDE is amazing. Just use VIM keybindings in your industry standard IDE, you will be able to use all the tips in the linked article and still not miss out on anything offered by the IDE.

The only problem is that the VIM keybindings are integrated into direct text editing, but not the IDE UI. For example, in Visual Studio, IntelliSense offers you a choice of possible completions for a variable name you are typing. You can only navigate these choices with your cursor keys, rather than with the VIM-style jkl; keys. But it's a small price to pay for really good text-editing qualities!


> You can only navigate these choices with your cursor keys, rather than with the VIM-style jkl; keys. But it's a small price to pay for really good text-editing qualities!

I have ctrl-j and ctrl-k mapped to down and up on my keyboard for just this reason. If you have a keyboard that supports macros it's easy to do and it works for all those annoying places in Visual Studio and the rest of the OS you need to use arrow keys for.


There is a loss though, which is that Visual Studio is incredibly slow, and editor latency has "important effects on typist behavior and satisfaction" [1]. You wouldn't want to use Visual Studio to edit a single config file, unless you already had it open for a big programming project. Adding a Vim binding plugin makes things worse and often introduces a startup delay before the editor enters normal mode, meaning your first command gets typed into the file unless you pay attention and wait for the UI to get ready. Vim opens even ridiculously large files that have no place in a text editor instantly, every time.

[1]: https://pavelfatin.com/typing-with-pleasure


I use vim every day. I only know i, /, :q!, And :wq. If I am actually creating something I'll use Atom, change it to LF, and paste it into Putty when I'm done.


These are excellent. I didn't know about gi, and that's very useful.

Today I accidentally learned that ctrl-a and ctrl-x increment or decrement the number under the cursor. That's not terribly useful unless you're dealing with a lot of numbers, but if you are, it will save a lot of keystrokes.

One set of movement keys the article didn't mention but which I use all the time are H M and L (shift-h, etc.) They jump to top (high), middle, and bottom (low) of the editor window, respectively.


Even better you don't have to be with the cursor on the number you want to increment or decrement with Ctrl-A and Ctrl-X. It will work with the next number to the right of the cursor.

The same goes for ci' or ci".

a = 'foo' // imagine the cursor on the letter a

Executing ci'bar will change foo to bar.


> Even better you don't have to be with the cursor on the number you want to increment or decrement with Ctrl-A and Ctrl-X. It will work with the next number to the right of the cursor.

To the point that I have used c-x c-a as a stupid shortcut to jump to the next number on a line. I'm sure there's a better way to do this, but it's fast so...


Surprisingly, there actually isn't an out-of-the-box way to jump to numbers that I know of!

I personally added a "number" text object, so that I can treat numbers just like "words", and also created a "jump to number" shortcut.


And just for completeness: ci' and ci" replace everything within the quotes, ca' and ca" replace everything including the quotes.


Wow! Thank you.


> That's not terribly useful unless you're dealing with a lot of numbers

Make no mistake: that is terribly useful, even if you're not dealing with a lot of numbers. You just found out about it so maybe you haven't realized it just yet. The mere fact that it accepts a count (i.e. 10<C-X>) and it's repeatable with the dot operator makes it a killer feature.

To make the shortcut smarter and able to deal with dates and times I recommend vim-speeddating by Tim Pope:

https://github.com/tpope/vim-speeddating


Even more useful - it works flawlessly with octal and hex, detected by the 0 and 0x prefixes respectively.


Check out https://github.com/zef/vim-cycle to extend Ctrl-A/Ctrl-X to arbitrary groups of words, e.g. to cycle between true and false.


Cool to come across this linked here! That’s turned out to by most popular bit of open source code.


It really is an awesome plugin, very simple but such a timesaver :) Thanks for all your work!


There's a similar set I use often alongside those three: zt, zz, and zb. They scroll the buffer so the cursor is at the top, middle, and bottom.


ctrl-a is the most useful in a macro, for example if you want to increment a number on the next 100 lines.


Or implement fizzbuzz


Ctrl-[ is a good replacement for escape but I've found it's not always supported in every vim implementation. If I remember correctly it doesn't work in the visual studio vim plugin.

Binding something like JJ to escape is also a good solution, but if you ever have to edit on another machine without your vimrc, your speed will seriously suffer. I try to not change/add any core hotkeys for this exact reason. I can ssh into a brand new Linux install and edit with stock vi at the same speed as on my development machine's vim install.

I discovered that Ctrl-C is another default escape alternative. It's worked on everything I've tried so far: vi, vim, nvim, gvim, vim over ssh, vim for visual studio, vim for IntelliJ, etc. This is what I've gotten used to using. Another benefit is if you're using a non-vi editor and try to exit insert mode out of habit, Ctrl-C won't actually do anything, whereas Ctrl-[ could be a hotkey in that program and JJ will obviously insert two unwanted characters in your document.


Ctrl-C will keep certain events from firing in vim (can't remember their names off the top of the head, something like OnInsertLeave).

Remap caps lock to escape on your computer and it'll work in every editor and every machine you ssh into.


But I'm using Caps Lock to type Ctrl-C!


Caps Lock :)



Who cares? As long as you can edit text and it doesn't get in your way it's all fine. I can switch between using vim and vscode without any problems.

I don't use vim to its full potential and I never will, I don't know many vscode shortcuts either. I'm not a typist, most programmers should spend more time thinking than typing anyway.


I've noticed the people who work to master the tools of their trade are also the people who master the trade itself. I've yet to meet someone who mastered the trade without also mastering the tools they use.


I must say I disagree. Having some control over the tools is certainly of benefit. Yet my experience certainly was, that the greatest people I met were sometimes surprisingly slow with the tools they used.

This is because what really seems to matter is their prespective at things and what decisions they take then. Sure knowing their tools inside out will make them faster, but it is not the KEY thing of why you would take them over every other person. Unless of course your job very focused on these tools (e.g. hand crafting etc) and even there knowledge often trumps tools.

Tools are just tools. If you look at a Cameraperson at a movie set, you will see it even more so. A young guy who knows that 50k€ Arri Alexa inside out might be ending up making worse images than that old fart who just knows where to put it and how to press record. That young guy would be a perfect camera assistant tho. Making pictures is not the camera, just like writing code is not the editor.

If I manage to get to the same thing as you, it doesn't matter if I use notepad.exe, a typewriter or pen and paper, unless it takes me ten times as long. But nearly none of the time consuming problems I had with code were ever due to the fact that my editor slowed me down, but rather that I wasn't aware of parts of my code.

I aknowledge however that people are different, and maybe it could be distracting if your editor is to slow depending on the type of person you are. I also like smooth workflows where things don't get in my way also in vim, but there is a threshold above which it bascially won't matter anymore.


From my experience, people who are good at their trade tend to know their tools very well. They may not use the best tools, but they use the ones they have to their fullest. The people who aren't very good at their trade but want to appear like they're good use the flashiest tools, but they don't know those tools to their fullest. They may know of a lot of the features, but they don't use them consistently.

It doesn't really matter what tools you choose, provided you know them well and they're well suited for your work.


Now that I gave the whole thing another thought, it might be very different for different professions.

Maybe we also got it upside down? What if experts tend to be good with their tools, because they had a ton of experience with them and not the other way round. So they are not experts because they use their tools well, but they use tools well because they had a lot of time spent with these.

That is, if you are in a profession were the tools stay the same. The sound mixers I mentioned certainly know SOME workflows inside out, but mixing desks change and differ between manufacturers, get more modern etc. That means judging a sound mixer purely by his ability to handle a certain mixing desk on one point in time might not be completely representative of the man/woman’s abilities.

For programming it is much the same. A perfectly guru programmer could have switched to vim just months ago, while anoob could have invedted a year into learning vim instead of gaining experience with code.


Skill of your too directly impacts your ability to complete a task. If you struggle to prep food for cooking, you're going to be slower and probably less effective than the master chef who doesn't even have to think about how to dice.

But I'll agree with you in this way - there are a lot of people who want to just get good at their tools (huge vimrc that's mostly unused) and don't care about how well they actually write code. I think it stems from procrastinating.


> If you struggle to prep food for cooking, you're going to be slower and probably less effective than the master chef who doesn't even have to think about how to dice.

This analogy is not good in that prepping is a major part of the complete task. To fix the analogy, consider the same scenario, but prepping now takes only 2 minutes per complete meal and can be cut down to 30 seconds given years of training.


Text editors, though, are really only one tool. There's plenty of different "tools" and other things to have a mastery understanding of, and I've never seen any proof that you need to be a vim golf pro to write amazing code. If that was the case, clearly our interviews should be all about text editing ;)

In all seriousness, I personally see marginal at best benefit to getting better at text editors. I do occasionally learn things that improve my workflow, but I prefer to spend time on other things, there's enough subjects I'll already never know as much as I'd wish about...


This is one of those things that looks like it make sense but it ends up being shallow wishful thinking.

Learning every nook and cranny of your editor is just a waste of time. As an old advertisement said "It's a tool, not an art form. Why are you wasting your time learning it"

Tools should get out of the way. I like Vim but I'm not going out of my way to do something that I could do more easily in another editor or with another tool (or just do manually).

Your code is not going to be 10x better because you know some extra Vim or Emacs magic. Even those powerful "do all" Java IDEs, while very helpful, don't write the code for you. There's no magic, miracle or hidden power there. It makes some things extremely easy but it won't write the code for you

Learn it if you like but don't expect any epiphany coming from it.


The problem is you can't do those things more easily. The GUI has tricked you.

But think about it this way. Leaning your editor in full and taking advantage of what it offers -- no matter what editor your chose is ensuring that tool gets out of your way.

There are a lot of tedious things when editing and writing code. And by using your editor to aid, you get a lot of advantages.

1) you can do it in less time. 2) the chances of making a mistake on something repetitive goes down when you use your tool to aid you. 3) Using the editors advanced features can often make boring task fun.

I also think you are slightly wrong. While not 10x better code. I expect the code coming from somebody who uses their editor in full will produce better looking more consistent code.

EDIT: removing snark.


There are many things that a good IDE can do automatically which would require a lot of configuration for Vim.

Sure, you might be willing to spend that kind of time configuring your editor, but most people just want to do their job and get on.

It's the same reason most people don't use Arch Linux or Gentoo even though they might be arguably superior–not everybody wants to spend their spare time editing config files.


You seem to think GUI tools are somehow inferior to text based tools.

I wonder how many people would still vouch for Vim if they spent as much time learning a modern editor as Vim. But frankly, I don't think it's possible to spend as much time configuring any other editor as much as Vim, since most editors can do out of the box what hundreds of lines of .vimrc can't accomplish.


I would say that notepad-like text editors and IDEs are the ones the get in your way. It's not a big deal, but you do spend a lot of time just trying to move the cursor to the right spot, character by character.

It's like you want to e.g. "change what's inside those parens", or "just open a new line above this one". Vim has those exact commands.


I've seen (very) competent programmers at varying degrees of tool mastery. If we're talking text editing tools at least.

I don't consider text editing speed that important to my programming productivity. I like things that help me comprehend code, like syntax highlighting and being able to easily jump to definitions or a tool tip telling me what arguments a function needs.

This is not directed at you particularly, but when I see people say they are faster at navigating the cursor with hjkl than the arrow keys, I can't help but roll my eyes. I'm pretty comfortable with navigating text in Vim. It's great how little strain it puts on your arms to not have to reach for your mouse. But overall the mouse is such a superior pointing device, and I have to use it for tons of other stuff anyway, that I feel like I'm putting a lot less overall strain on myself by using a "normal" modern non-modal editor.

I've used Vim for years. But after forcing myself to learn to use the mouse for text editing tasks, I'm actually in the Zone a lot more often. I almost feel like a 10x-er in comparison to my Vim years.


I know several great programmers who use Notepad. I'm pretty decent at what I do and I use whatever is handy (from vim to IntelliJ) and I can't say I have mastered any of them. And I just don't care, maximum speed is of little interest to me, quality is the important thing and the editor has little to do with that.


I know several great programmers who use Notepad.

...and now you know another one ;-)

A lot of others are very surprised when they see me work without using any IDE, just multiple text editors and terminal windows. I don't need syntax highlighting or any other fanciness like autoformatting; in fact I find them distracting. I use Notepad on Windows and Vim elsewhere, and on the latter have Visual Studio only for its debugger (but will sometimes use WinDbg instead.) I believe much of why I do this is because I started without any IDE, sometimes even writing lots of code by hand on paper and thinking about it before entering it into the computer. When IDEs became available, I didn't see much point in changing my workflow.

Contrast this with some coworkers who have such a plugin-ful IDE and are so accustomed to using it that they'd rather wait upwards of half a minute to open a source code file than browse to the file in the filesystem and open it with a text editor. These same coworkers also complain about why their machines are so slow...

I wonder if those others you know also started the "old school" way.


Whenever I use Notepad for quick edits it trips me up with its lack of Unicode support and inability to handle Unix-style line endings.

I've tried to write (i.e. read) code without syntax highlighting for giggles, too. But I felt like it really slowed me down (i.e. cost me more energy to focus).

You know there is a middle ground between Notepad and Visual Studio, in various places on the spectrum, right?


Notepad also has an undo "queue" only one level deep. When I last used it I found that very frustrating, particularly in a non-modal editor where it's not clear what counts as a single change.


> quality is the important thing and the editor has little to do with that.

If you consider that the final outcome of any programming exercise is a text file then yes, any editor can be used to produce that file.

Also the quality of the code found in that file is entirely dependent on the quality of the programmer and not the editor used.

However, what a good programmer's editor brings to the table is the ability to produce that same code in a shorter period of time.


I agree partly. People who master the tools seem to always enjoy and master the trade.

But, there are people who enjoy and master the trade without mastering the tools as well :)


I have not noticed the same thing. I think it's not black or white. People who use certain tools a lot often become quite familiar with them, so maybe you've noticed that?

But it's not like when VS Code released, all the vimzards who went to use it suddenly became awful at their job.


Semes to me that the mastery of a text editor doesn’t have an impact on your end product in the same way that the mastery of the chisel does for a woodworker...


I draw almost precisely the opposite conclusion.

Having used both vim and chisels, with varying degrees of mastery.


Thats because you can’t press “u” on a chisel. It’s a single mode auto-saving tool. I’ve got a job at home that needs a chisel and I’m quite weary about doing it, knowing if I screw it up it’s a problem. git checkout — . won’t save me.


Agreed completely. There are few great songwriters who can't play an instrument, few great mathematicians who don't know arithmetic, few great golfers that don't understand how to hold their clubs, etc.


We're not talking about the basics. We're talking about mastery.

Many great musicians haven't mastered their instruments because many styles of music don't ask for it. So that analogy is arguing against your own point.

Great a great golfer is more or less synonymous with being good at golf. A better analogy to text editing and programming would be a golf player being obsessed with caddies.


Moving cursor using arrow key vs using hjkl is no way comparable to not knowing arithmetic. That's like some fanboy comparison.


I'm not worried about using the arrow keys or anything in particular. I don't even think vim is an especially good program. But whatever tool you use you should be effective with it. All the comments insecure about vim practices are missing the point; using your tools effectively is worth it and is a highly transferrable skill. If your weapon of choice is a magnetic needle and a steady hand, I expect you to be able to write code in cursive forward and bakcward all over that disk like there was no tomorrow.


Ain't nobody got time for that. Pareto principle, my friend. I'm here to get the job done.


Your 20% may not be everyone else's 20%.


My observation is that masters prefer simple tools.


Sure but there are so many tools that you have to be selective about what you are mastering. Also, great tools are easier to be mastered.


Those who master language and domain live outside of tools and don't need them but use them for speed.


>Who cares?

Some of us do. Else we wouldn't be used Vim in the first place.

You can "edit text and it doesn't get in your way" in nano or 1000 other editors too.


Busybox doesn't come with nano.


Most programmers never had to use busybox.

Especially the kind of programmers that take an issue with vim for being arcane.

And even when they have to, its trivial to extend to add nano or whatever.


I'm saying that vi is ubiquitous, not that I use busybox constantly or find vim arcane.


Its not just about speed.

To me just doing something repetitive is annoying, and reducing that annoyance is just a nicer experience, regardless of speed.



> @@

Something somebody once showed me was

    noremap <Space> @q
With this, you can quickly record a macro to the q register by typing qq (and q a final time to end the macro.) Subsequently with that binding, pressing the space bar will execute the macro once.

With this binding I find myself making sometimes dozens of throw-away macros an hour.


> Ctrl+F — Move forward one screenful.

> Ctrl+B — Move backward one screenful.

Why use such obscure combinations instead of standard PgUp / PgDn? I find this bend on "make vim usage super fast by using completely obscure keyboard shortcuts for common actions that already have designated keys" not to be helpful at all. Such kind of micro-optimizations are not really what increases productivity.


The same reason we use all the other Vim keyboard shortcuts - to keep the hands on the home row!

I can ctrl-f way the f faster than someone who has to move their right hand down or over to the pgdn key.

I once read a great explanation about programming language wars. The author described a ladder of awareness, such that some languages were lower on the ladder than others. The idea was that programmers who knew languages at or below their level on the ladder could easily see the people below them and recognize that their languages were inferior, but they were unable to see the superiority of the languages above them. Of course the superiority of a language is somewhat subjective and largely dependent upon situation, but the concept is quite valid.

Do you use the mouse to click menus, or do you occasionally "cheat" and use a ctrl-c, ctrl-v, ctrl-s, whatever? If you use those keyboard shortcuts, why not other useful ones?


I use many keyboard shortcuts, but I prefer natural usage, such as arrow keys for one symbol / line navigation and PgUp / PgDn for page navigation. The home row issue doesn't really bother me. Heavy focus on home row that forces such kind of shortcuts seems a bit extreme for me personally.


I take issue with the wording "natural usage", as there is nothing that is "natural" about keyboards.

At least not in the sense that someone would "naturally" rather grab things with their hands rather than their feet.

This is why to me neither ctrl-f nor PgDn are natural, and anyone can choose one or the other. Ultimately they were both created by someone who saw the need to have a shortcut to move one entire page down.


I wasn't aware people were being forced to be mechanically efficient. It's an option. You're free to drive your mouse all day if you like; in fact, you could mouse select, right click copy, mouse click the cursor to a new spot, right click paste, and be totally free of the burden of the home row.


"The right vim way" proponents can be very opinionated about it, and view those who don't follow same approach with a bit of conceit. I'm not saying that always happens, but I've encountered such views. Not sure why this affects specifically vim and not other editors.


I suspect the real reason for using these key combinations is that they are original vi commands as developed by Bill Joy in the late 70s. Most likely, his keyboard didn't have PgUp or PgDown keys.

The same commands also work with the `less` pager -- and they're specified in POSIX for the `more` pager: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/mo...


Yes, that most likely is the reason, and not the home row focus like it's often portrayed.


Bill Joy's ADM-3A indeed had no PgDn nor PgUp keys.

* https://vi.stackexchange.com/q/9313/19613


Two laptops never have PgUp and PgDown at the same place, while Ctrl, F and B have consistent locations.


I guess on laptops it can be useful. I prefer to use a full keyboard to avoid this kind of mess.


Full keyboards also commonly differ. There are some that have that little island of keys as 2 rows and 3 columns of normal size keys, then there are those that are 3 rows and 2 columns with a delete key that is twice the size of the others, then the keyboard at my work is 2 rows of 4 columns with an up arrow key between page up and down. I admit this last one is a little more unusual, though.


Sure. I find Unix layout useful, though it's hard to find such keyboards, besides may be Sun Type 7 these days, which are already out of production as well and have become a rarity.


The same bindings work in less, manpages, and git diffs. They're not obscure.


So ... in less, in less, and in another way of invoking less, then. (-:


Speak for yourself, my MANPAGER is vim!


So ... these vim bindings are not obscure because they are also to be found in vim. (-:

Can I interest you in the util-linux pg as a pager? It has the feature of not understanding Control+F, Control+B, PgUp, or PgDn.


The vim pager is just useless errata, it makes me happy I found it.

But the point is a lot of common CLI tools will have ctrl+F/B available via less unless you configure it otherwise.

I finally found another one, a real other one, by the way: tmux.


For me it's because putty by default dumps characters on the screen when pageup is pressed. I work in an awful cloud hosted env that will not remember changes to my putty terminal aas well.


> Moving one line at a time

I either go down with arrows (I know it's controversial), beginning of file with :1, end of file with G, line number with :[line number] or search with /. I usually don't have large files so this works very well (and I almost exclusively go by line number on large files).

> Moving one character at a time

I use ^ for beginning of line, $ for end of line, e to move quickly in a line

> Searching for the word under the cursor

Nice, didn't know about */#, I just type what I'm searching, gonna use that.

> Deleting, then inserting

Insert mode is fine.

> Using the arrow keys

I use the arrow keys, and I don't care about all the arrow-key shamers out there.

> Moving in insert mode

I use insert mode only while editing (makes sense). I don't get the point of this paragraph.

> Moving to Escape

I'm fine with escape key.

> Moving to the start or end of the line, then inserting

I much prefer just going into insert mode.

> Entering insert mode, then opening a new line

I also use o quite often (as it just goes into insert mode).

> Entering insert mode to delete text

Yes, I delete with dd, de, etc. (. is also useful for that), deleting in insert mode is painful for more than one character.

> Repeating commands or searches

Didn't know about q: and q/, pretty useful, nice.

> Repeating substitutions

I use %s/for/far/g or %s/for/far/, or for a few lines, I select them (shift-v) (visual mode) then : (which auto-sets it to :'<,'>) then :'<,'>s/for/far/ for instance.

Anyway, been using vim for ~5 years with a pretty light .vimrc and one thing I would recommend is bogado/file-line plugin which lets you open a file at a line, e.g. vim app/models/user.rb:48

My vimrc if anyone is curious: https://gist.github.com/localhostdotdev/aa25d1c81f3f3b67ac35...


> Moving in insert mode

He doesn't give the most relevant shortcut for this situation! While in insert-mode, "ctrl+o" will allow you to run 1 movement command and leave you back in insert! I've found this to be amazing once I got the hang of it.


>I either go down with arrows (I know it's controversial)

Probably not that controversial any more. It used to be (although I would use the word inadvisable instead), because dumb terminals like VT-100 and some emulators of them, would emit escape sequences when arrow keys were pressed. Since an escape sequence starts with the Escape key and then has some other keys following it, it would result in your going from input mode (if you happened to be in it) back into command mode (due to the Esc key) and then the remaining keys in the sequence would be likely interpreted as vim commands (since many letters of the alphabet are vim commands), so any unwanted modification could happen to the file you were editing, maybe without your noticing. Then if you saved the file without knowing that there was some such inadvertent change, you could have lost or mangled some of your content.

Nowadays common emulators that I have come across, don't have that issue, so arrow key usage should be fine.

The other reason why people may comment if you use arrow keys for movement in vim, is because if you instead use the default and recommended hjkl keys (for left, down, up, right respectively), your fingers stay on the home row (on a QWERTY keyboard), which may make for less finger / hand movement, so less strain.

>beginning of file with :1, end of file with G, line number with :[line number]

You can use 1G for beginning of file, G for end of file, and nG for going to line n, without having to hit Enter after some of those commands as you have to with the :[line number] method, thereby potentially saving one keystroke many times per edit session.

>I use ^ for beginning of line, $ for end of line, e to move quickly in a line

0 goes to the real start of the line, ^ goes to the first non-blank character on the line.

>I use the arrow keys, and I don't care about all the arrow-key shamers out there.

Good on you.

>I also use o quite often (as it just goes into insert mode).

O (a capital O) Opens a line above the cursor, o (small o) opens a line below it.

> Repeating substitutions

>one thing I would recommend is bogado/file-line plugin which lets you open a file at a line, e.g. vim app/models/user.rb:48

  vi(m) +n filename
will open filename at line n, for both vi and vim, so I'm not sure why that plugin is needed, unless it does other stuff too.

And:

vi(m) +/pattern filename will open filename at the first occurrence of pattern in filename.


It seems to be more a function of the vi-like in use. Old-school vi behaved that way, but (at least some) vim interprets ESC [ A close together as a movement command.


Not sure if you are directing this comment at me, but I know most of these already. Didn't know about the older terminal emulator issues with arrow keys though.


It was partly for you and partly for other readers. It seemed to me that, based on your comment, you may not have known about some of the points I mentioned, like use of G with number modifiers instead of the "colon then <number> then Enter" method. Maybe I should have been more specific, and put the more general points in a separate comment. Also, I guess you may prefer to use the colon method even though the G method is one key less. I know I do at times, too :)


>Didn't know about the older terminal emulator issues with arrow keys though.

NP. Yes, I've found that some people do not know about those issues, which is why I mention them (and also, like others, recommend the use of the hjkl keys) in my quickstart tutorial that I mentioned elsewhere in this thread:

https://gumroad.com/l/vi_quick


Same here. I cannot take my vimrc everywhere I go so keep it on the minimum.


What I cannot wrap my head around is word-wise moving in code. I just never really know where w or b takes me, let alone how many w’s it takes to get me to the desired word. My moving is mostly based on estimating counts; nth space (nf ) or just before third comma backwards (3T,); plus manual adjustments.


There are 2 types of characters ignoring whitespace:

* Upper and lower case letters, numbers, and underscore. This is what one commonly refers to as word characters as they're the least common denominator of what identifiers in programming language are usually allowed to consist of.

* Everything else (punctuation and other symbols, etc.). We'll call these non-word characters.

w, b, e, etc. will work in units of consecutive characters of the same type. So, if a consecutive set of word characters is a word, a consecutive set of non-word characters is a non-word, and everything else is whitespace. w will take you from the current word or non-word to the beginning of the next word or non-word. e will take you to the end of the current word or non-word, unless you're already there (one character word or non-words, for example), then it will take you to the end of the next word or non-word. b will do the same as e but to the beginning and work towards the previous.

The upper case versions of these commands, W, B, and E, treat the aforementioned word and non-word characters as of the same type, so you move in units of consecutive non-whitespace characters.


I find t and f more useful in my day to day. On any given line there is almost always some character that gets me within a few words of where I want to be then w or b to get to the word itself. Might be somewhat language/style specific though


I don't suggest disabling arrow keys and mouse. But I don't suggest using them either. (This goes for tmux as well).

The reason being is that you will frequently have to work with others. If someone comes over to your computer (or you bring it to them), they need to be able to look at the code. It just saves a lot of hassles. Besides, disabling these isn't going to help you develop those patterns, what helps you develop keeping on the keyboard is actively staying on the keyboard.

Side note: you'll notice vim users are more likely to use keyboard shortcuts in substantially more programs than in the terminal.


I don't see the point of disabling them. If you're a grown ass adult and you want to learn the homerow movement, just use the homerow until you naturally don't feel like using the arrows. It's not really that hard and you can always fall back on the arrow keys if you really can't afford to guess where your cursor will end up next.


I disabled mine earlier this week. After a bajillion years of using the arrow keys (even in Vim), I needed something explicit to force me to use the homerow.


I think this is actually the point he was trying to make in the article, if your instinct is to use the arrows and you want to break that, then Vim can help you!


Another tip: Don't remap your comma (,) key to leader.

Many people suggest this — and I don't know why — but it shadows the command(verb? motion?) to move to the previous match in a line-wise find.

Some people in this thread say they skip through a line by word with w/W/e/E, but sometimes it's faster to see the character you want to jump to, say it's the number 4, and do f4. If the cursor lands on an earlier occurrence of the character that you didn't know was there, hit ; to jump to the next one. If you skip too far, hit , to go back again.


I like <Space> as my leader key. Easy to hit and it doesn't do anything useful.


I've used vim for seven years now. My vimrc is a gargantuan 122 lines of vimL. It went from 0 lines to 300 to 750 and it's been 122 for a year now. Whenever someone asks me for tips and tricks to learn vim I reference this tweet:

https://twitter.com/ID_AA_Carmack/status/473247789728952321

Just use VSCode / SublimeText / Notepad++


See also the excellent "Your problem with Vim is that you don't grok vi" by Jim "Linux Answer Guy" Dennis:

http://stackoverflow.com/questions/1218390/what-is-your-most...


vim-adventures.com is a great way to learn vim by playing a game.

It’s worth the money if you enjoy solving puzzles and learning by doing.


vimtutor is also a good way to get started with the basics of vim. If you have vim installed, it probably came with it.


Its a monthly subscription for a simple "game". vimtutor is free without the cutesy stuff.


Some vim keys I use a lot that seem not to be mentioned too often:

{ and } to go back and forwards a "para"

^U and ^D to up and down a half a page

{ and } are particularly useful with verb keys such as y, d, < and > (outdent and indent). And ! (bang) to reformat text with `fmt`

I cry a little inside when I see people go through pages with the j,k or up and down keys.


One I noticed missing (based on another comment here) is ctrl+o to run a movement command while in insert mode. To me this is pretty valuable glue between command/insert mode.

E.g. "ctrl+o 2e" to skip forward 2 words.


Cool. There's always stuff I didn't know about.

I think that on most terminals/vim combos the arrow keys will also move in insert mode.


The opening of this rings true for me. Once I get a pattern ingrained, it can be difficult to reverse it even if there is a more efficient way. To combat this I usually pick one thing per coding session to work on. I find lists like these helpful to check-in and see if I can add anything to my future to-work-on lists.

When I started learning vim I read an interview where someone (Ben Orenstein maybe?) talked about keeping notecards or a cheatsheet on their desk so they could do the same thing and I thought they were insane (and vim was insane). With time though, this method got me proficient at vim, then better, then better still. Each time I learn something new or unlearn sometime inefficient for something better I get a little bit of joy out of my daily work.


Disclaimer: My vim knowledge has many gaps.

Understanding vim's model, what Chris Toomey of Thoughtbot calls "the Vim Language", helps incredibly:

https://youtube.com/watch?v=wlR5gYd6um0

I've picked up numerous tips watching this and other of Thoughtbot's excellent video series. More importantly, though, is that I've learned why specific vim idioms and motifs exist. They've lead me to rethink my own usage patterns, sometimes changing them, sometimes holding them just a bit more tightly. (Say, my practice of doing global regex pattern-replacement edits rather than repeated vim edits or macros, generally.)

But for a tool I use for coding, data cleaning, systems administration, email, writing, document preparation, and more, it pays to be on the lookout for more effective, faster, reliable, and/or repeatable methods.

And no, vim's not the only editor I have, or do, use. It's not even the first Unix editor I'd used. There's been DOS EDIT, EDLIN, MacWrite, WP51, WordStar (me and GRR!), EDT, EVE, the ISPF editor, emacs, pico, ae, MS Word, ... you get the idea.

But back in the 1980s, I first encountered (and balked noisily at, for a few weeks), BSD vi. And the basic muscle memory acquired, after a brief period of pain, has almost certainly been my best technical investment after learning to touch-type itself. Most importantly becaue both have been remarkably durable skills. No, vim is not vi, but it builds on its core. And over 30 years later, I find it useful both to see what new capabilities have been added, and where my old knowledge has holes or flaws.

And I plan to be using, and able to use, that knowledge in another 30 years. Which I cannot say for most of the other editrs I've listed, or those listed by others here. It's been both vi/vim's utility and consistent access to it which have made it a valuable and durable tool.

Vim is a massively efficient tool for sculpting text. And that's why I use it and continue to hone my own skill with it.


No Brief? Or qedit? Or E? (-:

^K^D


I omitted a few. Qedit makes the list.


For the advice towards ESC key, anyone uses ctrl+c for quitting insert mode? I didn't know about the ctrl+[ combo works too.


Of all the good practices listed here, the only one I can't seem to be bothered with is */# for searching the word under the cursor. I am curious is this happens to others, or it's just thst my workflow is idiosyncratic in this respect.


I use * often. It's even more convenient nice I have * mapped to pressing a modifier+n, so after I type * I can just hit the same key and type n, or switch to shift+n to go backwards. The map is on my keyboard, not on vim.

(You have an interesting username!)


It's an interesting airport :)


I love * / #. One of my regular pattens is

*#ciw<something><esc>n.n.

So I put the thing I want to change in the search register, jump back, change it and then start hopping through subsequent occurrences changing them too.


I will never understand why iPad keyboards do not have a proper esc key. I know you can remap but it’s not the same. It’s almost as if apple knew this one key would forever preserve the MacBook as a developer platform.


The current Macbook Pro with Touchbar does not have a physical Esc key either.


I find this highly annoying as it's my issued computer at work, but it took me like one day to get used to standard ctrl + [ as an alternative


Perhaps but shouldn’t there be a rule that if it takes more keystrokes we shouldn’t do it? It’s like deprecating df.ix for df.iloc... why do I need to type two more letters for essentially the same functionality?


One thing I noticed myself doing is moving my fingers from the home row alot. For example when type "0p, I think I am supposed to only the pinky the type the entire command, but I am using the ring finger.


Glad to notice I knew all of these, apart from q: and q/


More tips:

If you inoremap jk to ^[ (esc), and kj to ^[ as well, you can just roll jk or kj keys to escape back to command mode. No more reaching for the esc key.


Or swap caps lock and escape. How many times did you reach for caps lock during the last year?


I prefer CTRL to be where caps lock was. I use CTRL very often, especially since (on macOS and Linux) many text fields use readline, which means you get Emacs ctrl- movement keys.

Almost the only time I use ESC is in Vim, and ctrl-[ or ideally the jk/kj->ESC mapping is really nice for me.

Now that I go the jk/kj esc mapped for .ideavimrc, I'm super psyched.


Using Vim without knowing WAY more than this article is an anti-pattern. Vim is inefficient for editing so you have to learn a lot more than these tricks and hacks to be proficient. If you aren't learning more about Vim's nasty design every day then it's an anti-pattern to use Vim, because you'll be much more efficient with less learning in any other editor. If, for example, you don't know how to edit searches and command-line mode commands in full Vim mode, then keep learning (press control-f in search mode). If you aren't proficient in Vim's garbage VimL then keep learning. Obviously an IDE with intellisense and multiple cursors is more efficient than most of Vim's efficiency hacks. Vim's efficiency gains more apply to editing text, not structured code.


I started using vim about 10 years ago. I am not an expert user, but I am using enough of it's features that I feel crippled when I am using another editor. I just have to think move this function to another file and my fingers will execute the vim commands.

I don't know any Vim Script. You don't have to know it to use vim, unless you want to write your own plugins.

I tried using an IDE recently (Clion), but it was not really worth it. Vim has plugins for most IDE features, including autocomplete and syntax checking. The only feature that I really miss in Vim automatic refactoring such as inlining functions.


You don't mention interactive debugging in vim ... and I'm not sure there's a good story there that's better than your CLion (Jetbrain's C/C++ IDE) -- I'd like to hear about vim interactive debugging. Perhaps there are other good debugging solutions for C/C++ but I like to edit and debug in the same environment.

Any Python code I write or review in Python I try to give a run-through in PyCharm (JetBrain's Python IDE) interactively -- having a chance to step through code lets me consider more options and corner cases and get a more expansive view on what I'm developing or reviewing.

"vim" is my preferred editor when I'm not in an IDE, and often when writing bash scripts, but over the last ten years especially I've rarely written higher-level language code outside an IDE environment ... and I stick to JetBrain's suite mostly these days.


20 year vim user here... There is a really decent VIM plugin that works with all of the jetbrains IDEs I have used that I would recommend. It will even read your vimrc file! I wouldn’t write Java or C# without an IDE (IntelliJ IDEA and Rider respectively) and the vim plugin makes adjusting to them much less painful.


Do you mean the plugin that is built in or is there different one?



Can you provide the link for that plugin?


I’m not in front of my workstation right now, but I believe this is the one: https://plugins.jetbrains.com/plugin/164-ideavim


It’s not perfect, but it does visual mode and visual block mode and will use as much of your vimrc as it can. Beats the heck out of vanilla IntelliJ that’s for sure.


Vim 8.1 ships with a GDB plugin (TermDebug).


Well, TBH, that sounds naïve. I use vim for way more than 10 years, have 500 lines of vimrc with multiple plugins installed, know pretty much every shortcut by heart, never use arrows and can somewhat write VimL. It is really hard for me to code w/o vim-layout, so I was struggling for a long time, but finally moved onto using JetBrains products (with vim-mode plugin, which is meh, but better than nothing still). I don't really like it, but I have to finally admit, that vim with plugins is not "almost an IDE". Mileage would vary for different languages, but the point is that IDEA/PhpStorm/PyCharm can suggest me so much more than Vim, because it knows the AST, and writing plugins to operate it is currently easier than with vim. I mean, in theory you could install whatever backend you want onto vim, that does AST-parsing and autocompletion, there already exist pretty neat YouCompleteMe, jedi-vim (for python) and even heavy artillery such as eclim, but unfortunately it's all far from "solid support", and VimL is not the most friendly environment to write plugins for.

I really wish there was an IDE that would be IDE-first (building an AST for each file, and using it for most of the functionality + making it easily usable in the scriptable plugins), but had the UI and usability of vim, but there doesn't seem to be any.


You may want to keep an eye on https://microsoft.github.io/language-server-protocol and https://github.com/w0rp/ale.

Any editor that supports it will have very very high quality auto complete and other IDE-like benefits like jumping to definitions.

It's still in its early stages but it's shaping up to be a game changer if you want those features.


https://langserver.org has a very useful set of tables. It currently has 5 entries labeled "vim/neovim".



I am currently writing C++ code. The vim plugins I am using are YouCompleteMe, Syntastic, UltiSnips and TermDebug. In combinations these plugins give me most functionality that an IDE has.

Like I said, Clion (which is a JetBrains product) has some great functionality which goes beyond that. The one I found the most useful is the refactoring functionality. I actually opened Clion just to refactor some code on Friday. But it also has drawbacks. I am working a very large codebase and Clion is very slow.


What's the loc size of codebase? I've been using clion on blender (several million loc) and it runs pretty neat.


I work at Google, so it's in the billions.


mind blown good luck with that.

edit: Let's take 2 billion. Assuming 60 characters per line, that'll take around 120GB just to keep the text in memory! Would the ast representation of whole codebase be smaller or larger in size?


That's great. After moving that function, rename the file in Vim to reflect the change. Just kidding. Made you sweat though, huh?

Not knowing how to use a more productive IDE doesn't mean that Vim is more productive.


You believing that renaming a file is difficult in Vim shows that you don’t know Vim as well as you think you do.

Here, I’ll do it completely from memory for you, while typing on my iPhone.

    :saveas newfile.ext<cr><c-^>:!rm %<cr><cr>:bd<cr>
And of course, you could always use the command line to rename anything.


I wrote a plugin to do it, which is way better than what you posted. And they're both way worse than an IDE. And the command line is least efficient of all for this task.


I’d like to remind you that you are arguing about the efficiency of renaming a file.

This argument is so nonsensical it doesn’t bear contemplating.


I guess the point is that even such small tasks require typing cryptic commands in vim.


yup, you're right, talking about concrete examples of efficiency in a thread about efficiency is "so nonsensical," which you only pointed out after posting dozens of keystrokes for something that takes two keystrokes in well designed editors.


Excluding the filename and extension which would have to type out in any case, there are actually only 22 keystrokes there.

So, not dozens.

You could also not bother destroying the old buffer.

You could also do:

    :!mv % newfile.txt<cr><cr>:e newfile.txt
Again excluding the filename and extension, that's a total of 12 keystrokes.

And again, this is not a task anyone spends much of their working life performing.

Give up.


Nah. You can get by just great if you know movements(h,j,k,l,w,b,W,B) and I, i ,A , a, o, O, dd, f, v, and how to use numbers with all that and how to combine them and how to quit and save. If you want to look like a wizard, learn to search/replace, ciw, star(*), macros and the dot(.). By now you probably have a custom config...


>Vim is inefficient for editing

Probably the first time someone ever thought this inane idea.

>Vim's nasty design

OK, trolling, next.


> Vim is inefficient for editing

I learned vim a bit more than 20 years ago and can tell you it’s a very efficient tool. Fair enough if I was doing most of my coding in a single language it might be worthwhile to learn a different IDE. You’re welcome to use a different tool that better fits your needs. And hope that you find it at your next workplace or the legacy server that you are asked to fix.


[flagged]


Could you please stop being a jerk in HN comments? It's what we're trying to avoid here, and I'm afraid you've done it quite a lot. That's dismaying.

If instead you would please review https://news.ycombinator.com/newsguidelines.html and take the spirit of this site to heart, we'd be grateful. Some other links that might help, too:

https://news.ycombinator.com/newswelcome.html

https://news.ycombinator.com/hackernews.html

http://www.paulgraham.com/trolls.html

http://www.paulgraham.com/hackernews.html


To an extent you're right. I've used vim for 20 years, and in the first say 5 years I would spend a lot of time tweaking configs, learning new commands etc. I don't think I will ever make back the time I spend on that in saved editing time.

However, the main benefit of vim isn't so much 'increased speed' (to me) but rather 'feels like a solid tools in my hands', or even better, 'feels like an extension of my mind'. No other editor gives me that - there are always these small micro-interruptions of 'reaching for mouse, aim at menu, miss, try again' or 'take hands off home row, now my elbow isn't in a comfortable position any more when I go back'.

It's like using say a Hilti, blue Bosch or Makita cordless drill vs a no-name or even cheaper brand name one. You can drill holes or screw screws just as well, but the reduced vibrations and excess power and tighter fit of everything just make everything feel more effortless and make you spend less time on being annoyed at the tools, even if they're all just 'micro-annoyances' that don't add up to any measurable time wasted. The more expensive ones (in Vim's case, expensive in learning time) are still worth it.


Been using vim for 'years' and I am not using it 'perfectly'. What I have noticed is that like with i3wm with vim you create your own way of working with it. You just find the way that works for you.


Nice gatekeeping


The article doesn't specify whether you're coding or not. It even says "whether writing code, poetry, or prose" at the top.


Do you have an example where multiple cursors are efficient, but Vim is not?


I easily can: modifying multiple expressions that have different length, but the same ending and are separated with some lines of code in between. In vim I either do it manually (because the movement is truly faster) or record a macro. In most "modern" text-editors I could do it with multiple cursors. Recording a macro always feels a bit more energy-consuming, than just making all the changes visually.

TBH, now that I'm mostly using an IDE with vim-plugin for work, I still prefer writing macros in such situations than using multiple cursors, because such situations are rare enough, and the power of habit is strong.


Sounds like a job for the "global" ex command (with or without a macro).


Although you have to admit that Vim is excellent at beeping.


> Using Vim without knowing WAY more than this article is an anti-pattern.

VIM is about composing small and straightforward operations, like in functional programming. So with several primitives you get a lot of combinations. So the idea actually is the opposite: Learn just a few primitives and get your shit done using the combinations, which can be very flexible and powerful.

> you have to learn a lot more than these tricks and hacks to be proficient

The techniques highlighted in this article are not tricks nor hacks. It's actually more like VIM 101. Surely VIM has a lot of hacks but these definitely aren't among those. You don't sound very informed about VIM here.

> Obviously an IDE with intellisense and multiple cursors is more efficient than most of Vim's efficiency hacks.

Obvious to you, maybe. Funny you believe that something that has caused a shitload of controversy can actually be obvious. Please don't serve your personal opinion as being "obvious". To me, and I'd say to many others, it's not only not obvious, but "obviously" wrong.

Also VIM has multiple cursors for some time albeit as a plugin: https://github.com/terryma/vim-multiple-cursors

> Vim is inefficient for editing

> Vim's efficiency gains more apply to editing text, not structured code.

First of all, structured code is text, so Vim's efficiency gains have to apply to it as well, there can't be any denying that. On top of plain text, VIM has other easily applicable features for structured code such as text objects, folding, highlighting, auto-completion and tag-browsing. These are not very hard to get right.

> If you aren't proficient in Vim's garbage VimL then keep learning

VimL really is garbage, I'll give you that. The trick is that you don't really need to learn it. I'm a ~10 years VIM user and still don't know anything about the VimL syntax (intentionally). The secret is that you can have a very effective VIM config around ~50 lines which itself mostly consists of settings, file type specific settings and aliases. But if you try to make VIM behave as something it wasn't meant to be, you'll be sorry.

I think that the confusion comes from the tendency of comparing VIM to IDEs, as well as trying to make VIM behave like IDEs. In my opinion, most people in the VIM community are "guilty" of this as well.

If you need an IDE, but you want VIM's mode and command composition driven approaches and keybindings as well; the wiser choice would probably be a modern IDE that supports a VIM mode.

For me, stuff like popping fancy file browsers or git wrappers from VIM is not what I'm looking for in the VIM experience.

But if what one wants is to get stuff done in the terminal; then one should learn a couple of UNIX tools instead of installing a gazillion of VIM plugins.

In short, if you need a modern IDE, use a freaking modern IDE. No need to make ignorant comments about our beloved VIM.


Linking to that plugin means you haven't used it. Use an IDE that supports this well, not an incredibly buggy hack to get basic editing features.


You don't need a plugin to get multiple cursors in Vim.

Go into visual block mode, press j a few times to select more lines, and hit I to go into insert mode. When you finish the insertion, you'll see the same insertion has been performed across all the selected lines.

You are clearly trolling, and/or you have far less knowledge of vim than you think you have. You are only making yourself look bad here.


That's much more limited than multiple cursors. Have you used that feature in other editors?


It is more limited, yes. It is only useful in rather trivial cases.

For everything else, there’s macros. Macros are unarguably far more powerful and useful than multiple cursors.

Visual block mode is constrained by absolute cursor position. Multiple cursors is constrained by relative cursor position. Macros have no constraints whatsoever, and can even be recursive.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: