Instead of having encyclopedic knowledge of every feature, I think editor fluency is being really good at the few features you need such that the editor is no longer the bottleneck.
The few features you really need to know for VIM are mostly in `:help motion.txt`. Knowledge of other features is obviously helpful in actually editing text, but being able to navigate well should remove most of the bottlenecks, especially considering how most VIM commands take motion into account.
> The feeling of true Vim fluency—one where every keystroke is exact, I never make mistakes, and I’m exploiting every obscure feature—is a fantasy, at least for me.
Perfection is not particularly attainable, or necessarily the point. Nor would it be that fun, I think? It's nice to have some aspect to improve upon. See this Casals quote:
> A reporter asked Casals, "You are 95 and the greatest cellist that ever lived. Why do you still practice six hours a day?" He answered, "Because I think I'm making progress".
> Although, also, perfection probably doesn’t come from adding options either.
No. However, the first step to _refinement_ is knowing about the thing you want to refine, so in that sense actively engaging and learning about the option lets you know whether to pursue it further.
I rerun vimtutor from time to time, because I still don't remember every trick from it. I've recently tried to read the whole embedded "introductory documentation" on a train, learned a lot, but probably need to do it again. Setting every option in the .vimrc seems a nice exercise, will need to do it some time! I like to nuke my config from time to time anyway. (My experience with Vim is about 14 years I think.)
Kudos for reading all those docs and sharing some nuggets.
Does anyone else feel vim clumsy like the author? I'm trying to understand how one could accidentally lowercase a whole buffer, or trigger scary messages or open unrecognized menus. Not condescending, just curious. I find the q: thing relatable, but not the rest.
If you're at the top of the buffer, guG will lowercase the whole thing.
So if you open a file, go to type G to jump to a line, but accidentally hit g, then try to undo it with u out of habit, before hitting G again, you do the same thing.
While I had times discovering myself to accidentally putting 'i' accidentally into MS Word docs and having vim key binding ls in VS Code (and formally eclipse) as well for that reason, I still feel clumsy. I think this is because I mostly rely on muscle memory rather than understanding deeply what I am doing to also allow me to go beyond what I normally do ) which already makes me faster than in any other editor). I found VimSpeak [1] interesting because I somehow understood how to really compose vim commands in a way
Uh to be perfectly honest for the past … 30 years I’ve ran with a buddies vimrc and really never took the time to understand it; it was perfectly good lol and to this day I could not recreate it if I lost it.
> lowercase a whole buffer,
Happens a lot to me actually!
That and accidentally incrementing a numeric value haha..
Most of it is commented very well. Also I like it because it has a little bit of personal character.
> " Incrementally match the search. I orignally hated this
> " but someone forced me to live with it for a while and told
> " me that I would grow to love it after getting used to it...
> " turns out he was right :)
> set incsearch
This feels like the "wrong" direction today with the advent of AI? Just seems like in the realm of "bending yourself to the tool vs bending the tool to yourself," it's the LATTER that's about to get a whole lot easier, if it isn't already.
So, sure, there are probably things you can learn, but e.g. I'm much more about "I think it should be THIS way so how do I make it do that."
The problem is both (1) knowing what you want, and (2) specifying what you want.
(1) is hard enough and a necessary prerequisite to (2) which, even so, is even harder than (1).
Good, documented software is the accumulated knowledge of people who (1) knew what they wanted, (2) implemented it, and (3) communicated how it works. AI can ease the building of such software but does not make the process trivial.
You are getting downvoted quite heavily but I do wonder what percentage of people are growing more and more accustomed to the latter.
I say this someone who was dedicated to (neo)vim for a decade. With AI I spend a lot less time writing/editing pure code these days, and all the VSCode based IDEs have become so essential to my workflow/productivity that using vim only would be masochistic. I still enable the vim binds in my editor and while they’re never a perfect 100% replacement I get so much value out of other tools I can’t see myself going back.
Learning Vim has been one of the highest-longevity skill I picked up in University. With every new technology - autocomplete, IDEs, various GUI design interfaces - there's always a chorus of folks who say: "Well now you don't need to Vim, this new tool makes that obsolete." And every time I end up having to manipulate a mountain of text regardless - whether that's in logs, source code, configuration, or documentation. With the amount of text that AI outputs I don't see the need to manipulate text going away and Vim is one of the fastest and most flexible ways to do that.
>> single keystroke could move the cursor halfway across the file to exactly the right spot.
> sorry what is this? exaggeration?
It is indeed. I need two keystrokes to move from an arbitrary positions in an arbitrarily long file to the exact spot I need to be.
I use it all the time, in fact. Multiple times an hour. It's muscle memory now for me, while reading/navigating code, to automatically do `ma` or `mb` etc.
At some later point I realise "let me read the function definition again" and then I do `'a` or `'b`, etc.
I can see how that could work depends on the setup and the context. For example: People might use `. to jump to the last edit, or to a mark they set manually. Or simply `ciq` to edit inside the next quote without any manual cursor movements. I see people use plugin like harpoon to jump to their favorite location quickly. If you don't know about such setup, seeing people type <leader>1 to jump not just within a file, but across files, seems magical.
Nope! "G" moves the cursor to the end of the file. Very useful. Inferior editors have ctrl-end or alt-end, but with Vim, 90% of your lazy fingers stay on the home row!
"The feeling of true Vim fluency—one where every keystroke is exact, I never make mistakes, and I’m exploiting every obscure feature—is a fantasy, at least for me." - that's a wrong mindset. bash that jk hundred times and adapt when it becomes a nuisance
Instead of having encyclopedic knowledge of every feature, I think editor fluency is being really good at the few features you need such that the editor is no longer the bottleneck.
The few features you really need to know for VIM are mostly in `:help motion.txt`. Knowledge of other features is obviously helpful in actually editing text, but being able to navigate well should remove most of the bottlenecks, especially considering how most VIM commands take motion into account.
> The feeling of true Vim fluency—one where every keystroke is exact, I never make mistakes, and I’m exploiting every obscure feature—is a fantasy, at least for me.
Perfection is not particularly attainable, or necessarily the point. Nor would it be that fun, I think? It's nice to have some aspect to improve upon. See this Casals quote:
> A reporter asked Casals, "You are 95 and the greatest cellist that ever lived. Why do you still practice six hours a day?" He answered, "Because I think I'm making progress".
Although, also, perfection probably doesn’t come from adding options either.
I can use hjkl y and d perfectly! :set rnu and I can even throw some numbers in there!
> Although, also, perfection probably doesn’t come from adding options either.
No. However, the first step to _refinement_ is knowing about the thing you want to refine, so in that sense actively engaging and learning about the option lets you know whether to pursue it further.
I rerun vimtutor from time to time, because I still don't remember every trick from it. I've recently tried to read the whole embedded "introductory documentation" on a train, learned a lot, but probably need to do it again. Setting every option in the .vimrc seems a nice exercise, will need to do it some time! I like to nuke my config from time to time anyway. (My experience with Vim is about 14 years I think.)
Kudos for reading all those docs and sharing some nuggets.
Does anyone else feel vim clumsy like the author? I'm trying to understand how one could accidentally lowercase a whole buffer, or trigger scary messages or open unrecognized menus. Not condescending, just curious. I find the q: thing relatable, but not the rest.
If you're at the top of the buffer, guG will lowercase the whole thing.
So if you open a file, go to type G to jump to a line, but accidentally hit g, then try to undo it with u out of habit, before hitting G again, you do the same thing.
While I had times discovering myself to accidentally putting 'i' accidentally into MS Word docs and having vim key binding ls in VS Code (and formally eclipse) as well for that reason, I still feel clumsy. I think this is because I mostly rely on muscle memory rather than understanding deeply what I am doing to also allow me to go beyond what I normally do ) which already makes me faster than in any other editor). I found VimSpeak [1] interesting because I somehow understood how to really compose vim commands in a way
[1] http://www.youtube.com/watch?v=TEBMlXRjhZY
I miss keys sometimes, but if it makes bad edits (it doesn't always!), I just hit `u` to undo.
Uh to be perfectly honest for the past … 30 years I’ve ran with a buddies vimrc and really never took the time to understand it; it was perfectly good lol and to this day I could not recreate it if I lost it.
> lowercase a whole buffer,
Happens a lot to me actually!
That and accidentally incrementing a numeric value haha..
Mind sharing your .vimrc file with the world? Would love to try it.
https://pastebin.com/YCQmKJRJ
Most of it is commented very well. Also I like it because it has a little bit of personal character.
maybe throw it in your friendly neighborhood LLM
This feels like the "wrong" direction today with the advent of AI? Just seems like in the realm of "bending yourself to the tool vs bending the tool to yourself," it's the LATTER that's about to get a whole lot easier, if it isn't already.
So, sure, there are probably things you can learn, but e.g. I'm much more about "I think it should be THIS way so how do I make it do that."
The problem is both (1) knowing what you want, and (2) specifying what you want.
(1) is hard enough and a necessary prerequisite to (2) which, even so, is even harder than (1).
Good, documented software is the accumulated knowledge of people who (1) knew what they wanted, (2) implemented it, and (3) communicated how it works. AI can ease the building of such software but does not make the process trivial.
You are getting downvoted quite heavily but I do wonder what percentage of people are growing more and more accustomed to the latter.
I say this someone who was dedicated to (neo)vim for a decade. With AI I spend a lot less time writing/editing pure code these days, and all the VSCode based IDEs have become so essential to my workflow/productivity that using vim only would be masochistic. I still enable the vim binds in my editor and while they’re never a perfect 100% replacement I get so much value out of other tools I can’t see myself going back.
Learning Vim has been one of the highest-longevity skill I picked up in University. With every new technology - autocomplete, IDEs, various GUI design interfaces - there's always a chorus of folks who say: "Well now you don't need to Vim, this new tool makes that obsolete." And every time I end up having to manipulate a mountain of text regardless - whether that's in logs, source code, configuration, or documentation. With the amount of text that AI outputs I don't see the need to manipulate text going away and Vim is one of the fastest and most flexible ways to do that.
> single keystroke could move the cursor halfway across the file to exactly the right spot.
sorry what is this? exaggeration?
>> single keystroke could move the cursor halfway across the file to exactly the right spot.
> sorry what is this? exaggeration?
It is indeed. I need two keystrokes to move from an arbitrary positions in an arbitrarily long file to the exact spot I need to be.
I use it all the time, in fact. Multiple times an hour. It's muscle memory now for me, while reading/navigating code, to automatically do `ma` or `mb` etc.
At some later point I realise "let me read the function definition again" and then I do `'a` or `'b`, etc.
I can see how that could work depends on the setup and the context. For example: People might use `. to jump to the last edit, or to a mark they set manually. Or simply `ciq` to edit inside the next quote without any manual cursor movements. I see people use plugin like harpoon to jump to their favorite location quickly. If you don't know about such setup, seeing people type <leader>1 to jump not just within a file, but across files, seems magical.
Nope! "G" moves the cursor to the end of the file. Very useful. Inferior editors have ctrl-end or alt-end, but with Vim, 90% of your lazy fingers stay on the home row!
Then there’s Emacs, where Meta - > takes three fingers!
Yes, it's exaggeration. Modal editing cannot read your mind.
… (For Your Love)” -Frankie Valli
I never understood this idea that you should min/max your typing. The editor should serve you, not the other way around.
Then again, I'm an emacs user.
"The feeling of true Vim fluency—one where every keystroke is exact, I never make mistakes, and I’m exploiting every obscure feature—is a fantasy, at least for me." - that's a wrong mindset. bash that jk hundred times and adapt when it becomes a nuisance
> that's a wrong mindset
The very idea there is a 'right mindset' is weird to me.
OP didn't necessarily say that, they just said _that_ particular mindset is not it.