Vim Anti-Patterns That Cause Beginners To:Quit
paweldu.dev
paweldu.dev
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)
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 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.
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.
Vimr looks excellent on macOS though, I'll definitely give it a go.
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
Same with me. I try and get on the vim hype train. seems like a great idea, but i can never 'get' vim.
Either way, what's distracting context switching for one, is essential functionality that enables effortless work for another.
(Edit: I mostly use VSCode with the Neovim extension myself)
My understanding was that the UX studies around modal editing showed it was hard for new users, which isn't quite the same thing as "bad".
Personally I think what really works about vim for me is the composition of action and motion in a sort of language.
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.
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.
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.
Your problem with Vim is that you don't grok vi https://stackoverflow.com/a/1220118/867757
You cannot create a "language for manipulating text" in a modeless editor, at least not a very rich one.
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.
Nowadays, I use both vscode and neovim but mostly neovim as it’s faster for me.
The problems I see are -
- not everyone is comfortable with customizing their editor.
- the meaning of bare-minimum features is different for everyone.
- some of us try hard to learn vim and then give up, declaring it unfit.
- some of us go too far in customizing it and end up thinking that we are overdoing it.
So, some of this hate may be genuine, but generally, people don’t hate vim.
They just hate the way they know/use it. At least I did.
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.
For code-completions coc.nvim offers similar config and plugins as vscode. There is official lsp support for neovim now but coc.nvim works fine.
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!
According to that, Microsoft's budget was 20 billion. I bet quite a bit of that goes towards convincing developers to lock into their ecosystem
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.
Like I said in the other thread about vscode:
If you assume whatever's been done here's been done wrong it saves the company time and money, we know it's fucked up that's why we called you.
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.
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.
RPN calculators on the other hand...
That's how I got over the learning cliff though..
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.
I recommend https://vimvalley.com/ highly.
Devoting resources to getting into modal editing was a helpful investment for doing headless work in the cloud over SSH.
You can turn it off using `stty -ixon`, and this also wouldn't be a problem in a graphical vim, but vim would need to have a keybinding for it.
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.
: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.
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.
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.
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.
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
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.
"Your problem with Vim is that you don't grok vi.":
It is the top answer to this question:
https://stackoverflow.com/questions/1218390/what-is-your-mos...
Also check out the "A sobering thought paragraph" at the end.
Related to that, a plug by yours truly, for my own vi quickstart tutorial (including why it was written), is linked from this tweet:
"Why I teach vim" (the "I" there is someone else):
https://mobile.twitter.com/vasudevram/status/132791223088143...
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 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.
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
Yes, that's what .vimrc is for, but now that's one more config file to keep track of.
Seems more like a weird para-work hobby than an actual productivity hack.
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.
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.
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 studies that "prove" CLIs are faster than GUIs are decades old now, and my experience says they're obsolete.
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...)
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
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)
On and on
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 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.
And Sublime is vim with a user-friendly-ish GUI wrapped around it.
Ended up settling on MacVim.app which has nice window support.
I’ve had good experiences with the visual studio vim plug-in that’s written in F#
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.
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.
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.
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!
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.
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.
Or you can keep resetting the default editor to nano. You do you, friend.
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,
Delete an entire line: CTRL-Shift-K in VS Code.
Or just look at the end of the file: Ctrl-End in most editors.
Etc...
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...
Like tab or is something more elaborate?
In vim and vim emulators you select multiple lines with visual mode and press >
Or you do “10>>” and it will indent the next 10 lines.
This is how you do it in vscode:
https://code.visualstudio.com/docs/editor/codebasics#_multip...
This is how you do it in IntelliJ:
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.
sed 's/vim/nano/g'
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.
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.
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.
I already have that.
While it is true that it has advanced somewhat since it's electron days, this is still not the case. It is at best acceptable.
> open source
Not in any way that matters. Try packaging a not crippled version of the application and you will find out in short order.
It is faster than Jetbrains IDEs or Eclipse.
> Not in any way that matters. Try packaging a not crippled version of the application and you will find out in short order.
This was not my experience at all, but it's been a little while since I tested it so this could be the case.
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.
I don't think that's exactly true. The marketplace server is proprietary, but you can still install extension by hand https://github.com/VSCodium/vscodium/blob/master/DOCS.md#ext.... It's not ideal, but it's far from crippled.
Vim also has normal mode where every key has an effect on the editing. You can jump forward, backward, delete a word, a line, yank(copy), paste.
readline and MacOS Cocoa also have interesting ctrl/alt+key combinations.
It's useful.
You can use those vim skills in most IDEs. So, your editing will be faster in those IDEs.
I believe vscode is doing a better job at extensions UX than vim. These days, webkit is allowing a smoother experience than TUIs.
It's that line in the Matrix where he goes "Eventually you don't see the numbers. You just see blonde, redhead, brunette"
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'"
> 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?
Do you customize your command line at all? What about your desktop? Keyboard? Chair? Office? Editor is just another part of the stack.