Modern IDEs like VSCode + Vim bindings is my preferred platform
And casual keyboard-commands just don't scale well. Moving cursor x chars means you must type the movement-key x times. With vi you just type the number x and the movement, and usually save big time.
Aditionally, vi has more knowledge about textual objects, which are all interchangable. So whether you move 3 chars, words, paragraphs, pages or functions, it's all the same, just with different letters.
Vi's command-language is highly composable and thus very dense, so it will alwys be faster than mouse and casual editor-commands. Of course as long as you habit them.
I recognise there are other better ways to move around but they too often have drawbacks, like moving somewhere with ‘/‘. You have to parse the line you want to move to for a unique string that’s close to where you’re going. Then you have to scan over all the text in between to make sure it doesn’t occur too much there.
Maybe I’m still just doing it wrong.
Correction - you must move your mouse hand from the keyboard, move the mouse to the desired location, _then_ click.
Ergonomic concern often goes side-by-side with editors like vim.
I'm also not convinced that comparing the simple editor things is demonstrating the value of vim much. It's how easy vim handles the _not_ simple things, and also how easy it is to motion the often unique or rarely used edits, combined with drop-of-the hat programmability, that makes vim a good choice.
>how easy vim handles the _not_ simple things
Agreed, despite any minor differences in movement speed, even '.' by itself is useful enough to never switch back.
While it's true that most programming is spent thinking about the problem rather than manipulating text, the benefit of modal editing and Vim bindings is not only in the saved time, but also in removing the barrier from thinking about how you want to change the code to actually changing it. That leaves you more time to think about the problem, but also doesn't interrupt "the flow" by having to think about moving and positioning a mouse cursor in a GUI, which is always a more mentally draining action than typing a few keystrokes.
Once you get good at Vim + a tiling window manager, constantly swapping to a mouse to do things interrupts your flow. It’s akin to forced context-switching, which programmers hate because that also interrupts flow and concentration.
But it does take practice to master enough Vim commands to be able to use it without referring to help docs (which also interrupts flow). You won’t really understand this flow advantage until you’ve done that.
Fwiw, Wall Street culture has something similar around Excel. The best, most proficient Excel masters can use Excel with keyboard only, no mouse, b/c they’ve mastered all the keyboard shortcuts for navigation, data entry, and calculation. They judge each other based on this ability. It’s not unprecedented in the software development community only.
I think you just said it. Its not interesting/nor a priority for you to optimize things to that level. Those using vim properly and trying to move away from the mouse consider it better for efficiency and ergonomics (debatable).
Its not that you fail to understand. Its more so that you don't care that much.
I have doubts whether the efficiency gains are that useful in every day life. There will some days where I make some pretty widespread refactoring changes over files or the yanking/register stuff can be quite useful, but in general, every day programming, I don't see the efficiency gains.
I have another theory for why people like Vim so much.
Using vim makes you feel like the old-school, crazy powerful, very smart programmers shown in Hollywood. It makes you realize the dream that the little child had when he saw programmers on TV. ( at least for me ) and honestly, its more fun to be doing that so I do it. :)
Maybe I am not that good at vim. But at my level, i don't see great efficiency gains. I simply see more fun gains, and that's good enough for me.
Vim bindings are a gain because you don’t have to use the mouse.
I can comment out a function/block/line from anywhere in the function without looking at either the screen or the keyboard. And I do it without consious effort.
You probably use keyboard shortcuts to go to the end/start of the line anyway, if you expand that to all the vim movements that's what you gain. Adding composition and macros are just the icing on the cake.
Also, I find that preventing constant movement from the keyboard to my mouse and back helps mitigate wrist pain and discomfort from long sessions at my PC.
With vim bindings it’s easier to do things like rewriting arguments in a function, without having to carefully select them with a cursor or using ctrl+shift+Right arrow the right amount of times.
The speed I find it’s only a plus when having to work with old/sluggish machines, because it breaks my flow way less, but that’s completely personal preference.
If you don't mind moving back and forth between mouse and keyboard, or smashing ctrl-arrow to move, then it's fine.
VSCode is at the edge of an editor and an IDE though, or so is my feeling at least. I feel like the massive need for ease of use and speed clashes with the needs of power users (e.g. for Java EE or database developers), and that this push vs pull might to be the downfall of VSCode in the future (unless MS throws a pile of money and devs on the codebase).
Secondly, trying to discern between an “IDE” and a “text editor” in 2020 is a fools errand. It’s pointless because there’s such a grey area between where one definition starts and ends.
1. Text editing
2. Command Line
3. Program logs
4. Code console
Flipping through them is a breeze, and I never have to leave Terminal. The displays are always simple, straight forward, and focused. No distractions. I'm able to just get in the zone with the code and forget anything else exists.
Then you can, for instance, make your development machine a dedicated cloud server, like digital Ocean etc.
This is what I do and it's very nice to be able to use any hardware I want, including cheap underpowered stuff, since it's just a window to my real machine.
It's very nice!
I mean come on..
> Vim is a highly customizable text editor geared towards writing code. But open-ended configuration possibilities often lure users into wasting time while chasing after perceived minute gains in productivity. This article describes my Vim journey, starting from heavy personal customization and ending with a renewed love for defaults.
One can read it, take the message, and move on.
However if another reader wants details, it's hard to know upfront what kinds of details he/she will care about. Hence, based on the premises in the summary, the article expands on: 1) the ways in which Vim can be over-configured; 2) some examples demonstrating the possibilities of changing default behaviour; 3) the benefits of scaling configuration down; 4) Summary and additional notes.
You might only care about one or few of those. However this, I feel, is where you would have to selectively skip some sections, based on your own judgement.
And I'm pretty sure it's not just "noobs" that focus that much on customization, but of course their attempt will more likely be unproductive.
Let's all just move on from this trend of things that are sexy in a category being regarded as 'porn': earthporn, cityporn, natureporn. Maybe I am getting old..
Of course it's fine to value succinctness, but it sounds like your saying the author did something wrong or that he owes you something. Maybe "I found there were too many details and would have preferred it was much more succinct; for example..." would have been a better tone than "can we please try to be succinct"?
map ; :
It's kind of cool how you can get two Vim power users (not a group I count myself among, mind) in a room together and find they use a completely different subset of features.
nnoremap ; :
nnoremap : ;
I was like, wtf, remapping all this stuff?!! argh!
Here's my minimal vimrc if anyone is curious https://gitlab.com/jane314/settings-and-scripts/-/blob/maste...
However people insist on using spaces. Like between words in sentences or between tokens in a line of code.
Spaces are better than mixing tabs and spaces, especially with "modern" (newer than 30 years old) tools. Especially if you use these editors enough that you are never indenting manually with backspace or tab/spacebar.
So the options are tabs+spaces mixed together or just spaces unless you are dealing with tab delimited files with no spaces in them, which is rare.
The tradeoff is you lose the ability for different people working on the same thing to see different indentation levels. In exchange you don't regularly get your formatting confusing messed up because of some kind of invisible control character confusion.
But as a counter-example:
I've done most of those "types of vim porn" I guess, then moved to spacemacs, then my own custom emacs/evil setup. Always with some similar window manager and command line tweaking as well.
Probably spent a hundred hours on all this kind of thing easily, in a small number of big bursts.
Over 20 years.
During which time I've had a very comfortable, understandable, debuggable and pleasant dev environment that made development, testing, documenting, debugging and planning a thing I can just work on without really thinking about the tools. Switching between the files, the command line, the failed tests, the docs, the repls and the browser tabs as fast as my eyes move.
I don't need to break out that one efficiency-tradeoff XKCD either because while it was definitely mathematically worth it time-wise, there is no question the wins were happiness-wise and not-swearing-at-my-tools-wise (just the project code).
Learning to type was probably a better ROI, can't think of what else is in the ballpark though.
This has not been my experience, fwiw. Everywhere implements "most" of what I do, but I still wind up hitting something in the unimplemented portions pretty frequently.
I often see Emacs newbies stealing hundreds of LOCs from different sites, only to end up with a lot of added complexity that is hard to understand let alone maintain. I imagine it's the same for Vim.
Emacs defaults are quite usable. I've been using Emacs for 15 years and I'm only altering a dozen variables. The rest of my .emacs is simply use-package directives. As I become more proficient, I trim down my dotfiles, not the other way round.
Some defaults seem to be there for historical reasons. When I see such a thing, I wait a few months. If I'm still convinced the default is legacy code, I try to lobby for a change. I've found that developers tend to be very receptive if changes can be well justified. E.g. there's a long discussion now in emacs-devel on how to modernize many defaults and make the editor more friendly.
My goal is to push all my dotfiles upstream, and end up with almost empty configurations. And I'm getting there.
Every few months, if I'm not 100% on the utility of a customization/package, I'll remove it and see if I survive without it.
This beats having to declare config bankruptcy.
Anyway, this stance seems to be what separates conservative from a liberal. Conservative want to protect something that exists but he has no knowledge of reason - such as people protecting slavery, racism, etc. Putting up barriers against people trying to change world for the better.
2. It's not hard to come up with reasons for slavery and racism to exist; that's all you need to do to satisfy Chesterton. I'll even go a step further and say that for societal issues if you don't have at least a basic understanding of the forces that caused them to exist (and cause them to continue to exist), then you will probably fail to change them anyways.
3. Fences take time to build. It's very rare that you get eccentric people putting fences up randomly (rare enough that discovering that to be the cause of a fence should be pretty easy because it would be so notable!)
4. Because of all of the above, I'm going to say that it's not really the difference between a conservative and a liberal, but it is part of the reason why younger people tend to be more liberal and older people tend to be more conservative. Understanding the lesson of unintended consequences puts pressure on the "conservative" side of the scale, and it can be an excuse for conservatism. However, Chesterton's fence is an important engineering principle that should be taken into account when making policy regardless of your political leanings.
The simple truth was that, no matter how
much energy I invested in my custom configuration, the
people who built and designed Vim knew it a lot
better than me.
Today, I work in a codebase whose human-readable source alone might be larger than any installed digital storage system that existed when vi's shortcuts were chosen. By necessity I navigate it with semantically-aware indexing and information-retrieval tools that would have been miraculous back then. My edits are guided by static analysis and effected with automated refactoring and code generation tools.
My configuration doesn't suit my environment as well as vi's defaults suited their environment. It does, however, suit my environment better than vi's defaults do.
And let's not even get into emacs configurations. :P
I do try to add a few shortcuts to my .vimrc file though which is pretty minor:
- jk maps to escape
- oo and OO map to create a new line below/above but stay in normal mode
- leader \ to clear highlights
and that is about it!
Whenever I use vim without my config I wind up hitting Q and entering ex mode and wishing I had my config.
I've used vim on and off for at least 6 years and have never installed a plugin. Vim is great for quick edits, arranging text in temporary files (control x + control e in the terminal, quit without saving), moving chunks of code around, running macros. Its also great to use the keybindings in your favorite electron IDE.
I'm just not a "plugins" person. I've been trying to set up a python environment in emacs for a while and it hasn't been fun. Its an iterative process of installing a few plugins, getting something buggy and slow to use, and eventually getting fed up and restarting from a minimal config file.
Emacs has been amazing for magit alone, I just wish I was good enough at it to use it for more things.
Vim? Its my barebones text mover that has keybindings in countless apps. That's all it needs to be.
Isn't the usual one (perhaps it's even default) leader (default \)-l?
I used to use Esc, which honestly I really do prefer (intuitivly - I'm in 'search mode', ESC to get back to normal), but it's somewhere between painful and impossible to portably implement without weird bugs, so I eventually gave in.
Therefore, I remap D to delete the whole line, but do not put it into any register. This allows me to cut a line with dd, while I can throw away a few other lines with D to clean up around the target location, before finally pasting with p.
nmap D "_dd
vmap D "_dd
I work as a JS Dev on a large(ish) React project with Vim, so I realised I did want modern facilities such as Coc.nvim and denite.nvim which are my two weaknesses. I tried using `set wildmenu` for a while but I found it difficult to use compared with my denite leader+r using rg.
Other than that I have four Tim Pope plugins (vinegar, fugitive, surround, and commentary). Fugitive I could live without as I rarely use it but I could not live without surround - I'd say it's my most useful plugin and doing the same in Vim was awkward.
I've noticed similar pattern with other tools, e.g. git. I've seen coworkers add all kinds off aliases to simplify git commands, and I'm very much against it since I prefer portability.
Admittedly, it does get annoying when I'm sudo-ed to another user, but it's vanishingly rare for me that I am both sudo-ed to another user, and doing enough editing that I really want those configs. Usually a sudo-ed vi for me is just updating a couple lines in a config, I don't need a full config for that
Typically I clone that into my home directory. Then I link everything to it with:
ln -s ~/vim/.vimrc ~/.vimrc && ln -s ~/vim ~/.vim
The .vimrc is kind of documented, but a quick version is:
tt: select a file name to open into a new buffer
fr and fR: go forward or backward through buffers (open files)
fd: close buffer
f2: if the needed commands are installed, reformat code
There's a few other remappings, but those are the most frequent ones I use, hence making it easier.
<tab> completion works everywhere as well. There's a bunch of other stuff for navigating windows and tabs, but once I realized that "buffers" are actually the "vim way" of file navigation, I stopped using those short cuts.
Edit: Yes I realize this is probably what the article is complaining about, but oh well.
se ts=4 #1 tab= 4 spaces
se ic # ignore case when searching
se nows # don't wrap to top when you reach end / beginning of file in a search.
I could add a lot more, eg a json / xml formatter but never got around to it in 21 years.
It had worked for me so far and I never really felt any less productive than when I used IDEs or VS Code.
this exact pattern is found in so many vi|m articles and is touted as a triumph of vim's default patterns, when it is really a failure of vim to support whole ranges of functionality. as a daily user of neovim, i know that vscode is a superior alternative and am waiting for a month off to transfer all my vim customizations to a real ide
1) RFP, RFQ then purchase your ideal enterprise application.
2) Start customizing it to meet your old way of working (and before you really understand it) while ignoring the fact that X's 10000 customers seem to do fine with the default configuration.
3) Complain that it won't really let you work the way you did a) on the mainframe which was designed based on b) the way you did it with paper and pen.
4) Throw in the towel or force your users to adopt some practice that was neither a) your original process or b) the vendors optimized process.
I've seen this pattern with:
1) Oracle ERP
3) Jira (twice)
4) PeopleSoft (twice)
7) Remedy (twice)
One of the most solid recommendations I can give is that when you purchase a software system, don't do any customization for the first 12-18 months.
P.S. Okay ... go ahead and put your logo on it.
If you've seen the pattern you describe almost everywhere, and the key second steps (well, “customize out of the gate to fit your business processes”) are exactly what the vendor markets heavily, what makes you think there huge numbers of customers who are both not customizing and doing just fine?
I've seen and heard of a few cases where customers use software of that kind and minimize customization of the software and instead try to adapt their business processes to the software. And usually those are at least as much horror stories as any heavy customizers.
Really, as much as it's not in the vendor’s interests, big bang implementation of this kind of software that becomes immediately central to a wide array of business processes is probably a bad idea for the same reason that big bang software system replacements usually are, even when there is no existing software system being replaced. Incremental, iterative improvements to business processes and supporting tools are probably a better idea. But big-bang, notionally close-ended projects are more succinct “achievements” on manager/executive CVs resumes, and no one is courting buyers and giving out swag for continuous improvement.
Enter some individuals who think that they know better and have determination to force that Jira-shaped peg through their round hole, even if they have to use a jackhammer to do so. The result is the worst possible outcome, and every user gets to pay each day for it. m(
- hjkl is not a reasonable default mapping for motion, for one it doesn't make it obvious that j is down and l is up since the keys are next to one another (which makes it a lot harder to memorise in the first place) but on top of that it wastes two very premium home row keys, h and l, for something that you really shouldn't end up using a whole lot (b, w, f, t, e and friends are usually much more efficient for moving on the current line).
- To make matters worse, the one key that's easiest to access on any keyboard, the space bar, is... just doing the same thing as l, it moves right. So now you have two of the best keys on the keyboard mapped redundantly to a relatively little used function.
- What about the enter/return key? It does the same thing as j, it moves down. Brilliant.
Those are just minor nitpicks of course, but I have a laundry list of those if anybody cares to hear them. It's littered with small inconsistencies and idiosyncrasies that stem from historical baggage and not actually trying to design an ergonomic editor.
That being said I don't get where you're coming from with VScode. Do you consider the editor part of VSCode to be better than Vim, or are you talking about Vim failing as an IDE?
It's important not to mix things up, VSCode is an IDE, Vim isn't. If you wanted an IDE and tried to get Vim to do that by adding 3MB of vimscript from various sources to make it work I can't blame you for giving up, it's probably going to end up being a mess.
> but on top of that it wastes two very premium home row keys, h and l, for something that you really shouldn't end up using a whole lot
Even if with all the advanced search and move features, I still use the h and l keys pretty often. Being able to skip to a certain character is nice, but I find pretty often I just need to move a few characters forward or back, and a mindless `lll` is much easier than doing the mental math of which character I want to stop at and using the appropriate navigation command.
I've also grown to appreciate that the default keys are the most basic commands: on the right side, single-unit navigation, and on the left, basic character entry/removal.
> To make matters worse, the one key that's easiest to access on any keyboard, the space bar, is... just doing the same thing as l, it moves right. So now you have two of the best keys on the keyboard mapped redundantly to a relatively little used function.
I'm actually very thankful for this. I never thought about it before, but I realize that I never use my thumb when in Vim (other than to add spaces when typing normally) and I _think_ I like that. It let's me concentrate on the other fingers. Might be a matter of practice, but as it is I don't feel a need to incorporate the space bar or my thumb into my vim commands. It lets my thumb stay "dumb" so it doesn't interfere with any non-vim typing habits.
> If you wanted an IDE and tried to get Vim to do that by adding 3MB of vimscript from various sources to make it work I can't blame you for giving up, it's probably going to end up being a mess.
Agreed with this. For people that want to work in an IDE, they shouldn't work in Vim. Personally I dislike IDEs, and in part use vim to stick to a (relatively) simple editor.
It's the same order as Dance Dance Revolution ;)
My personal vim ethos: You can, and you SHOULD tailor it to yourself.
Vim (or at least some vi derivative) is semi-unique among many of the more complex tools we use in that it exists by default on just about every Unix host you connect to, so it has sort of a dual life in that respect. It's many people's go-to tool for local development, but it's also the default tool you can rely on for text editing remotely. Those use cases have somewhat separate pressures they place on how people use it.
Still use vim for as much as I can. The language is too rich, and there’s a lot of muscle memory I’ve built up. It also tickles some part of my brain that’s always looking for better, faster, more effortless ways to do things, so I feel like it prompts learning in ways no other software I’ve used does.
What about vscode makes you like it over vim? I use nvim + coc for Intellisense and prefer it to vscode with vim mode.
... I now realize you may just be trolling.
I know that you can get good LSP integrations in vim, but the problem is that discovering the features available to you is impossible in a text-first UI. In vscode I can go through menus, I can right click and see available refactoring options, etc.