There's been a number of "anti-vim, use a real ide(TM)" posts coming into my feed lately and I don't get why. Do people really get buttmad about this?
I switched from vscode to vim as I found it to be largely much faster in getting around when I started my new job, some people find the opposite. A ok.
Why do people try to force us into these largely closed solutions? ( Mainly it's vscode, which has a real EEE threat)
IME, it's because when you view vim as just another element in a list of "things that let me write code into files", where sibling elements are "IntelliJ", "vscode(ium)", etc, then vim comes off as looking like "gedit but with keyboard shortcuts and no discoverability, oh but you can research and install and configure a million plugins with no overarching design cohesion and you also have to maintain and update them". As opposed to many other editors/IDEs that are designed holistically and more intentionally, and have a much higher "just works" and discoverability factor.
From that angle, yeah, it's probably fair for people to look at vim and go "what even is this".
I think the right way to look at vim is "it's a powerful editor that is installed on almost every linux box everywhere that is deeply customizable and extremely flexible".
Seldom a week goes by where I'm not ending some ridiculous shell pipeline incantation with "| vim -" to dump it into vim and then do further investigation there (with regex, find/replace, etc etc support).
So, I consider myself a vim fan, but I don't use it for day-to-day coding but I still consider it an important tool in my toolbox.
I do think there's a crowd, too, for whom customizability for the pure sake of customizing is a big feature. And that's fair too. But I think that really tends toward being for amusement rather than productivity gains. Which is fine! Lots of software is for having fun, and having fun adjacent to being productive and make it easier to be productive. So I'm really not bashing anyone here, promise!
Does (neo)vim offer a similar debugging experience? Visually stepping through code and setting break points and stuff?
I like vim's code navigation, but I miss the autocompletion features of bigger editors. Can you make vim tab complete like sublime? Last I tried, it was never as "one key to rule them all", but required some additional finger-fu and attention. Also moving selected code around (so I can make engine noises) is a must.
Something about VS Code just feels wrong, but it's pretty much exactly enough of an "IDE" for me. Tho, I strongly dislike the project based file management. Would like to have a solid vim setup instead.
It's the time wasted. Look at a guy merging 30 conflicts in text mode for an hour :D
I think there can be clever specialized vim gurus, but god the ones I work with just struggle so much while idiot me click 3 buttons in an IDE and move on.
We're not paid to be clever, we're paid to make money.
I've never gone for vi(m), even after roughly 25 years of using Linux now.
I'm not trying to force you into anything, certainly not anything closed. I used NEdit until its lack of utf-8 and ancient GUI library started causing trouble. Then I used Slava Pestov's JEdit, which was wonderfully extensible and portable. Now I use vscode, which is just so outrageously well made that even electron and Microsoft can't scare me away from it. All are open source. (Don't know what you mean by EEE threat, googling it doesn't help.)
But modal editing is just a bad idea. We've known since the 70s. One of the most solid things to come out of behavioural psychology was the idea that switching contexts - so that the same thing does something different - has a cost, and isn't a great idea when designing a user interface. Imagine you had a car with stick shift. But you also had a little button on the dashboard, which, if you pressed it, toggled so that the stick shift controlled your car radio instead of your gearbox.
Obviously, that would be a terrible idea. Still, people might get used to it. They might even get so used to it that they would defend it and complain when the feature wasn't there.
All I see that's really different about modal editing is that the stakes are lower when you make mistakes. But it's, bizarrely to me, become a matter of prestige and pride for some to use an antiquated UI design. I'd understand it if you grew up with it, but odds are you didn't. Even the guy who tried to push it on me back in the 90s didn't either. It's like everyone's zipping around in electric cars, and some people still swear by those gear/radio sticks.
That is an unfair comparison on the edge of a strawman. In vim, you see your mode right at the cursor shape (bar in insert, block in normal, selection in visual). It’s like saying that DEs are bad because switching active windows is modal. Why not send input to the first window in the taskbar by holding ctrl and to the second by holding ctrl-shift then? Does that sound absurd? Even when you make a modal mistake once in a while, no stakes are lost because uu.
One thing I agree on is that UI could use more graphics, smoothness and features. But all my attempts to adopt vscode failed miserably. It’s just too mouse-y and too configure-y but still lacks futuristic features I want.
I agree on the graphics part. I've tried doom emacs for the graphics, but it's not quite the same thing. On Mac, though, vimr[0] had a nice UI for neovim. On linux I'm yet to find a neovim GUI I'm happy with.
Yes, visual feedback reduces the chance of errors with mode switching. I believe (correct me if I'm wrong) it's one of the improvements vim has on old vi. Unlimited undo is another one vi certainly didn't have from the start.
I did say the stakes are much lower. But shouldn't we make less critical interfaces with the same care we make more critical ones?
And yes, many things we still have in UIs are arguably mode switching and bad, it's just we haven't figured out better ways to deal with it. With editing we did, long ago.
How is it easier to move your hand to a trackpad than it is to keep your hands right on the keyboard, do `ci)` which is (c)hange (i)nside `)` to delete all of a function's parameters and instantly be retyping them?
I don't understand how you can speak so authoritatively as if I'm accessing a completely different part of my brain when I'm using vim modes when I'm telling you that having to navigate a cursor to click, drag, and select all text is so much more context switching
And also, that ci) command? It's a language. You can do `ci"`, which is (c)hange (i)nside " to instantly change a string without having to hold the backspace button or manipulate a cursor.
I see your point, but I think we’re held back not by UI, but by input methods, including physical ones. And I partially attribute that to vim’s [niche] success. It’s so annoying to hold ctrl-shift to select anything in windows-likes and personally I make much more mistakes while properly fingering the keyboard in these than while using vim modes. The path I see is to make better keyboards with separate keys for fundamental edit ops like selecting, language switching, word/structure navigation, etc, and then some more. We’re too stuck in these typewriter interfaces.
Citation please? I mean, from a personal point of view I'm mostly in agreement with you, but your post reads like a straw man argument with a non apology affixed. "Not trying to force you into anything" followed by "modal editing is just a bad idea" just reads like judgmental noise to me – can it can be backed up with actual research?
Meanwhile vim (and variants) exists and are hugely popular and so to me it seems that by definition modal editing can't be that bad an idea, or such multitudes of people simply wouldn't use these tools and they'd die out. Doesn't this kind of invalidate your argument?
I'm a staunch Sublime Text supporter myself, having paid license fees since 2011-2012 sometime. I've dabbled with vim and friends but never really "got it" – yet I don't presume that my inability to see the light means there isn't one to be seen.
> It's like everyone's zipping around in electric cars, and some people still swear by those gear/radio sticks.
Anecdotally, the vim users are the ones "zipping" around their code. I can't remember a single time thinking it was painful watching a vim user when pair-programming. In contrast, it's often quite painful watching someone slowly point and click around their IDE.
Yea, it's a little difficult to describe, but it's more than just pure speed, it's mental load. Vim let's me integrate the entire development process into a single flow. This is true fractally: from typing all the way to being able to comfortably live inside my screen sessions.
It's difficult for me articulate how valuable it is to maintaining flow to almost _never_ feel like I'm switching muscle-memory contexts, where my text editing and screen switching and file-handling and model-training and everything else all feel like I'm in the same app.
I've never come close to achieving this using a graphical IDE, including with vim keybindings.
It obviously requires up-front investment in a way that more newb-friendly GUI tools don't, but I was lucky enough to make that commitment in college, when the initial hit to my productivity was practically costless.
How can you tell modal editing is bad without having used it? You said you've never gone for vim in 25 years, how then can you know what model editing is like? Because you read some behavioral psychology textbook?
Your comment is by far the most ignorant one I've come across on hackernews.
Take my advise, go ahead and try out vim for a few weeks. Then even if your opinions don't change at least you'll have an ounce of credibility
You have started with an opinion and a theory of why vim doesn't work for you. This is perfectly valid. After all who knows you better than you? Then you launder that opinion through an appeal to entirely hypothetical authority "We've known" and bad analogy and what comes out is eternal truth as authentic as the town facades in a cheap western movie.
It's a bad analogy because a car's controls are operated while carefully piloting a ton of metal at life ending speeds around 17 assholes on their phones while your editor is operated safely at your desk. Your car also has few enough vital controls that they can all be given a physical manifestation while your editor has a lot of functionality and most provide some way for you to access all of this functionality easily. All options have some downsides and mental overhead.
You can provide a wide array of buttons possibly in sub and sub sub menus see content creation applications. Specifically 3D modeling apps.
Filtering options as you type. Consider application launchers on most platforms where you could type Fir<Enter> to launch Firefox.
Sequences of shortcuts after you have exhausted the standard fare. See Emacs default key bindings for an extreme example.
The thing is that even Holding down Control while you press c is an example of a modal action. The C key either inserts its character or copies selected to a buffer based on whether the control key is held down. This is modal!
The same is to a degree true of sub menus as the functionality presented changes based on which menu is open and which options you have picked previously.
You are to some degree paying the inevitable cost of navigating a large number of functions and the only thing you can do is either forego the power of additional functionality by using simpler tools or figure out how to pay it in the least expensive fashion.
You've elevated your preference to how to pay this tax to a scientific choice and reduced a massive number your fellows to Luddites in an abusive relationship with their editor defending their choice with misplaced pride. I invite you to consider that perhaps 1/4 of your fellows aren't simply idiots and perhaps there are reasons that for them this method of dealing with complexity is effective for them.
The best tip imho is to use `vimtutor`. It's installed on every machine that has vim (to the best of my knowledge) and provides an interactive tutorial that builds on itself to teach vim knowledge. It's really cool, if you haven't checked it out just fire up a terminal and give it a play.
Vimtutor is what finally got me into vim after trying it and quickly abandoning it a couple times. The interface finally "clicked" in my head and I was able to edit text quickly with a little practice. I've used vim a lot more since.
I honestly can't stand editing large amounts of text without vim after learning it six years ago. Writing social media comments in a <textarea> is one thing, but anything I actually intend on seriously editing? Can't live without (neo)vim. My brain now cringes at the thought of reaching for my mouse, pointing, clicking, then dragging, and moving my fingers in weird, uncomfortable positions to do things like copy and paste.
i have taken to vscode because of the nice that is all the extensions. that said it can have neovim as a backing editor so that's what i use and it's not amazing but pretty great overall
I used to spend a lot of time messing with Vim configs, memorised enough shortcuts to save me time, and set them up in my dotfile repo. I have since switched to VS Code permanently and I would not look back. It just works with so many toolchains/workflows, and as much as I dislike electron, it is in my estimation, no less productive than my Vim-zealot setup. The command palette is good enough to navigate functionality for me.
It is my personal opinion that there is no good reason to learn Vim or its variants nowadays with the current tooling available. We should be trying to innovate on something better than text editing for producing code because there has been next to _zero_ innovation (imo) in paradigms for producing code for literal decades and I know there is an opportunity for something better. I don't know what that kind of 'better' would look like but I'd be really interested to find out.
I used to dislike vim because of its steep learning curve - my brain would say "I'll always forget it and it won't be worth it". After learning vim (only the very basics), it continues to put a smile on my face now and then. It's like someone has given me 8 to 10 lego pieces and what I can do can be imagined on the spot. Stack the lego pieces and voila, yet another smile on a rather dim morning. Vim is great, but I totally understand my old self that was put off by the elite/snob culture and their ways to scare you away.
All said, if you don't know vim and don't want to learn it, you're not missing out on an occasional smile and a kick in discovering ysa2t or whatever the command. It's not as hyped up as it is treated by the elites. It's good.
I had a rudimentary understanding of vim for a few years, but what really made me prolific at it was a point where I decided to forego productivity for a month and use it full time (not vim binding in IDE, just full vim, with vim plugins and whatnot).
It coincided with a new job, and I only had to slightly wean myself off vim by conceding Java to intellij (but with vim binding). I still edit all other languages in vim directly, when there are many packages and distracting threads, vim is fast because it skips setup process and works everywhere in the same way.
Personally I think, whatever ctrl-s is doing instead of saving, is the only really hostile default in vim. To a beginner it's the "mysteriously break vim for good" shortcut. And maybe the lack of ctrl-c/-v clipboard management. I hate pasting things into default vim.
Oh, yeah right. Thanks. I forgot the details there. This even goes to your e.g. .bashrc right?
Tho, couldn't vim overwrite this somehow?
In any case, this legacy feature is a major pain in the ass for beginners. Today ctrl-s/-c/-v and maybe ctrl-z have another meaning IMO and sticking to legacy is messing with heads unnecessarily. Pantheon terminal manages to e.g. make ctrl-c context dependent copy/cancel.
probably the single most useful thing in NeoVim is
:set inccommand=nosplit
This lets you see the results of commands (like complex regex for example) while you type them. For me this has made a huge difference to the enjoyment of refactoring code. It is both possible and fun to try a ridiculous regular expression with lots of capture groups or even one that works across newlines when I can watch the results as I type.
Saddly this only works in NeoVim to my knowledge, not in regular vim, but it's pretty amazing.
The article isn't really antipatterns, more just some advice on how you might want to get started. Different people like to approach things in different ways, and tend to do things however they want anyways. I'd just suggest not to give up on Vim too early, and maybe look for an easier introduction if necessary. If you are using another editor/ide, just use vim mode in that ( most have it ).
Vim is like anything in computing. Confusing at first, eventually you have an "ah-ha!" moment, and in time it becomes second nature.
But there are also different personal preferences. I'd say vim is great if you work frequently in a terminal and prefer the keyboard to the mouse. It's not for everyone and that's ok.
One tool that helped me a lot was learning about :h usr_01.txt.
There are 45 or so of these pages. Reading through some of them was one of the most useful ways to learn vim.
What's weird is very few blogs or articles mention these even existing despite the suggestions for using vimtutor or reviewing the :h command for finding help on specific settings.
Same goes for Emacs, nobody points you to the Info system, which is absolutely amazing.
Perhaps this is because both vimtutor and the Emacs tutor do refer to their respective help systems, but given the sad state of most help systems beginners are familiar with I think they can be forgiven for not taking the recomendation seriously. Its worth really emphasizing to beginners that there is a follow up to the simple vimtutor/TUTORIAL built right into the editor.
In the age of google everything, it seems like people don't even consider that built-in help could be a thing. And people just don't seem to read. vim's startup message contains:
VIM - Vi IMproved
version whatever
by Bram Moolenaar et al.
Vim is open source and freely distributable
Become a registered Vim user!
type :help register<Enter> for information
type :q<Enter> to exit
type :help<Enter> or <F1> for on-line help
type :help version8<Enter> for version info
Things in <> are even colored so you can see them easier. Wow, it's so hard to figure out how to exit! Oh well, vim is doing fine.
how often are people opening vim with no buffers? Even if I'm creating a file, I know what name I want to give it so I'll invoke vim with that as the argument
> I found myself going very deep down that rabbit hole of plugins and tweaks on multiple occasions. Of course, every time I did it for the sake of “productivity” until I snapped out of it.
I’m guilty of this, although I typically don’t snap out of it so much as blow away my vimrc or start fresh.
> Usually after taking a step back, asking myself “do I really need this?” - it turned out I can do just fine without devicons and the latest plugins
Agreed, however the latest neovim + native lsp/lua offerings are pretty amazing. It’s a rabbit hole that I find it hard to stay out of. It’s still early days, but it seems to me that there’s a significant amount of functionality that this combo unlocks while side stepping some classic vim/vimscript pain.
A while ago though, I made an interesting realization/admission (at least for me).
Vim is great for small files (because it’s ingress is so quick and fluid and universal) and pretty good at editing/tweaking existing content.
But I have found it painful for original authoring of large original content. So if I need to rough out the first go at a python/elixir/c code base of anything that’s gonna be larger than two screens of text, I’ll pull out a “real” editor and build it up.
As I switch back into tweaking mode past the original splurge of content creation I often go back to Vi(m). It’s ability to navigate/modify existing code is unparalleled. That’s been my experience at least.
I like to rough out code in Vim, and clean it up before I run it in vscode. Vim is so fast and I can get the majority of the structure out quickly, and than I can mouse around in vscode and make sure my arguments to functions are in the right order and that sort of thing
> But I have found it painful for original authoring of large original content, .... anything larger than two screens of text.
I guess the balance is in how much you're writing compared to editing; I'd hazard a guess to say that most programmers are editing code mainly, with only short bouts of creation.
Whenever I'm creating, I always need to modify as I go; spelling errors, re-order thoughts, delete entire words, etc. and I find the vim keybindings too mnemonic to not use anywhere else.
Even when I'm writing research papers on sharelatex.org, I still try to turn on vim mode, because I find myself trying to type ":w" and "ciw" all over the place.
While I enjoy using vi*, in today's practical terms it itself seems like an anti-pattern, unfortunately: as soon as I leave my closet and reenter the big world, I always have trouble readjusting to the "normal people's" keybindings...
Something I've always wanted to do is create modal editor keybindings designed to have the easiest learning curve possible for someone coming from CUA keybindings but still off the power of what you get with vim down the road. The idea is that in insert mode ctrl-c, ctrl-v, and so on work the say you'd expect and in normal mode you would just type c or v for the same effect.
Can distros quit shoving unexpected behaviors and options down our throats? Nothing like trying to edit a YML file and have vim go all wacky on the indentation, or trying to paste text into an xterm and have vim intercept my mouse. No, I was expecting to see my terminal's right-click menu.
Yes, that's what .vimrc is for, but now that's one more config file to keep track of.
I know enough vim and emacs that if I'm stuck somewhere and have to use it, I'll be fine. I'm sticking with vscode for day to day work though. I've experimented with vscode's vim extension , and it seems like the best of both worlds.
I just don't buy the premise that I will profit from spending a lot of time optimally customizing a text editor to my supposedly very unique and special needs.
Seems more like a weird para-work hobby than an actual productivity hack.
Then don't. Just learn the basics. Learn how to use insert mode, edit some files, ignore anything not directly relevant. Eventually you'll come across a particular use case where opening a full blown IDE doesn't feel worth the effort, so you'll open vim.
You'll learn a few shortcuts, because it would be nice to delete an entire line, or just look at the end of the file. What do you know `dd`, and `G` respectively do that for you.
Eventually things will become easier in vim, and you'll just have another tool at your disposal.
It took me years to begin to appreciate vim. I don't have a .vimrc, I use all the base settings. However, now that I know how to use vim it's become invaluable.
The thing about vim is that it doesn't have to be complicated. It can be as easy or as hard as you want it to be.
> Eventually you'll come across a particular use case where opening a full blown IDE doesn't feel worth the effort, so you'll open vim.
Imho there are strictly better options than vim for this nowadays for people who are not already invested in vim. Sublime text is easier for people that prefer GUIs. For CLI, Kakoune has better discoverability, better thought/more consistent commands, and actually usable colorschemes and syntax highlighting out of the box.
>The great thing about vi(m) is that it's always there. SSH'd into some random server and need to edit some random config? vim
I hate that, I ssh in, then maybe I want to edit cron and I am hit with vim(someone changed the simple nano with it), in the past you had no choice then google how to quit vim but now it will tell you how to do it(I ssh and change config files 1 or 2 times a year). I never learned how to quit, just o use
EDITOR=nano command
to get a simple editor, I don't need a powerful editor for config files.
A lot of times it's easier to just learn the tools of the trade instead of fighting a never-ending battle. I don't need or like awk, but I learned it because it's in use and it was very helpful to do so.
vim - is not my tool of trade, I am developer so I prefer IDEs like Intellij for coding and for config files I will use kate for local and for remote nano will do the job.
It makes no sense to learn vim because I am hit with it once a year, I better learn tools like "tail" and "grep" this ones are useful for what I do.
But sure if you are a sysadmin or ssh daily and edit big complex config files the sure learn vim if you really want that.
I mean, based on the complaints outlined in your comment above it kind of sounds like vim _is_ a tool of your trade (albeit one that you don't use very often). The basics are probably worth learning just so you don't have to care when you run into vim (opening files, inserting text, save and exit). Learn it once and you're good to go.
Or you can keep resetting the default editor to nano. You do you, friend.
Sorry if I was not clear, most of the time when you edit a config file you decide what editor you use, so you would run
nano /etc/congig.cfg
my only issue was with crontab, since it was using nano but someone changed it to vim so I was surprised by it, I really had to google how to exit it. Since I edit cronjobs once a year and for config files I can use nano it would be a waste to learn vim, I would just forget all the shortcuts - not sure how other people memory works by me I forget stuff I do not use , like regexp I use them 2 times a year and each time I need to read again what symbol does what.
I am not sure who to blame for making vim the default (in EDITOR), I could swear it was nano and someone in our team had to switch it vim to fuck with the rest,
In most the distributions, the default editor is vi, I believe the only (mainstream) distribution which has nano as default is ubuntu. In fact, being a sysadmin, the reason most of us learnt vim is because it's always the default and it's installed everywhere.
This leads to being stuck with tools which are unpleasant to use and sometimes not suited for what you want to do with them - for example, editing text files as a beginner.
Would it be better if Nginx would have never been written and we'd all use Apache instead?
What about Docker never having been written and us having to ship VM images with no tool chain around them?
What about JetBrains never creating new IDEs and everyone being stuck with Eclipse or NetBeans?
What about no systemd and having to use sysvinit or OpenRC? Okay, perhaps that last one is debatable, due to some valid concerns.
If Vim is so powerful, then this power should be embraced and transformed into a software package that's easier to use, be it with nano style hints or simpler shortcuts - Vim isn't good because of its accidental complexity after all!
Of course, that might take a few generations, because no one who knows Vim wants to relearn it, whereas the newer people will oftentimes simply resist using it.
But my point is that the weaknesses of each software package should be addressed and eventually fixed, either in itself or another to replace it.
Any sufficiently capable editors will be complex. Emacs for example is just as hard to learn if not harder than vim. Nano is easier for one simple reason which is that it is not as capable.
Could vim be easier? Probably. But it’s still useful and is an archetype. Remember I’m not saying new code should be written in Awk. It’s just useful to know how to use the tools that everyone knows, regardless of whether they should be replaced or improved.
The handsaw isn’t perfect or that beginner friendly, but if you refuse to learn to use one because there are other cutting instruments, you’ll probably have a bad time compared to if you didn’t.
> It’s just useful to know how to use the tools that everyone knows, regardless of whether they should be replaced or improved.
This is a perfectly reasonable argument to make and probably reflects the reality of working in the industry pretty well.
That said, I'm still stoked to see what people come up with in the next 20 years.
Maybe gradual improvements like Neovim tried to do. Or perhaps Vim-like text interaction in VSC or JetBrains IDEs, with all of their plugins and ecosystem. Or maybe something even more grand!
As noted earlier in the thread, that embraced and transformed easier to use version of vim is called Sublime Text. (I actually thought it was a fork, but no, apparently it's just "inspired by".)
Vim's power comes from it being 1) text-based, 2) very fast to load and manipulate files, and 3) very fast to use if you are familiar with the syntax. Like many power tools, it's the last part here that's hard, but it's also very hard to fix without affecting one of the other two qualities. For example, Emacs nails points 1 & 3, but is so much slower to load that few people use it as their default $EDITOR, and has a sizable learning curve as well.
Vi (rather than vim) should probably be treated more like how most developers know how to use a unix shell, rather than a specific product. Far more than the program that implements it, vi(m) is more relevant as a UI. Granted, it is not idea and goes contrary to the expectations of users who haven't had much experience with it yet, but it is at least for the time being a de-facto standard worth knowing the basics of (and I mean extrem basics, how to enter leave insert mode, how to save how to quit. If you aren't using a real vi, then anything about the normal mode is nice to know).
fwiw i've also thought that and moved to vscode with neovim as the backing editor for normal mode and it's generally fantastic. some rough edges but not that many... it's still neovim and vim in the background
Yeah. It's pretty easy to delete a line in Sublime, and contrary to CLI fan wisdom, a single accurate trackpad gesture is simpler and faster than the barrage of commands needed to jump to a particular line.
The studies that "prove" CLIs are faster than GUIs are decades old now, and my experience says they're obsolete.
I develop with emacs using my keyboard exclusively and I'm 100% convinced there is no appreciable benefit for doing so, it's pure personal preference. I remember seeing John Carmack express that didn't feel it was worth it to become a text editor power user, and he was getting numerous twitter replies insisting he was missing out on enormous productivity benefits. Imagine saying that to one of the most productive programmers of all time. It cracks me up every time I think about it.
Vim movements allow you to compose rich intentions with a matter of a few keystrokes. I find it very hard to believe that can be beat with a mouse unless someone is using gestures.
More than anything, it's about not switching devices. Typing feels like playing the keyboard. Switching to the mouse feels like having to pick up a trombone between keys. (I know that's a bit dramatic of an analogy, but...)
Bringing up the old mouse makes this conversation sound so dated - as I said, I use a trackpad. Specifically, like millions of others, I work on a MacBook Pro with an incredibly precise trackpad right under the keyboard. I move my hand to and from that trackpad in about 0.1s, and I can click on anything I want in less than half a second. "Rich intentions in a few keystrokes" doesn't sound competitive with that IMO.
It's all about uninterrupted experience, I don't want to move my hand anywhere off the home row and then move back again, it feels clunky.
Regarding competitiveness, with a bit of get used to, you can muscle memory things like: "remove content inside this bracket (), or "", or block {} and place me into insert mode so I can start typing new content" in 3 keystrokes. I don't see how searching manually for start and end then select with mouse/trackpad can ever be competitive to that.
I'd happily race using vim against anyone using any pointer device. Your very fast 0.1s accumulates over the day, the week, the year. Versus never moving your hand away from the keyboard.
How do you handle having to change a function's parameters, for instance?
In vim, you just have your cursor inside the (...) and do `ci)`, which is (c)hange (i)nside `(, which instantly deletes all the test inside the (...) and you can type that stuff out easily
For a trackpad, don't you have to manually select all that text, hit delete, then start typing again? Or is there a better way I'm not thinking of
So. Many. Shortcuts. And, if you use it as an extension to your IDE, say for VSCode, you can still use your pointer.
Delete to line's end: d$
Delete to next blank line: d]
Replace current character: r
Surround the next 3 words with quotes: ys3w" (non standard, but out-of-the-box on VSCode)
I think there is merit to learning vim, and merit to using a GUI/IDE. Especially if you can combine both. Submlime, vscode etc all have reasonable vim bindings.
I was an avid user of vim for many many years, and I would not describe myself as a vim expert, rather I know a lot of the core commands. I have since switched do vscode (for many reasons) and still use the vim bindings.
I also don't believe it is just an issue about speed using the mouse. I believe it's also a movement issue.
This is the benefit I get, if it is vim/vscode/jetbrains etc as long as it has vim bindings I know `dd` is going to delete a line etc, the editing experience is fairly static. Block editing and yanking, F, T, ctrl-D, ctrl-U, cw, de, cs"`, vwS(, ci", and many others are all great vim methodologies, just like cmd-p (mac) for sublime and vscode.
Multicursor in vscode, feels broken do to me compared to block editing but even if I need to do mutlicursor across distributed lines (something missing from vim) I can use `gd`.
I would say vim is more of a methodology than just an editor.
If you care about quick edits in a user friendly environment, you might as well use software that's simple to use and doesn't have a steep learning curve, instead providing user friendly shortcuts.
In my eyes, Vim is better suited for more advanced text processing and more macro heavy edits, where you need to do lots of repeated actions. Of course, if you are used to Vim, might as well use it for everything, however if you don't that suggestion is possibly a suboptimal one.
Though there's definitely a space that's also occupied by regular text editors (like Notepad++ or the *nix equivalents) if you're in a graphical environment where you even have the possibility of opening an IDE.
> Eventually you'll come across a particular use case where opening a full blown IDE doesn't feel worth the effort, so you'll open vim.
I'm not sure that's still relevant, given the popularity of VSCode
> You'll learn a few shortcuts, because it would be nice to delete an entire line, or just look at the end of the file. What do you know `dd`, and `G` respectively do that for you.
That might be just me, but 99% of my navigation is a ctrl+f (a search) or a ctrl+click (go to definition). Most of my "complex" editing needs are served well by the multi cursor and ctrl+left/right arrow (go over a "whole" word). I know that vim is a generalisation of that, and instead of having a specific thing like this you have a whole language to compose things, but I just don't see the point.
I wonder if it's one of those thing that appear universal, but is in fact very personal, and "vim people" are different from "emacs people" and from "VSCode people" and from other people in a fundamental way that can't really change, and that is visible mostly through the editor choice.
It's not even good! This has to be the strangest cargo-cult following of all options you could have. If you're going to use a proprietary closed editor anyway, use something like a jetbrains IDE. At least then you will have a lot of very complete and well-integrated features.
> It's not even good! This has to be the strangest cargo-cult following of all options you could have.
I don't think that's true. It's lighter and faster than big IDEs while being way more accessible than them and vim/emacs. It handles most of what you throw at it, has lots of very good extensions, and you can easily use your shell. If you don't understand what's good about it, that's a failure on your part.
> If you're going to use a proprietary closed editor anyway
It's open source though.
> use something like a jetbrains IDE
My experience with jetbrains has been mostly terrible. That doesn't mean that their IDE isn't good, but it means that they are worse than VSCode for me.
> At least then you will have a lot of very complete and well-integrated features.
This version is crippled. The plugin system works because of a workaround to a proprietary server, which will inevitably be broken on purpose when it gains any traction.
> This version is crippled. The plugin system works because of a workaround to a proprietary server, which will inevitably be broken on purpose when it gains any traction.
People say things like this, as if other text editors don't have the same functions. The alternative is not "notepad.exe", it's Textpad, VS Code, or IntelliJ IDEA.
Delete an entire line: CTRL-Shift-K in VS Code.
Or just look at the end of the file: Ctrl-End in most editors.
I can only speak to my experience, and I might be mistaken: but the reason I tend to reach for vim bindings is not because I already know them- it's because, mostly, it's consistent where as IDE key binds change depending on the platform and IDE.
IntelliJ has programmable keys and they prompt you on first run which ones you'd like to use "Original?", "MacOS", "Linux".
VSCode has it's own key binds for various movements (like indenting a block), I know sublime does too.
It's all just too much hassle, and obviously that doesn't translate to being ssh'd into a server and needing to move some text around, which is harder than it ought to be in Nano. (but you only feel that after you've learned vim.. so.. that's weird, there has to be a universal law about that somewhere)
But consistency only exists within a "culture", such as Linux or Windows.
From the perspective of someone from Windows, VIM is hilariously inconsistent, to the point of absurdity.
Most editors on Windows share a relatively consistent set of navigation commands. Ctrl-Left-Arrow for previous word, Ctrl-End for end of file, etc...
VIM meanwhile is so far away from this it's basically from another planet.
So then from your perspective VIM is consistent and consistently available. From a Windows user's perspective it is the Windows standard editors that are consistent and consistently available.
That's why I've gone on rants previously about the bizarre hybrids like VS Code, where it does some things like VIM, but pretends to be a light version of Visual Studio. It's a garbled mess, but apparently I'm not allowed to criticise it because it is free and JavaScript people had nothing as good available to them before, so it must be the best thing since sliced bread...
Try "Delete until the 3rd closed parenthesis", or "Delete everything within the {} block currently under the cursor".
In Vim it's pretty natural, because commands are compositional. It's like you can "talk" with the editor and tell them exactly what you want, rather than just moving around and inserting/removing/selecting characters.
Granted, it's not easy to learn and perhaps not for everyone. I think it takes a certain kind of... disposition, maybe?, to appreciate it.
Today I learned there was a better way than "dt)..", but that is still one of the things I like most about vim: verb+adverb+subject goes a really long way instead of trying to learn millions of keyboard shortcuts. Each new verb really expands your options rather than doing a single thing like a keyboard shortcut.
I don't think I've ever come across a use case where opening an IDE didn't seem worth it. I've never come across a use case where I though vim was the better option.
There are many times I had to use vim because I didn't have a choice. And usually it was with the thought, that I have to one again use a hacked up line editor.
The set of unique and special needs follows a power law: you are going to get most of the benefits from a small set of very common commands. The long tail will be rarely used.
Under a reasonable assumption that 'brain space' is finite, not filling it up with editor commands that may be used at most once a month will leave room for something more valuable instead. This applies for many other aspects in the life of an engineer: indiscriminately memorizing the options of ps/ls, specific APIs, etc.
I spend all days writing code in my editor, and will probably do so for many decades to come. Even small improvements will add up to to large differences over time.
My speed of writing code (or anything else really apart from commenting on random websites) is limited mainly to my thought process about the logic I'm about to write. If you can code so fast that fractions of a second make a difference then more power to you but most people probably can't.
And I spend even more time reading and refactoring code than writing it. Vim has many improvements for both of these, and all these seconds here and there really adds up in the end.
Wait until you get RSI. I’ve tried to cut down on the number of keystrokes I have to do something (Emacs user here, recently switched to evil-mode) and I’m more comfortable and productive.
Do you customize your command line at all? What about your desktop? Keyboard? Chair? Office? Editor is just another part of the stack.
Customizing can definitely be a time sink, and I tend to agree.
It's not portable!
I'd rather know/use the defaults, there's benefit to be had there. Most importantly for me, it will be on every server I ever have to log into/maintain.
GUI editors won't, and the hassle getting the output to where I need it doesn't fit well with workflows like mine.
Also... the config management stuff I write (YAML/Python+Jinja) is well enough supported as-is. Don't need much more than indentation preservation...
There's always a pane available to the side for ansible-doc/manual pages as a reference.
The only unusual thing I carry around with me is this:
alias vimtabs="vim -c ':tab all'"
It just makes it easier to open many files in the same editor with simple shell globbing.
Check out micro[1], there's no need to learn key shortcuts because it uses the same ones that every IDE or text editor ever uses. It also has full mouse support.
> I just don't buy the premise that I will profit from spending a lot of time optimally customizing a text editor to my supposedly very unique and special needs.
> Seems more like a weird para-work hobby than an actual productivity hack.
Because you will use the skills for forty years throughout your career?
I used vim as my primary editor for about 2 years. It was definitely the fastest way to edit text. However, editing text is pretty minor compared to time spent thinking. For me personally, I just find moded editing slightly grating. It would also be faster if I moved around at a break-neck sprint all of the time, but slightly tiresome and unpleasant. I had the same experience with vim. It was fast, tiresome, and unpleasant. Humans don't deal well with exceptions and moded interfaces. The background hum of hitting escape and confirming my mode or occasionally hitting keys in the wrong mode was just grating.
After 2 years you still felt that way? I've been using it for ~5 years and felt that after a year or so having to think about vim melted away and it just feels like the natural way to edit text, I barely think about the modes I'm in anymore
It's that line in the Matrix where he goes "Eventually you don't see the numbers. You just see blonde, redhead, brunette"
same here. vim is on every machine that I need, and if I become accustomed to non-standard bindings now I am burdened with context switching between personal-vim and standard-vim. I'd rather adapt to stock standard
I switched from vscode to vim as I found it to be largely much faster in getting around when I started my new job, some people find the opposite. A ok.
Why do people try to force us into these largely closed solutions? ( Mainly it's vscode, which has a real EEE threat)