After years of a love/hate relationship with Vim (I love what it does, but have configuring it), I had an epiphany: by sticking with the defaults, whether they are my preferred choices or not, I can instantly understand how to use Vim in any environment. Once you get used to biting the bullet and hitting escape instead of jj, or ctrl+c, it just works, everywhere.
If you abandon the urge to pimp out your Vim with a billion plugins, and just use it raw, it's a kind of editor Nirvana. Let go of your desires and live without want :)
Of course, that's just me. I understand why someone would want to turn Vim into their personalized powerhouse editor with IDE powers, with their .vimrc a 'git pull' away.
But I've learned to live with the humble defaults, and it's made life easy.
>After years of a love/hate relationship with Vim (I love what it does, but have configuring it), I had an epiphany: by sticking with the defaults, whether they are my preferred choices or not, I can instantly understand how to use Vim in any environment.
Which I've never found much important.
If you know Vim basics (modes, basic commands, movements, etc), then you can use vim in any environment that you SSH to or happen to have to work temporarily on.
But why wouldn't you want the Vim on your main driver laptop, which you use every day to not have a nice custom setup, and some good third party plugins (e.g. file search, linting, etc)?
It's not like using them will make you forgot the basic commands, movements, etc, to use vim in some unknown remote machine.
And it's also not like you should optimize for the random remote machine you'll get in, and not where you spend hours programming every day.
So unless one is a sysadmin and has no real "main" machine he uses vim in, this makes no sense to me...
> It's not like using them will make you forgot the basic commands, movements, etc, to use vim in some unknown remote machine.
No, but time I spend setting up and tweaking a custom environment is time I could be spending internalizing the tools that exist everywhere and work well after the learning curve.
Since working on a foreign machine usually only happens when something’s broken, it’s already a stressful situation— my tools not behaving the way I expect won’t help matters.
> But why wouldn't you want the Vim on your main driver laptop, which you use every day to not have a nice custom setup, and some good third party plugins (e.g. file search, linting, etc)?
There are two assumptions I think you're making here:
Assumption 1: You can do better than the defaults enough to justify the costs of optimizing. I use a pretty much default vim configuration as my primary development environment, and see zero evidence that this hampers my productivity in any way.
Built-in file searches are good enough for open files, and grep/git grep do well enough for other files.
Linting should be part of your build process. There's a benefit to it being a bit painful for linting to fail, because that negative reinforcement causes you learn the linting rules and start writing pre-linted code.
You might disagree with me that these benefits are minor, but that's only looking at the benefits: let's look at the costs of "optimization":
First, there's the bugs in plugins and bad interactions between plugins. Very few plugins are written to any sort of reasonable QA standard. I've pair programmed with a lot of devs who use highly custom vims, and without fail, they've got bugs in their configurations that are far more distracting and impeding than any minor inefficiencies in the default configuration. Say what you want about the default configurations, but I've not found any bugs in them in years of using them.
There's also simply the time spent configuring. At one time in my life, I spent hours trying to get things just right in my configs. The results were pretty mixed--a lot of times I ended up not liking the changes I had made and reverting them.
There's a bit of hubris involved in believing you can do better than the defaults. Instead of looking at the settings as the problem, consider the possibility that your knowledge is the problem. It's likely that there's a good enough way to solve your problem in the defaults, and you simply don't know or grok it yet.
When I first started learning vim, I thought it was kind of stupid--everything seemed way harder than it needed to be. But once I actually grokked the tool, I realized that my initial impressions were the stupid ones. A lot of problems I've run into over the years with vim are like that--the problem wasn't that the default vim didn't solve my problem, it was that I didn't grok the solution which was easily assemble-able from the vim skills I already had.
A programmer I really respect has a background process which watches file edits, internet usage, and a few other things (i.e. VLC) and automatically tracks his productivity. His process marks time spent editing Emacs configuration as wasted time, and I agree. Although that might be because it's Emacs configs rather than Vim configs. ;)
Assumption 2: Text entry is a significant bottleneck compared to other areas of your process.
In backpacking, there's a saying, "Don't save ounces when you can save pounds." The idea is, don't optimize the weight of your lightest things, i.e. your stove and water bottle, when there are still big optimizations to be made on your heavier stuff, i.e. your big three (backpack, sleeping bag, tent). Configuring your editor is almost always an attempt to save milligrams.
Frankly, once you reach a certain proficiency with an editor that's automatic enough to just get out of your way, editing becomes a subconscious process, and you can be thinking about other things while you edit. I think some people believe that they think of what to write, and then edit it in, and any slowness in editing is preventing them from thinking of what to write after that. I don't think that's how the brain works--if you don't have to think about editing, then you don't have to finish editing to be thinking about the next thing. So the best thing your editor can do for you is to not make you think about it consciously. The more complicated you make your editor, the less likely this is to happen. The power of vim is that it lowers a lot of more complex edits to the subconscious level: swapping two lines is three keystrokes, so it's a simple enough process that I don't have to think about it.
Once you reach a certain level of subconscious-ness with an editor, editing simply isn't the bottleneck. I've known Notepad++ users who were faster Ruby programmers than me--I could certainly edit faster with vim, but they could come up with the solution to the problem in their head faster because they're more proficient with idiomatic Ruby. If editing really is the bottleneck, the problems you're solving are quite easy for you, and you could probably get paid a lot more if you took on harder problems!
And that's just looking at the process of implementing features! There's a lot more to software development. I've yet to work at a workplace where requirements gathering and keeping shareholders informed weren't much larger opportunities for optimization than my editor configuration.
I've taken this approach halfway and only install plugins/config that I can easily do without. Things like git-gutter [0] and a line at the 80th column [1] are great, but I don't depend on them when I log into a remote machine. If I really want some features, I have them somewhat organized in my .vimrc [2]. It's a great compromise; I find that I haven't thought about major editor configuration in a couple of years.
[edit] Just want to add that I 100% agree that erring towards vanilla vim is a great idea; I used to use emacs and switched to vim precisely because the starting point fit my use style far better than vanilla emacs.
I use a bunch of plugins and I've never had trouble remembering the defaults in the odd case I'm unable to use my own config.
I don't get why the top comment on all vim threads is always recommending using poor defaults your whole life so you can avoid learning to configure it or avoid a second of confusion when you're ssh'd somewhere.
Maybe everyone else besides me spends all their time ssh'd into random servers.
Nah, I've seen people downloading their preferred configs right to the production server, because they, understandably, feel more comfy with that.
But, it may not be for everyone.
Where I work, we are in the process of reaching some compliance targets, and all this downloading unknown stuff from unknown servers is out the window. For the best, I think.
It's not a serious issue for me. I can't download my configs to random devices either. Working on embedded stuff I've usually only got vi, and honestly, the most annoying thing is no `F` binding (which is a default in vim).
If you want portable then yeah empty out your .vimrc and get fluent with vims superpowers as they are.
If you want "personalized powerhouse editor with IDE powers" you are FAR better off going with Emacs/Evil.
The Emacs plugin ecosystem is way ahead of Vim.
Plugins are clean, stable and compose well together. That was never my experience with Vim.
Also unlike Vimscript, Elisp is pretty clean useable language that many Emacs users actually learn. I'd bet the vast majority of vim users never get past step 1 on learning Vimscript?
Emacs/Evil for the workstation and clean Vim for the random server side work.
I bind my CAPSLOCK to ECAPE that way instead of the escape key killing my hand my left pinky finger can just naturally get me out of insert mode by hitting CAPSLOCK.
Am I the only person who actually finds Esc easier than C-[ or Caps Lock? Maybe it's just heavy muscle memory at this point, but I've been using Esc for years and every time I try to use anything else it just feels clunky.
Using the ring or middle finger allows you to hit the escape with very little motion and you can find the home row again afterwards without looking. Try it - usually takes the slightest wrist angling and extension of the fingers.
On my keyboard I need ALT GR for [. On a side note, I'm rather disappointed that the ESC key didn't get updated with modern keyboards. The keyboard vi was designed on had ESC where Capslock now resides.
That's what I do, and lately I've been recommending it more often to others when I hear them complain about the lack of a hardware Esc key on MacBook Pros.
I’m a long time VI(m) user, who started with emacs. I’m proficient in both editors, but use vim as my daily driver.
When I started my career, my mentor was an emacs user, and the reason I started with emacs. I became very proficient with the editor, learning how to handle multiple buffers, window splits, rectangle selects, etc. At that time, I didn’t know vi.
Until I started working on another project, where the project manager made a statement to me that started my migration to vim. I was logged into a machine that didn’t have emacs, and I was complaining about it. “Just use vi”, he said. “I don’t know vi”, I said. Then came the statement that stuck with me,
“Son, you got to know vi just enough so you don’t look stupid.”
So I learned vi, just enough to not look stupid, and eventually, as proficiency set in, turned to vi more often than emacs.
Now vim is my primary editor, and I can use emacs just enough to not look stupid. ;)
Back to defaults.
I customize my vim with colorized syntax highlighting, and several plugins. But at its core my vim is still default with respect to key bindings.
These are the defaults that matter. If you leave key bindings alone, then the core of vim use is identical anywhere you use vim, with or without your personal vimrc.
You can a make “stick to the core defaults” argument for just about any editor. Just keep the core defaults, and customize away on systems you use daily. Then when you use the editor without your personalizations, the editor still behaves as usual.
My editor life is also easy, but with some more creature comforts for daily use.
Pretty much likewise. Actually, I do away with the tabstop=4 these days too -- I've grown to like 8-width tabs.
When I started using vi on a Sun machine in ~1986 or so, I was an expert at 'edlin' (if there could be such a thing) because it existed on every DOS machine. I learned vi for the same reason: It not only ran on everything, it was pretty much guaranteed to be installed on everything.
I hated it, as I was used to many other 'visual editors' that were modeless, more like emacs. The first Apollo editor was my favorite.
But in those days, installing an editor was a real task, so I went with what was there. Now it's in my fingers.
Although on the (fairly frequent, because busybox) occasion I have to use REAL vi, I'm flustered when I type capital-V to get a visual line buffer...
The nice thing about these settings (I use the same ones) is that if you're on a machine that's not configured to use them, they take only moments to type.
Other than shiftround, the other three seem rather language dependent (which is why I've cluttered so many files with various vimlines/modelines over the years). Wonder if the editorconfig-vim plugin might be a better compromise "only plugin" approach? Particularly given the growing consensus towards editorconfig across editors.
I don't find myself needing to use Vim in random environments enough to gnash my teeth about how it doesn't work as expected. Even for those who do, it's not hard to pimp out Vim while leaving the baseline behavior alone. Any new functionality I add I make sure not to override existing frequently used key bindings.
I go for a heap of plugins but don't remap the things that start off built-in, so I get the muscle-memory for the defaults when I need a remote shell somewhere, but still the useful plugins on my own computer.
This is my philosophy with most software. I expect to get 80-90% of the way with zero configuration and then maybe for some advanced features I’ll touch the config and personalize some things.
The added benefit to becoming proficient with default configuration is that it is really easy to upgrade to a new computer and start from scratch.
And of course with vim, the benefit is the ubiquity when using ssh or docker or VMs which typically use the defaults.
I find that the muscle memory for my personal config is keyed off the visual appearance of my preferred color scheme. So I have no problem context switching between personal config and default config, provided the color schemes are right for each.
(Or anyway, that was the case until recently when I switched to evil-mode. I'm totally helpless in default config emacs.)
nvi had more direct lineage to true vi, Keith Bostic was in the Bill Joy headspace, but it kind-of got stuck. Vim diverged in ways which used to annoy me but I've come to accept.
I won't mention "the other editor family" here but it is interesting to see the things in that one, which I miss in this one (for me at least) which are principally the ability to cut-paste regions, and a set of things which became screen and tmux. Now there IS screen and tmux, that matters less.
Not having 2D region cut-paste is a small price to pay for the joys of a modal editor.
Some defaults aren't very usable, although "Debian defaults" are very close. I had the same approach, but lately I've decided to add plugins or configuration to "enhance" and never "replace", and I have never been happier as I'm now with vim.
I also decided to invest some time to move to vim + tmux instead of using gvim and now that I'm used to the extras I get with tmux (yep, terminal support in vim 8 is nice but not as flexible), I think I can't go back!
I do exactly the same thing. It really relieves the stress of working with an unfamiliar environment, and you become that much more effective with stock vim!
My biggest reason to not use the defaults has been keyboard layout. I've bounced back and forth between a version that deeply changed the Vim keys and one that tried to minimally change keys as best as possible. I'm back on the "minimal change" layout preference, but the problem is still "minimal change" is not "no change" and definitely not quite "nirvana".
This makes sense if you don't use vim as an IDE, but if you do, configurations and plugins are essential. Of course, you wouldn't expect to have a fully configured jetbrains IDE when you SSH into a remote server, but that doesn't mean you can't use one on your local development machine.
> > Of course, that's just me. I understand why someone would want to turn Vim into their personalized powerhouse editor with IDE powers, with their .vimrc a 'git pull' away.
I would agree, but then I found this: https://vim-bootstrap.com/ and it is sooooo nice. I no longer have to think about configuring vim or managing plugins because it is done. Esp for golang.
I'd take a tremendous hit in productivity if I followed that advice.
The amount of time I spend in Vim not customized is negligible, and I can always hit Esc in those cases with a
not even in the ballpark time saving over losing snips and all the custom plugins.
On a lot of machines, C-[ (control + left bracket) maps to escape. But some programs don't seem to acknowledge this? Like in firefox, doing that changes tabs, but in Emacs + evil mode it's how I "ESC."
There's an interesting reason for this related to the ASCII table and bit shifting, but I can't find a description of the exact mechanism for it. H and [ are in the same column as escape and delete respectively, and control shifts the bits in the character codes by some amount. Maybe someone smarter than me can elucidate.
I try to keep it minimal as well, but some plugins are too good not to install for my daily work. TabNine, Auto Pairs, Vim Surround, Endwise, and CtrlP are a few that come to mind.
Been using vim since 1998 and rarely stray unless I'm typing notes for something unimportant and them I use Nano.
Back in the day when I was a Unix admin, we often worked in full screen terminals and when editing a config file didn't like having to close the vim instance to go look at something, so learned about this little gem:
:sh (go back to shell and do your thing and leave vim running)
Ctrl-d to return to intact and running vim instance.
As an aside, if you decide to use nano to edit config files, make sure you use nano -w (no wrap), otherwise you may find yourself with a non-bootable OS instance.
This is one of the many things I learned from the destroyallsoftware screencasts [0] so many years ago. Before that I used vim in a gui (MacVim). Along with moving to tmux this completely changed how I work.
> :sh (go back to shell and do your thing and leave vim running)
In nvi (at least), one can also open a buffer and :script to run a shell inside vi and have all the yank/paste/navigation/all-the-things features of vi. Mind you need to i[nsert] or a[ppend] after the prompt to issue your commands.
Been using vim for almost a decade and embarrassed to not have known about how to go back to vim after doing `:sh` , so thanks for sharing that. I use tmux all the time so I tend to switch to a pane running bash and `ctrl-b z` to toggle the pane fullscreen
I wouldn't even use nano for typing notes; I'm so used to vim that I don't see why I wouldn't want its powers, even for something as simple as writing notes. I might very well want to reorder the notes, for instance: that's very easy in vim with dd/p. nano might have some Ctrl-key combo that does the same thing, but why bother learning that when I already know vim?
Mainly the idea is to not try and learn everything about vim, but instead pay attention to how you use it, and find things that are inefficient or could be easier, and then go figure out how to make vim do that thing more efficiently.
wow good for them if they're getting people to pay $99. It does look well-designed, but the course outline seems a bit elementary. If anyone is thinking about buying this, you could probably just google the items in the course outline and try watching a youtube video on it.
I started my programming career determined to be a vim guru and do all my programming with vim.
This was misguided and after a year of wasted productivity and wasted time fiddling with plugs and dealing with broken stuff (surely by my own hand) I switched to a professional IDE and I rapidly became a much better developer.
I use vim constantly now but in it's most plain vanilla form, for the purpose of editing files when logged into Linux systems. That's all I use it for.
I really wish however that every Linux system had a clone of the old DOS edit command which was beautifully simply and straightforward and met most needs highly intuitively.
As a sidenote: can I just say that PyCharm is an incredible IDE and I can recommend it heartily to anyone. If your job is programming then it is many times over worth paying the money for the professional edition.
To each their own! I'm a very effective python AND go programmer / sysadmin who uses vim for most all of my IDE stuff. I've also managed Linux professionally since 2005 and played with it since 1998 so it isn't for everyone.
You can install IdeaVim in PyCharm. I've been using IdeaVim with IntelliJ for 6 years and could never go back to non-vim style editing. This plugin provides the best of both worlds.
> I really wish however that every Linux system had a clone of the old DOS edit command which was beautifully simply and straightforward and met most needs highly intuitively.
The nano editor experience is pretty close to the old DOS edit feeling.
Everyone is missing the most important contribution of vi[m].
Vim defines an ergonomic set of rules for text navigation and manipulation, often implemented by very simple key bindings. This is wonderful.
The Vim editor implements all these rules, but the Vim's plugin ecosystem is a disaster. Hacks pile upon hacks. Noone understand Vim scripts. Vim scripts are easily broken and do not interoperate well with other scripts.
These set of rules can be easily implemented by other editors, as evidenced by many IDEs supporting Vim key bindings. Although these editors may not support all the above rules, they are pretty close (see the evil plugin in Emacs) and can replace Vim in daily usage.
The editor war is over. Vim's keybinding is superior. But the longevity of a text editor lies in its extensibility. For this, Emacs wins in the long run.
I rarely ever use actual vim, mostly when I'm in the terminal. But I have vim plugins for most IDEs I use (VS code, intellij, XCode). It makes editing so much faster. When I have to get by without it I feel as if someone put weights around my wrists. The reason I don't use Vim is because it's frankly not a smooth experience for most languages (unless you fiddle around a lot, and even then I found Ide+vim plug-in superior). I do hope Neovim will solve this, though I didn't test it because the last time I checked windows support was experimental.
After a several month effort to learn vim bindings and use them full-time, I eventually ended up weaning myself back off because the plugins for the editors I actually use all seemed to come with considerable downsides.
vscode-vim caused odd performance issues, and I encountered significant bugs with the undo stack (namely hitting 'u' would sometimes take out the last 10-15 changes instead of just one). IDEAvim would randomly go completely unresponsive for me, sometimes requiring just re-opening the file and sometimes requiring a restart of the entire IDE. And last I checked the Xcode plugin requires re-signing the entire binary with a self-signed certificate because the new plugin system won't support modal editing.
I was quite happy with neovintageous in Sublime, as well as Sublime's excellent performance in general, but no matter how many plugins I installed it could never seem to come close to the smarts of the other tools I was using.
Ultimately I just arrived the the conclusion that I'm never going to be happy with any editor and decided to make the best of what I could with a consistent set of keybindings across the tools I use.
That said, every time I edit my hosts file or something on a remote server and reach for vim, I wonder if I made the wrong choice. I'm really hoping Language Server Protocol becomes the standard and we reach the point where it no longer matters what editor we use.
I too have been down this road. I tried Atom for a couple of months, and that turned into a couple of years. I had it tuned into a VERY NICE Vim. I tried out VSCodeVim and got it to be a mostly passable Vim. It sure is pretty though. I'm back on nvim for the time being. Coc.nvim and LSPs make it pretty good. There are definitely rough edges and memory usage is pretty bad with all those plugins, but. I know it, I feel right at home with it. The only other two editors I invested any real time learning were Sublime and Emacs (I did not try to turn them into Vim - but I did end up installing Evil for Emacs later on)
I'm pretty broken by Vim. I don't really want to invest the time to get really good at a non-modal text editor.
I experienced issues with the VS Code plugin as well, though not as severe as you described. If I had the same issues, I wouldn't use it as well. I haven't experienced any issues ever with IDEA vim. I haven't used XCode in a while, so I can't chime in on the current state of the plugin. My ranking for most stable to least stable plugins I've used would be the following (in case of multiple plugins, I don't recall the exact one, sorry):
- QT Editor
- Eclipse
- IntelliJ
- Visual Studio
- VS Code
- XCode
At the moment I mainly use VS Code, and I'm still editing much faster, despite the issues (occasional undo hiccups and error messages).
I just wanna give my 2c in that after some years using vim I've started using vscodevim and I just love it. Perhaps it helps that it happens to match my vim config pretty closely (surround, easymotion, + language plugins and stuff such as ctrl p that is native to vscode).
I don't limit my plugin usage on purpose. I will add a plugin if it adds a value I can make use of.
Disregarding color schemes here is my list:
* FZF
* COC (it provides a lot of QoL, functionality of modern editors with it's plugins using an easy seamless yarn add)
* Sandwich
Very few customizations. Mostly vanilla.
Regarding colors, I love to try new ones all the time and my current is scery followed by Gruvbox, and Dracula because they work in Terminal.app and iTerm. They also look nice / easy-on-the-eyes. My friend at work has a thing for Nord and another loves Monokai Pro, but apparently the author wants money for it...? Which seems... different.
Readit News
If you abandon the urge to pimp out your Vim with a billion plugins, and just use it raw, it's a kind of editor Nirvana. Let go of your desires and live without want :)
Of course, that's just me. I understand why someone would want to turn Vim into their personalized powerhouse editor with IDE powers, with their .vimrc a 'git pull' away.
But I've learned to live with the humble defaults, and it's made life easy.
Which I've never found much important.
If you know Vim basics (modes, basic commands, movements, etc), then you can use vim in any environment that you SSH to or happen to have to work temporarily on.
But why wouldn't you want the Vim on your main driver laptop, which you use every day to not have a nice custom setup, and some good third party plugins (e.g. file search, linting, etc)?
It's not like using them will make you forgot the basic commands, movements, etc, to use vim in some unknown remote machine.
And it's also not like you should optimize for the random remote machine you'll get in, and not where you spend hours programming every day.
So unless one is a sysadmin and has no real "main" machine he uses vim in, this makes no sense to me...
No, but time I spend setting up and tweaking a custom environment is time I could be spending internalizing the tools that exist everywhere and work well after the learning curve.
Since working on a foreign machine usually only happens when something’s broken, it’s already a stressful situation— my tools not behaving the way I expect won’t help matters.
There are two assumptions I think you're making here:
Assumption 1: You can do better than the defaults enough to justify the costs of optimizing. I use a pretty much default vim configuration as my primary development environment, and see zero evidence that this hampers my productivity in any way.
Built-in file searches are good enough for open files, and grep/git grep do well enough for other files.
Linting should be part of your build process. There's a benefit to it being a bit painful for linting to fail, because that negative reinforcement causes you learn the linting rules and start writing pre-linted code.
You might disagree with me that these benefits are minor, but that's only looking at the benefits: let's look at the costs of "optimization":
First, there's the bugs in plugins and bad interactions between plugins. Very few plugins are written to any sort of reasonable QA standard. I've pair programmed with a lot of devs who use highly custom vims, and without fail, they've got bugs in their configurations that are far more distracting and impeding than any minor inefficiencies in the default configuration. Say what you want about the default configurations, but I've not found any bugs in them in years of using them.
There's also simply the time spent configuring. At one time in my life, I spent hours trying to get things just right in my configs. The results were pretty mixed--a lot of times I ended up not liking the changes I had made and reverting them.
There's a bit of hubris involved in believing you can do better than the defaults. Instead of looking at the settings as the problem, consider the possibility that your knowledge is the problem. It's likely that there's a good enough way to solve your problem in the defaults, and you simply don't know or grok it yet.
When I first started learning vim, I thought it was kind of stupid--everything seemed way harder than it needed to be. But once I actually grokked the tool, I realized that my initial impressions were the stupid ones. A lot of problems I've run into over the years with vim are like that--the problem wasn't that the default vim didn't solve my problem, it was that I didn't grok the solution which was easily assemble-able from the vim skills I already had.
A programmer I really respect has a background process which watches file edits, internet usage, and a few other things (i.e. VLC) and automatically tracks his productivity. His process marks time spent editing Emacs configuration as wasted time, and I agree. Although that might be because it's Emacs configs rather than Vim configs. ;)
Assumption 2: Text entry is a significant bottleneck compared to other areas of your process. In backpacking, there's a saying, "Don't save ounces when you can save pounds." The idea is, don't optimize the weight of your lightest things, i.e. your stove and water bottle, when there are still big optimizations to be made on your heavier stuff, i.e. your big three (backpack, sleeping bag, tent). Configuring your editor is almost always an attempt to save milligrams.
Frankly, once you reach a certain proficiency with an editor that's automatic enough to just get out of your way, editing becomes a subconscious process, and you can be thinking about other things while you edit. I think some people believe that they think of what to write, and then edit it in, and any slowness in editing is preventing them from thinking of what to write after that. I don't think that's how the brain works--if you don't have to think about editing, then you don't have to finish editing to be thinking about the next thing. So the best thing your editor can do for you is to not make you think about it consciously. The more complicated you make your editor, the less likely this is to happen. The power of vim is that it lowers a lot of more complex edits to the subconscious level: swapping two lines is three keystrokes, so it's a simple enough process that I don't have to think about it.
Once you reach a certain level of subconscious-ness with an editor, editing simply isn't the bottleneck. I've known Notepad++ users who were faster Ruby programmers than me--I could certainly edit faster with vim, but they could come up with the solution to the problem in their head faster because they're more proficient with idiomatic Ruby. If editing really is the bottleneck, the problems you're solving are quite easy for you, and you could probably get paid a lot more if you took on harder problems!
And that's just looking at the process of implementing features! There's a lot more to software development. I've yet to work at a workplace where requirements gathering and keeping shareholders informed weren't much larger opportunities for optimization than my editor configuration.
[0] https://github.com/airblade/vim-gitgutter
[1] set colorcolumn=80 textwidth=79
[2] https://github.com/stefco/dotfiles/blob/master/linkfiles/.vi...
[edit] Just want to add that I 100% agree that erring towards vanilla vim is a great idea; I used to use emacs and switched to vim precisely because the starting point fit my use style far better than vanilla emacs.
It is less buggy and doesn't refresh until you save, which I find to be less distracting.
I don't get why the top comment on all vim threads is always recommending using poor defaults your whole life so you can avoid learning to configure it or avoid a second of confusion when you're ssh'd somewhere.
Maybe everyone else besides me spends all their time ssh'd into random servers.
But, it may not be for everyone.
Where I work, we are in the process of reaching some compliance targets, and all this downloading unknown stuff from unknown servers is out the window. For the best, I think.
If you want "personalized powerhouse editor with IDE powers" you are FAR better off going with Emacs/Evil.
The Emacs plugin ecosystem is way ahead of Vim.
Plugins are clean, stable and compose well together. That was never my experience with Vim.
Also unlike Vimscript, Elisp is pretty clean useable language that many Emacs users actually learn. I'd bet the vast majority of vim users never get past step 1 on learning Vimscript?
Emacs/Evil for the workstation and clean Vim for the random server side work.
When I started my career, my mentor was an emacs user, and the reason I started with emacs. I became very proficient with the editor, learning how to handle multiple buffers, window splits, rectangle selects, etc. At that time, I didn’t know vi. Until I started working on another project, where the project manager made a statement to me that started my migration to vim. I was logged into a machine that didn’t have emacs, and I was complaining about it. “Just use vi”, he said. “I don’t know vi”, I said. Then came the statement that stuck with me, “Son, you got to know vi just enough so you don’t look stupid.”
So I learned vi, just enough to not look stupid, and eventually, as proficiency set in, turned to vi more often than emacs.
Now vim is my primary editor, and I can use emacs just enough to not look stupid. ;)
Back to defaults. I customize my vim with colorized syntax highlighting, and several plugins. But at its core my vim is still default with respect to key bindings. These are the defaults that matter. If you leave key bindings alone, then the core of vim use is identical anywhere you use vim, with or without your personal vimrc. You can a make “stick to the core defaults” argument for just about any editor. Just keep the core defaults, and customize away on systems you use daily. Then when you use the editor without your personalizations, the editor still behaves as usual.
My editor life is also easy, but with some more creature comforts for daily use.
Put that on a t-shirt.
I've been using vi[m] on an almost daily basis since about 1989...wow, that's 30 years.
In those decades, I have resisted putting anything in my .vi[m]rc except:
set tabstop=4
set expandtab
set shiftwidth=4
set shiftround
That's it. And I agree with you, it's a very happy place for me.
so I've saved my .vimrc to a gist and I just curl it every time I remote into a new environment
https://gist.github.com/airstrike/e361d94dbe4bb90f4fe6ff4418...
When I started using vi on a Sun machine in ~1986 or so, I was an expert at 'edlin' (if there could be such a thing) because it existed on every DOS machine. I learned vi for the same reason: It not only ran on everything, it was pretty much guaranteed to be installed on everything.
I hated it, as I was used to many other 'visual editors' that were modeless, more like emacs. The first Apollo editor was my favorite.
But in those days, installing an editor was a real task, so I went with what was there. Now it's in my fingers.
Although on the (fairly frequent, because busybox) occasion I have to use REAL vi, I'm flustered when I type capital-V to get a visual line buffer...
I'm not working with Latin-1 files.
set hlsearch
Though I really do like having the Capslock key remapped to escape.
The added benefit to becoming proficient with default configuration is that it is really easy to upgrade to a new computer and start from scratch.
And of course with vim, the benefit is the ubiquity when using ssh or docker or VMs which typically use the defaults.
(Or anyway, that was the case until recently when I switched to evil-mode. I'm totally helpless in default config emacs.)
nvi had more direct lineage to true vi, Keith Bostic was in the Bill Joy headspace, but it kind-of got stuck. Vim diverged in ways which used to annoy me but I've come to accept.
I won't mention "the other editor family" here but it is interesting to see the things in that one, which I miss in this one (for me at least) which are principally the ability to cut-paste regions, and a set of things which became screen and tmux. Now there IS screen and tmux, that matters less.
Not having 2D region cut-paste is a small price to pay for the joys of a modal editor.
I also decided to invest some time to move to vim + tmux instead of using gvim and now that I'm used to the extras I get with tmux (yep, terminal support in vim 8 is nice but not as flexible), I think I can't go back!
https://github.com/tpope/vim-sensible
Your parent (https://news.ycombinator.com/item?id=20481729) does say that:
> > Of course, that's just me. I understand why someone would want to turn Vim into their personalized powerhouse editor with IDE powers, with their .vimrc a 'git pull' away.
The amount of time I spend in Vim not customized is negligible, and I can always hit Esc in those cases with a not even in the ballpark time saving over losing snips and all the custom plugins.
The reason vi(m) is awesome is because it's everywhere and it's (pretty much) the same.
Reconfiguring means trouble when, for instance, helping a colleague or teaching someone, as well as the overhead whenever the configs are lost.
Well you can also invest the small amount of time to type in:
:imap jj <Esc>
Dead Comment
Back in the day when I was a Unix admin, we often worked in full screen terminals and when editing a config file didn't like having to close the vim instance to go look at something, so learned about this little gem:
:sh (go back to shell and do your thing and leave vim running)
Ctrl-d to return to intact and running vim instance.
As an aside, if you decide to use nano to edit config files, make sure you use nano -w (no wrap), otherwise you may find yourself with a non-bootable OS instance.
[0]: https://www.destroyallsoftware.com/screencasts
In nvi (at least), one can also open a buffer and :script to run a shell inside vi and have all the yank/paste/navigation/all-the-things features of vi. Mind you need to i[nsert] or a[ppend] after the prompt to issue your commands.
Deleted Comment
https://www.youtube.com/watch?v=eX9m3g5J-XA
Mainly the idea is to not try and learn everything about vim, but instead pay attention to how you use it, and find things that are inefficient or could be easier, and then go figure out how to make vim do that thing more efficiently.
I remember learning a fair amount from it when I read it a few years ago (and should probably read through it again at some point).
This was misguided and after a year of wasted productivity and wasted time fiddling with plugs and dealing with broken stuff (surely by my own hand) I switched to a professional IDE and I rapidly became a much better developer.
I use vim constantly now but in it's most plain vanilla form, for the purpose of editing files when logged into Linux systems. That's all I use it for.
I really wish however that every Linux system had a clone of the old DOS edit command which was beautifully simply and straightforward and met most needs highly intuitively.
As a sidenote: can I just say that PyCharm is an incredible IDE and I can recommend it heartily to anyone. If your job is programming then it is many times over worth paying the money for the professional edition.
My main vim plugins for this use case:
* go.vim * nerdtree * git-gutter * YouCompleteMe * syntastic + flake8 * black.vim # python equiv of gofmt
This is only for my workstations. I prefer vanilla configs for servers.
The nano editor experience is pretty close to the old DOS edit feeling.
Excellent for editing config files through the terminal.
Vim defines an ergonomic set of rules for text navigation and manipulation, often implemented by very simple key bindings. This is wonderful.
The Vim editor implements all these rules, but the Vim's plugin ecosystem is a disaster. Hacks pile upon hacks. Noone understand Vim scripts. Vim scripts are easily broken and do not interoperate well with other scripts.
These set of rules can be easily implemented by other editors, as evidenced by many IDEs supporting Vim key bindings. Although these editors may not support all the above rules, they are pretty close (see the evil plugin in Emacs) and can replace Vim in daily usage.
The editor war is over. Vim's keybinding is superior. But the longevity of a text editor lies in its extensibility. For this, Emacs wins in the long run.
vscode-vim caused odd performance issues, and I encountered significant bugs with the undo stack (namely hitting 'u' would sometimes take out the last 10-15 changes instead of just one). IDEAvim would randomly go completely unresponsive for me, sometimes requiring just re-opening the file and sometimes requiring a restart of the entire IDE. And last I checked the Xcode plugin requires re-signing the entire binary with a self-signed certificate because the new plugin system won't support modal editing.
I was quite happy with neovintageous in Sublime, as well as Sublime's excellent performance in general, but no matter how many plugins I installed it could never seem to come close to the smarts of the other tools I was using.
Ultimately I just arrived the the conclusion that I'm never going to be happy with any editor and decided to make the best of what I could with a consistent set of keybindings across the tools I use.
That said, every time I edit my hosts file or something on a remote server and reach for vim, I wonder if I made the wrong choice. I'm really hoping Language Server Protocol becomes the standard and we reach the point where it no longer matters what editor we use.
[0] https://github.com/neoclide/coc.nvim
I'm pretty broken by Vim. I don't really want to invest the time to get really good at a non-modal text editor.
- QT Editor - Eclipse - IntelliJ - Visual Studio - VS Code - XCode
At the moment I mainly use VS Code, and I'm still editing much faster, despite the issues (occasional undo hiccups and error messages).
Disregarding color schemes here is my list:
* FZF
* COC (it provides a lot of QoL, functionality of modern editors with it's plugins using an easy seamless yarn add)
* Sandwich
Very few customizations. Mostly vanilla.
Regarding colors, I love to try new ones all the time and my current is scery followed by Gruvbox, and Dracula because they work in Terminal.app and iTerm. They also look nice / easy-on-the-eyes. My friend at work has a thing for Nord and another loves Monokai Pro, but apparently the author wants money for it...? Which seems... different.