Good read. My strategy for avoiding all the vim porn and "plugin-madness" is to never install a plugin or mapping/override without learning to do the thing manually in vanilla vim.
This way you'll KNOW if that plugin is really worth the bloat, and if you do end up away from your config on a remote server you're just mildly uncomfortable instead of dead in the water.
What's with this attitude? The guy wrote a blog post and by definition he can write what's in his mind at his desired level of length and verbiage.
It's not like he was asked to write the eject procedure manual of a spacecraft...
I personally find vin to be a good tool for editing text without leaving the terminal. But when I’m writing a lot of code, I’ve found the vim ide concept to be far more trouble than its worth.
Modern IDEs like VSCode + Vim bindings is my preferred platform
One thing I never understood is why Vim bindings are a big gain when you have a mouse. I see a single edit, it takes me all of one second to click for a large jump, even less for cursor key combos in case of a small jump. For mass edits there is find/replace and find+multi cursor. 80% of my time in the editor I spend thinking about the code anyways - I have zero interest to optimize deciseconds of my time, or worse, optimize my perceived productivity vs. my actual productivity (e.g. forcing myself away from the mouse by ways of pattern matching that increases both mental overhead and time required).
Mouse takes far longer than a second for a selection. Switching between keyboard and mouse already takes longer than typing the usual vim-commands for a simple action.
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 have exclusively used vim keys for years now, but even after that time I find some of this just doesn’t ring true. Anything in vi that involves counting some number is usually faster with normal keys or the mouse. For example moving down 20 lines is way faster with the mouse, you just click. With vi you have to count the lines in your head - better hope you don’t lose count half way because two lines blur together. With lines you can use line numbers and mental arithmetic, but not really for any other number+noun combo.
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.
> For example moving down 20 lines is way faster with the mouse, you just click.
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.
Yes, it's certainly more ergonomic and comfortable. Still, I find the mouse pretty fast overall. But I'm pretty good at aiming at things with it after playing FPS games for a while.
>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.
You don't have to count. I typically make a rough estimation and go from there. For me that still is faster than putting hand on mouse, searching current cursor position, aim, click, and back to proper keyboard position. Of course ymmv
H/M/L is your friend (move to the top/middle/bottom of current screen). Getting to the wanted position usually takes me less time than just moving my right hand to the mouse and back.
Vim bindings operate on commands that can automate many of the daily work you do in a text editor besides inputting text and search & replace. Deleting or copying text inside delimiters or by lines, changing words in place, recording and replaying macros, etc. are all possible with a few keystrokes. Since commands are generic and composable, once you learn the few basic ones you'll be able to come up with combinations of your own that make you more productive over using a mouse and a traditional graphical IDE. If you've ever seen a Vim master at work you'll notice how quickly they manipulate text on screen. It looks almost magical, which certainly makes it difficult to follow for anyone else watching, but to them it's the most efficient use of their time and brain power, since the binding-to-command mapping has become muscle memory. Using a foreign IDE would cripple their productivity.
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.
Your examples of automation are all possible with multi-cursor edits as well. To me it's exactly the right mental model - I can do mass edits with the same commands I've learned in single cursor edits, and, maybe more importantly, I have immediate visual feedback between the edits I compose this way. I'd recommend anyone thinking about learning Vim to give this a try first and then evaluate whether there is any additional benefit from spending a lot of time learning Vim commands.
It's not about optimizing for speed; it's about optimizing for comfortability. Not having to move your hands at all from the keyboard is highly underrated. If you pair it with a windows manager like i3 and use something like vimium on chrome or zathura for pdf, you always have your hands on your keyboard. You don't realize how great that is until you try it. You can't go back to the mouse.
And if your my kind of programmer, you start to move to programs that have VI keybindings, swap out for ones that do, and hack into the ones that don't to make them do!
The whole point of vim binding is to reduce context-switching to the mouse, better maintaining flow.
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.
IMHO Vim's strength come from the ability to operate on any logical chunks of text in a unified manner. Being able to jump around text with the keyboard is hardly a big deal compare to that. For example, to delete the entire body of a function in C, you can type "da{", where "d" means delete and "a{" points to text surrounded by braces. To delete a single sentence, I can do "das", etc etc. Of course, you could do the same using the mouse by selecting text manually, but it's way more tedious than Vim commands.
> I have zero interest to optimize deciseconds of my time, or worse, optimize my perceived productivity vs. my actual productivity (e.g. forcing myself away from the mouse by ways of pattern matching that increases both mental overhead and time required).
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.
Not sure if you over read the second part of that phrase, but I have serious doubts whether the efficiency gains touted by Vim users are real or only perceived. I'd like to see some good hard data on that, comparing users of similar proficiency level at various editing styles.
Honestly, I use vim too, and I have learnt the "language" of vim i.e. the grammar and consider myself an advanced beginner.
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.
Thank you. The main gain I see in vim is being able to edit configs on any server through SSH. In an environment with IaC policy this gain basically falls away however. What's left is being able to do small edits where launching e.g. VS Code would take too long. That's where I still use it.
The gains from vim over using the mouse is mainly muscle memory for me.
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.
I think this can largely be attributed to preference. I have my hands on the keyboard anyways when I write code, so I find it easier to just move with keys instead of grabbing the mouse. For bigger, espacially vertical movements, I usually grab my mouse, unless I know the line I have to jump to. In that case using the movement keys would be faster as well.
I've come to the conclusion that the discrete interface of the keyboard and keypresses meshes well with the discrete nature of text versus the analog control the mouse gives. When selecting by individual characters/lines, I'd much rather use my keyboard and know that for each keypress I'm interacting with some X amount of text than fumble with my mouse until I get exactly what I want selected. Vim keybindings specifically are nice because they provide a pretty universal interface - most applications I use implement Vim keybindings, so there's very little context switching when working with my IDE, CLI file browser, Firefox w/ Vim Vixen, etc.
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.
To me the interesting part is not having to do precise mouse movements.
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.
I wouldn't call VSCode an IDE. It is an editor with plugins that give it IDE features. If that's your goal, you can really customize vim to similar place.
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).
You’re being downvoted because that’s nonsense. It comes built-in with formatting, intellisense, a terminal, a debugger, Git support, and syntax highlighting.
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.
Same. My normal set up is having a shell window with 4 tabs:
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.
If you can move your tabs to tmux, you will greatly improve your situation. It's easy.
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.
I use tmux to group shells by context, setting a shell variable that various things in my bashrc respond to. The biggest win is a separate bash history per context, so my commands related to project A don't get mixed up with my commands related to project B or my sysadmin commands or ...
What language(s) do you develop in though. I found this was fine for certain languages, but others such as C#, swift or perhaps Java really suit having a fat IDE. Or perhaps its me?
I also use a digitalocean droplet for my development, but I'm programming in Python, bash, JavaScript/HTML/CSS, PHP, MySQL. I wouldn't do this if I were using Java, Java without an IDE is painful.
Counterpoint: it's my editor on my computer, the most important thing is me understanding my own tools and being able to use them comfortably. So while I try to not deviate too much from standard shortcuts, I'm not afraid to make mappings for things I rely on more. At the same time I also dislike complex plugins that add crazy amounts of extra complexity.
Bro I don't mean to make you the shining example of what I'm talking about but can we please try to be succinct with write-ups? The whole first half of the article could've been summarized with a single sentence: "As is typical with newbie vim enthusiasm, I spent many hours producing a 1000+ line vimrc over a long time that I eventually realized complicates my word editing process more than it helps."
Thanks for the honest feedback, but I think everything you want summarized is in the summary at the top:
> 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.
I don‘t agree with rapferreira. I liked that the article included the actual technical details, including these that were the “old” solutions. Some insights are impossible to be achieved if the details are omitted.
I think it makes sense in context, where many tech enthusiasts do almost fetishise their or other's configurations as nerd cred. Just look at /g/ board on 4chan, people post their neofetches and compare kernels..
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..
I found it informative and enjoyable to read. I'm glad it had the details that it did and would have gotten less out of it if those details had been omitted.
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"?
I can't help remapping ; to : and vice-versa. Can't think of the last time I needed the default ; and sparing my pinky from having to hit shift every time I want to ;q is a game changer. Obviously, that's annoying to change in every vim install but I just have a very light .vimrc that I curl in every new box
I use a git repository for my configs that also includes scripts to install the configs and packages for different environments from the bare minimum to a desktop environment.
I’ll try remapping :, sounds like a good idea
The answer is I don't. I make heavy use of /, but for navigating within a line I make do with *#^$w.
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.
> I started to look at Vim as a line editor first and a text editor second. Indeed, if you look into it, the original intention of Vi was to serve as a visual front for a line editor called ex. And I think it shows. What it means in practice is that Vim encourages you to start your edits with the cursor placed at the start of the line. When you are in this place everything goes smoothly. And when you go against the grain all kinds of bad things start happening.
Noo I like tabs! Maybe you can explain to me, I genuinely do not get why people are religious about spaces instead of tabs. You have to backspace more times to get rid of an indent!
<< to get rid of an indent. People are religious about this because if you use a shiftwidth (or sts) different than your ts, you end up with a mixture of tabs and spaces. If you change your ts to something other than 8, then you end up with code that looks weird on everybody else's screen.
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.
I think everyone knows the rabbit hole problem that this kind of article is warning against. Especially for beginners.
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.
If your .vimrc is minimal, you will have a pretty good time using systems that implement "vim like" text editing. Take Overleaf for example, no vimrc is available, but I'm quite happy with what I got, and sometimes I even forget I'm in the browser.
> If your .vimrc is minimal, you will have a pretty good time using systems that implement "vim like" text editing.
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.
This should be cited whenever monstrous dotfiles are produced without understanding the reason for defaults.
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.
+1 to waiting a bit, incurring the inconvenience, and seeing whether you come across alternate solutions. Often the first thing I think of (customize, or install a new package; both of which incur maintenance costs) is just masking not understanding another aspect of Emacs.
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.
> "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."
I can't stand this. If Chesterton thinks he has all the power, why doesn't the onus to know "the use of it" fall on him? He should be responsible for documenting the purpose and motivations behind the fence, if he thinks he's such a protector.
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.
1. Wanting to remove the fence is a statement of "this fence does more harm than good" and if you say "there never was any reason for this fence to be built" it's very strong evidence that you did not spend sufficient time investigating the fence's benefits. Chesterton doesn't care about the protecting the fence, he cares that the person who wants to remove the fence thinks it through all the way first.
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.
That would make sense if the defaults we were talking about had been carefully selected five or ten years ago or shown any signs of evolution since they were first laid down in 1975. If I was editing code in the languages they used in environments like theirs using underlying tools that performed like their tools in a codebase the size of `ex`'s, I'd certainly trust the defaults. But I'm not doing any of those things.
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
One of these things that aged really badly is : for command mode. On the particular keyboard that vi was made on : was accessible without modifiers, but on virtually all other keyboards it needs shift and is not a good default. Comma (,) would make much more sense. I'm sure there are other instances where the keybind initially made sense on the keyboard the devs were using that nowadays makes less sense.
I have followed a similar vim path, although my vimrc file never was close to 1,000 lines long! I used to use many plugins though including nerdtree, airline, and surround. But in the end it was always difficult to maintain that setup long term.
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
I once decided to try an online vim profile generator when setting up after a disk crash, to save time re-creating my simplistic .vimrc. It was awful. All sorts of things I never used normally in Vim, forced down my throat. Manpage-reading plugins, bizarre brace handling, different buffer control, and a Day-Glo colorscheme implemented in some annoying-to-override fashion.
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.
Have you tried using Doom Emacs? The process of installing everything you need for a particular language only involves uncommenting a line on your config and running "doom sync". It's really good.
I haven't tried Doom/Spacemacs yet. The same thing that keeps me from installing vim plugins probably keeps me from installing large "frameworks" for emacs. Doom does seem relatively lightweight and I'll give it a try at some point this weekend.
I can't imagine remapping any of the standard commands. What if you have to edit something as a guest on someone else's system? Just get used to it and deal. I've been using it (in "vi" form) daily since 1985 or so and doing any of those remappings would drive me nuts.
> Now, after all the struggle, my vimrc is around 50 lines in length. It only includes simple and frequently used commands, like this map to toggle search highlighting with ctrl-/
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.
Regarding to the remapping for Y, I also only memorized y$, c$, and d$ and they seem more natural to use for me.
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.
It's been a while since I started using vim. I can see some similarities. Though, I didn't really do much configuration in the early days. Currently, I have pretty much no configs when it comes to key maps or some custom or shortcuts. I only add plugins for code completion and highlighting. Nothing else.
Honestly I'm the same, my .vimrc is mainly set commands for line numbers, highlighting matches, basic folding and setting backup/undo/swap directories.
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.
Exactly! I like being able to log in to any server and use vim/vi without any issues.
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.
The portability aspect seems overstated, or perhaps your use cases are just different. I can already log in to any server with my custom configs; Ansible is what configures my user already, so I just have it dump out my configs. If I can access it, it has my configs.
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
How many times does one remote into a server and then spend significant amounts of time editing files? Usually I make small enough edits that I don’t miss my custom keymaps
My journey started when someone just dropped their .vimrc and I tried it out... So I'll do the same: https://tinyurl.com/y4d7rx6f
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.
i just keep a repo of public configs and curl them to any new machines and have a simple script to symlink the various configs to their expected locations
> This article describes my Vim journey, starting from heavy personal customization and ending with a renewed love for defaults
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
This pattern is also seen in almost every enterprise application purchase I've seen over the last 10-15 years. The process is as follows:
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
2) SAP
3) Jira (twice)
4) PeopleSoft (twice)
5) Workday
6) ServiceNow
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.
> while ignoring the fact that X's 10000 customers seem to do fine with the default configuration.
Do they?
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.
Oh yes. I'm going through exactly that with Jira right now. Not that I'm at all a fan of the thing, but when you look at what's there, you get at least a sense of how Atlassian thought it should be used.
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(
Do you disagree in only this specific case or do you disagree in general and cite this specific case as being emblematic of why they're wrong? It's not clear to me what your point is.
I also find that vim defaults are very lackluster, I could spend all day listing its faults:
- 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.
> 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)
This, people in this thread are talking like the defaults like they were handed down by devine beings from the ancient past. The truth is that they are often just warts from and old past that can't be removed for backwards compatibility.
My personal vim ethos: You can, and you SHOULD tailor it to yourself.
I've always seen it as a trade-off based on what I'm using Vim a lot for. When I'm using Vim remotely on a hundred different systems I admin, then having a good grasp of of being comfortable using the defaults is extremely useful, and it feels painful to try to use something that's not enabled by default that is my preference. When I'm doing developing something more complex, I definitely appreciate more customization.
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.
Managing servers was why I started using vim other places. I started to use it for basic text editing and for coding, just so I could practice and not feel dumb when I needed it (far too often) on a production box. I also avoided too much customization for this reason too.
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.
It’s found on an matter really. People just get bored, obsessive and eventually "fatigued". No editor makes a boring job better, but some make it worse.
Honestly same. The vim integration in vscode is good enough, and the IDE features make refactoring and editing so much easier.
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.
Ever since I started using vim exclusively for development a couple of years ago, I deliberately decided not to use plugins nor to edit the defaults unless strictly necessary. Nowadays, my .vimrc is just a few lines, all regarding indentation.
It had worked for me so far and I never really felt any less productive than when I used IDEs or VS Code.
