Vim Anti-Patterns (2012)
sanctum.geek.nz
sanctum.geek.nz
- 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.
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.
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).
>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.
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.
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".
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.
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.
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]
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?
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.
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.
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
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...
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
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.
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.
"instead of se number
se nu
Was never able to adopt it as my main editor. The bifurcated input/command modes always trip me up.
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
2) That’s incsearch, `set noincsearch` to turn it off.
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.
"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. :-)
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.
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.
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 much easier to remember and you can use autocomplete anyway. Once you have the command down you can start to abbreviate it.
I mean yes in principle their roots are in ed but ex is the command line editor mode of vi since it's inception
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.
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.
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.
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.
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 :-)
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.
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.
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!
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.
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.
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.
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'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?
Given that it is an involuntary spasm, then yes, it does.
But alright, just sounds dreadful I guess, to be unable to stay in flow due to the most minute actions or occurrences.
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.
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.
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.
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).
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).
You can also adopt these keybindings inside vim with the tpope/vim-rsi plugin. This approach has been quite effective in my experience.
Thinking that you require perfect memory to use arrow keys while programming is just hyperbole.
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.
The same goes for ci' or ci".
a = 'foo' // imagine the cursor on the letter a
Executing ci'bar will change foo to bar.
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...
I personally added a "number" text object, so that I can treat numbers just like "words", and also created a "jump to number" shortcut.
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:
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.
Remap caps lock to escape on your computer and it'll work in every editor and every machine you ssh into.
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.
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.
Having used both vim and chisels, with varying degrees of mastery.
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.
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.
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.
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.
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.
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...
But it's not like when VS Code released, all the vimzards who went to use it suddenly became awful at their job.
...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.
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?
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.
But, there are people who enjoy and master the trade without mastering the tools as well :)
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.
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.
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.
It doesn't really matter what tools you choose, provided you know them well and they're well suited for your work.
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.
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.
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.
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.
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 binding I find myself making sometimes dozens of throw-away macros an hour.
> 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.
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.
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.
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?
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.
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...
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...
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
And:
vi(m) +/pattern filename will open filename at the first occurrence of pattern in filename.
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:
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.
* 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.
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.
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.
https://twitter.com/ID_AA_Carmack/status/473247789728952321
Just use VSCode / SublimeText / Notepad++
http://stackoverflow.com/questions/1218390/what-is-your-most...
It’s worth the money if you enjoy solving puzzles and learning by doing.
{ 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.
E.g. "ctrl+o 2e" to skip forward 2 words.
I think that on most terminals/vim combos the arrow keys will also move in insert mode.
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.
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.
^K^D
(You have an interesting username!)
*#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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
Not knowing how to use a more productive IDE doesn't mean that Vim is more productive.
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>
This argument is so nonsensical it doesn’t bear contemplating.
So, not dozens.
You could also not bother destroying the old buffer.
You could also do:
:!mv % newfile.txt<cr><cr>:e newfile.txt
And again, this is not a task anyone spends much of their working life performing.
Give up.
Probably the first time someone ever thought this inane idea.
>Vim's nasty design
OK, trolling, next.
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.
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.
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.
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.
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.