Stuff like typing "10j" made sense when text editing was high latency. Nowadays you can just hold j and stop precisely where you wanted to, even if you're ssh'ing into a server on the other side of the country. There's nothing wrong with it (and in fact I prefer it because of the 0 finger movement required).
The only times I use "precise" movement commands like that is when I'm in the odd situation of having to ssh into something from my phone.
I found that moving between empty lines is the nicest way to navigate most code across all programming languages, markup languages and just regular text. I don’t have to think, I don’t have to count, I just move and select text big chunks at a time… (not in vim, but I first saw someone have key bindings for this in vim)
This is the one thing I brought from my time of trying out vim.
I have now set all my editors to move by paragraph with ctrl+up/dn. It fits so well together with ctrl+left/right that I think it should be standard behaviour. I also set up ctrl+shift+up/dn to select, of course.
>I have now set all my editors to move by paragraph with ctrl+up/dn.
It's even simpler with Vim - just one keystroke - { or }.
On a US keyboard layout this is the same number of keys because { and } are Shift+[ and Shift+]
That's because you aren't combining it with more advanced commands, or macros.
"10j" may sound useless. But "y10j50jp" is much more effective. Put that in a macro that does other stuff too, and suddenly you perform complex editions to a file containing thousands of lines of text in a few seconds.
[deleted]
It's slower to "stop precisely"on key hold/release, so 10j still makes more sense, only for a few lines tapping J a few times makes more sense, but not 10-20
I've tried so many times to make it work, I've really tried. But it just ends up being faster to spam j a couple of times instead of having to think about how many times I want to move, then type it, then be wrong, then try again...
For larger distances you wouldn't even see the text in the screen, so you don't even know how much to jump. In this situation I just spam ctrl+d, then tweak with j.
Relative line numbers = no thinking
Look where you want to go, there's a number next to it. Type that number and then type j.
It can be about as fast if you set key repeat delay to minimum and repeat speed to maximum. I used it for a while and got quite precise with it. Works well until someone else needs to use your computer for a moment...
Hm, I doubt the precision can match and avoid under/overshootings, especially at high enough repeat speed to match, and it's a global change that can affect even regular typing, so you're suggesting specialized training (to minimizeerrors) for a less effective workflow
The main issue with precise jumps (for me) is that they require you to
- already exactly know where you want to go
- figure out the relative distance either by looking to the side at relative line numbers or calculating
- move your hands to the numbers row to input numbers and back (I don't have small hands, but that still translates into a small amount of arm movement for me).
Whereas just using repeat input on jklhwe... only requires you to have a rough idea initially and leaves you plenty of time to figure out where exactly you want to stop while you're already getting there.
Besides: I don't like to think about random numbers while I'm coding. Doesn't exactly make the cursor feel like an extension of my body (imagine you had to tell your hand "move 10 centimeters left")
Another quite intuitive way I navigate is using "/something" and cycling through hits - usually you know some text that appears near the area you want to go. That was pretty much instant muscle memory.
> - already exactly know where you want to go
Same as with moving down by 1x10? How are you even choosing cursor direction if you don't know where to go to?
> - figure out the relative distance either by looking to the side
Ok, how is that an issue? You also have to figure out the distance by looking down when moving down with the arrows, so eyes still move?
> move your hands to the numbers row to input numbers and back
No, you could maintain your hands on the home row and use a numpad layer containing it
> imagine you had to tell your hand "move 10 centimeters left"
Imagine you had to tell your hand "move 1 centimeter left 10 times"? The mouse is that extension where you don't "move by 1 pixel X times" and move in an analog way
Oh. Now I get why we're talking past each other. There's a thing most computers are configured to do out of the box, but yours might be different for some reason.
I'm going to assume you're using Windows. In that case go to Settings > Accessibility > Keyboard and configure "Character Repeat". What this will do is repeat a key you're holding as if you're pressing it multiple times! Configure it until it feels natural.
This is what people were referring to when we said we're holding a key. We're not pressing it 10 times, just holding it down and having the computer automatically repeat it until we're happy with the result (such as having moved where we wanted to). It's a bit like moving a mouse cursor, where you're also not calculating the offset you want to move your mouse in advance.
> It's slower to "stop precisely"on key hold/release
For longer distances, unless your repeat speed is very slow, you're often either holding a key repeat and stop before a few lines and then tap or overshooting and tap to go back. So ok, it's not 1x10, but 7+1x3 or 12-1x2
(but yes, the initial leg of the journey is more mouse-like "natural", but still not that because you can't vary speed on most keyboards unlike with they mouse/hand)
For smaller distances you could just tap a few times.
No one is doing 1x10 key presses. That's now how humans process information. You repeatedly press a key one time until what you see on screen is what you want. The further away you are the faster you do it.
> press a key one time
That's "1"
> You repeatedly press
That's x10
Generally I'm using 'e' to go forward and 'b' to go backward
Whereas I have always used `w` and did not even know that `e` existed (not that I can see an obvious advantage to it). Ahh, vim.
More often than not you want 'de' or 'ye' rather than 'dw' or 'yw'
> (not that I can see an obvious advantage to it).
Precision. I use e/E more often than w/W when editing a line or creating macros, but w/W for moving around. But more often i search with f and jump to next match with ; if I didn't hit the target right away. / then n if I'm moving to another line.
I think it took me about four months of daily use to know most of the editor basics without having to pause to look up things. Another eight for it all to feel natural. And, maybe about six years later, it remains my favorite text entry and code editing environment.
I've been using the LazyVim <https://www.lazyvim.org/> neovim setup and a handful of extras, but not too many. I still have to look up some esoteric stuff, but for the most part, it's completely natural.
And for the first few years, I was a hardline keyboard-only absolutist, but lately I've been using the mouse where it makes sense, and sometimes it does.
(MacOS, iTerm2, neovim, lazyvim, love this combo)
Have you tried WezTerm yet?
It also uses lua for writing its configs which makes it highly customizable.
I've switched to it from iTerm2 a couple of years ago and gradually added more and more to my config and it's super powerful.
I have various issues with it (e.g. wrapping on resize is just broken) and miss iTerm a little, but the built-in tabs aren’t too bad (unlike Kitty’s hardline stance) and it’s available cross-platform, so I can have the same config on many machines.
Ghostty is also a great option on macOS (on Linux I use Alacritty).
> unlike Kitty’s hardline stance
Are you maybe switching that up with alacritty? Kitty has built-in tabs and they work quite well.
Yes! Sorry Kitty for mixing you up!
> but lately I've been using the mouse where it makes sense
Get off my lawn, hippie
hehe
> 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".
Hokusai wrote at the age of 75 that he would only begin to understand the structure of living beings at 100, and hoped to “reach perfection at 110.” He died at 89.
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.
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.
Does anyone have a motion jump plugin they use with neovim they can recommend? I used to use a plugin where you could just to a given character in a given buffer, but I can’t remember the name or if it even works with neovim.
leap.nvim
you press a keybind and then press one or two characters , all instances of that character pair in the viewport will get get a hint (a characteror two in highlight) , hit those two hint keys and the cursor jumps to that location
its incredibly fast to navigate around your viewport with this.
+1 Leap takes a second to get used to but I love it so much. Even if you don't get to the precise character you want, you can get so close enough that normal motion commands get you the rest of the way.
I do change the bindings, tho. I have 's' leap forwards and 'S' leap backwards.
Like the nth character in the current buffer? I believe vim has that built-in: `<n>go`. I think `<n><space>` will do it relative to your current position.
Actually, `<n><space>` ignores things like new lines.
Check out folke/flash.nvim for a motion jump plugin. It’s brilliant.
I applaud this project, “setting all the options”. I think it’s a really good idea to become close friends with the software you use all the time, and getting acquainted through the lens of configuration is one way. Messing around with stuff is good.
I feel it’s worth mentioning that there is a sense in which I think it might be a bad idea. It could be that you’d now be fixating some value that may be optimal right now, rather than benefiting from future improvements to the default settings. But it all depends, of course, on how close friends you plan to be.
"Become close friends with the software you use all the time." That is a beautifully evocative phrase for a lovely idea, thank you for sharing.
If I may share an idea for which I don't have nearly as nice and succinct a summation, but I've come to view my personal computing environments through the lens of being a garden. I spend so much time within them, working, learning, playing and writing. I can see the different seasons of my life reflected through naming conventions, directory structures, scripts I've written and bookmarks I've long ignored. There are new things I want to try and explore in the spring when I hopefully have a bit more free time. I have planted seeds while children slept in my arms or in the next room, and I have enabled their dreams with the fruits of my labour. I would even say I have occasionally communed with the close and holy darkness on long, late nights.
In time everything I have created will return to dust, and probably no one will ever know this garden as I have. But it has still been a place of growth and blessing.
I've been using vim for over 20 years as my primary editor. I'm faster and more comfortable in it than I am in any other editor, but I still feel like a vim noob
I still have to look up how to do things I rarely do (like insert the contents of another file at the cursor position). And I don't really use many (if any) of vim's intermediate features, let alone advanced ones.
I've tried various ways to get more fluent, but nothing really stuck or kept my interest. This has always annoyed me a bit...
Same here. I use vim over other editors / key schemas mostly because it's easier for me than pressing a whole bunch of keys simultaneously. I use it where I can in other apps too. That's also why I only use a relatively small subset (whatever they all implement) and never spent too much time into going totally overboard with learning all its capabilities.
Also, typing just isn't really that much of task in the first place. I spend way more time trying to find out what to do and how, and then finally typing it isn't as relevant that I would need to optimize it over a certain point.
I've been using vim for 20 years as well, for everything other than Java code. I type my .vimrc by hand on each new machine to set a half dozen options.
Of the intermediate features, I use tabs and, more recently, split windows.
My favorite 'advanced' feature is visual block selection and replacement over multiple lines - super convenient.
I think vim's greatest problem is discoverability. It's a big enough problem that after six or so months working full time in neovim I went back to a GUI editor. I just about barely remember the most common commands, but I do not remember (at all) anything I only need occasionally. I also know myself well enough to know I will never remember this sort of thing well. I have a terrible memory for procedural / administrative / ritualistic knowledge.
I'm on Sublime right now. I like it a lot less than vim, but it's far less cryptic. If I need to tile four documents and move text around, I can do so trivially by dragging, without needing a PhD in vim esoterica that I would immediately forget the next day.
My time with Vi/Vim is similar, measured in decades.
There's a lot in Vim, and there's no requirement to be a tech maximalist. Settling at core features is not being a noob.
I was lucky enough that my first employer ran the very first 4.2BSD in Denmark outside academia (on a DEC-VAX/750), so i grew up with Bill Joy's newfangled "vi" and spent countless hours recap'ing the cheat sheet.
To this day stuff like "3dw" and "d}{{[P" are just second nature.
Very much enjoying moders stuff like neovim and CoC/LSP too.
And yes, nvim is perferctly suitable for Java and maven with ctags/ripgrep/fzf etc. plugins
That's because you should've fixed the foundation instead.
For example,
> I frequently opened this by running q: instead of :q, and didn’t know what I had done. Now I know:
But you still haven't fixed the typo-prone keybinds! And you still haven't set up a way to get this information so that next time something unexpected happens you can open your log of commands and see exactly what you've done and decide on the spot if you need to fix it. So you'd need to wait for the next chapter of the "let's read all the manuals" quest to when discover the issue
> Digraphs are an obscure feature for typing obscure characters. For example, you can enter “½” in Insert mode with CTRL-K 1 2. There’s a big list in :digraphs. I don’t use this much, except for typing fractions, but I use this more than I thought I would.
Of course, why would you commit that big list of obscure chars to memory??? The proper interface would be an avoidable visual feedback character picker so that if yo don't remember the "1 2" sequence you can even search for "fractions"
But at this point, why bother with a bad vim component when you can invest in a more general symbol input solution and use it in vim and everywhere else.
> But you still haven't fixed the typo-prone keybinds!
Which key bindings are you referring to?
It's not a trap, I promise! Just fishing for ideas.
I literally meant the ones I quoted
> by running q: instead of :q
other than that don't have a bigger list since most of the defaults are bad, so didn't use them
I stopped listening to Vim users one day. I can’t prove it but I feel like they don’t really understand efficiency, just following the traditions.
What's your definition of efficiency? Is ci" inside "long text here" efficient enough for you, compared to the same thing in traditional editors?
I’ve been using vim and now neovim for 15 years. Before that I was using TextMate. I’ve hand written my own config. I used Janus by Carlhuda, SolarVim, and now I’m on lazyvim because Folke is a goddamn wizard and I want to spend more time getting work done that dealing with breakage in my neovim config
Something I did a little while ago was read through most of Busybox vi's source code, and work out my own simple documentation page with most of its options.
It doesn't do visual mode but it does still work with registers etc.
I used vi first in 1993 on Xenix, master it enough to use when nothing else is available, still not convinced.
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.)
I love neovim but I always forget the keybind I did set myself, "which key" helps a lot here. There are many very nice addons like this that can help!
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
I have been using it for 15+ years as my main editor and I still feel clumsy. I move doing jjjjjjjjjjj very often. I guess I have reached a local maxima and I don't want to invest the extra time on improving
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.
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
maybe throw it in your friendly neighborhood LLM
> single keystroke could move the cursor halfway across the file to exactly the right spot.
sorry what is this? exaggeration?
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.
Capital letters for marks work across files without plugins.
>> 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.
if someone really want to have single keystroke, there's always F<number> key that they can map to their frequently used movements, such as last edit, next function, special marker (such as `m`), etc.
This can happen if you hit * when cursor is on say a function name. it gets you to the next occurance of that word. very useful
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!
Also H, M, and L for high/middle/low of the lines currently visible on the screen.
I find myself using '' as a builtin bookmark to go back to my previous spot when I use G, like gg=G'' to apply code formatting for the whole file then return to my spot.
Then there’s Emacs, where Meta - > takes three fingers!
[deleted]
Yes, it's exaggeration. Modal editing cannot read your mind.
An exercise in submission.
… (For Your Love)” -Frankie Valli
"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 waste of time, you can use someone else's experience instead
> 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.
thank you. vim is a tool, a good tool but just a tool
> Vim and Neovim have more differences than I thought. Among the many changes, [...], that Q repeats the last recorded macro
I followed the link where it says:
> Q Repeat the last recorded register [count] times..
> {Visual}Q In linewise Visual mode, repeat the last recorded register for each selected line.
That's a surprise, I have both in my config since my time on Vim but I didn't know they were implemented by default in Neovim. I guess the maintainers read the same article I did many moons ago.
I'm using neovim all the time, but I don't find this "zipping through the code" to be very critical. Most of the time is spent on thinking and analyzing it, not on fast typing or jumping through it.
Maybe but I often find the bottle neck between thoughts in my head is often the speed of which I can put them in motion, with that in mind vim motions are an absolutely amazing way to interact with a keyboard efficiently.
When using any new software my first thought is often how can I map these actions to vim motions and enable a full keyboard experience.
Depends on what you are doing. When it’s a large codebase, trying to debug or understand a implementation, hitting * to cycle through the occurrences in a file, “gd” to jump to the function definition, Ctrl+o to go to previous position are crucial.
I sure use Ctrl-O, Ctrl-I, * and N / Shift-N etc.
Though for definitions I rely on LSP and Ctrl-] most of the time. Never really used gd.
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.
Another Emacs user here. I would argue that even Emacs is a bit of a struggle sometimes. More modern editors like Sublime Text, Kate, or even Notepad have an advantage of being intuitive. Typing on a letter always outputs that exact letter. The shift key does one thing and one thing only. Mouse integration allows for rather precise cursor placement in a way that utilizes a human's natural hand-eye coordination. The shortcuts that they do use are common across the OS (no need to remember if the copy you need is Ctrl+A - W, Ctrl+W, Ctrl+Shift+C, or Ctrl+C).
Part of the issue is that operating systems have gotten more advanced and more standardized since Vi and Emacs were originally built. However, there is the case that UI designers have learned a lot over the decades. I like Emacs as well, especially when I am doing sysadmin work. However, I have to admit that it is not always intuitive. And even Emacs is more intuitive compared to the modal-nature of Vi.
> have an advantage of being intuitive
Emacs is incredibly intuitive - with a caveat. Once you internalize the model, things become incredibly intuitive. I love that EVERY single keypress, mouse movement and button press is nothing but the association to a piece of Lisp - documented, always available, fully modifiable, debuggable, profilable source. The intuition required is for Lisp only; once you grok that part, Emacs becomes an irreplaceable ally - nothing even comes close to what you can do in it with text.
And btw, Emacs is inherently a modal editor - just like Vim. Only because you're not using modality for "text editing", it doesn't mean it is not.
I never understood the appeal of these command-line editors with a million commands for different edge-cases. Why not just use VSCode? It has every possible extension you already need and a simple GUI. No need to type commands just to edit text when there's a file manager... It has remote SSH and features for vm machines. To me the kinds of people using these editors are the kinds of people that love making everything more complex to seem smart.
Since you asked:
* I’m old. I learned Vim many years before VSCode existed and I have good muscle memory for using it.
* Vim defines many editing commands are available in other places such as shells, db clients, REPLs so I can bring my way of working with me across OSs.
* Learn Vim once and you know it for all time as other editors come and go.
* Vim/NeoVim has even more plugins than VSCode both its own and via LSP, etc.
* Vim is true FOSS. No one can take it away from you, control how you use it or insist they are given ownership of your work including training rights.
* I’ve worked with many VSCode users since it launched. The way I see them using it seems slow to do simple tasks and unappealing.
* Vim is getting easier to use because LLMs are making it easier to learn some of the obscure features.
I don’t mind what editor anyone else wants to use so long as I can use NeoVim. I’ve worked some jobs where the boss insisted everyone has to use what they use and I’ve never stayed long when that happens.
> Why not just use VSCode?
Learning modal editor - vim, nvim, emacs is like skiing or snowboarding. For anyone uninitiated this whole endeavor may seem dumb - you have to spend so much money, time and effort, so you can just descent from a mountain peak to its base on a piece of wood? Absurdly bananas.
Some may even try hitting the greenest, flattest, most beginner-friendly slopes with great confidence, only to find themselves face down in the snow minutes after getting on the lift. They try again. Sometimes, falling for the fourth or fifth time reinforces their belief that it's really is dumb and they just quit at that point.
Some newbie skiers, after a few successful runs, get overly excited and head to the lift for the steeper slope, only to regret their decision. If falling all the way down doesn't make them quit, they may eventually start enjoying it.
At some point, they'd gain so much experience - their movements become smooth and graceful, their speed intimidating. Suddenly, they'd discover an enormous, indescribable feeling of joy. There's so much tacit - emotional, mental and physical enlightenment that is almost impossible to convey to another soul who's never experienced it or rose to that level.
Then there's a spectrum of differences - some still fall all the time yet enjoy it nonetheless, and they enthusiastically discuss with other beginner skiers how awesome they feel. Some, after mastering the most difficult carving techniques, somehow forget their own beginner's journey and become apathetic toward rookies.
So, then why ski [vim] at all? Well, it is truly one of the most efficient, fastest, healthy ways of getting back to the base [dealing with text]. But most importantly it's tremendously fun. Often, in quite indescribable ways. I'm afraid you would never understand the appeal until you do try it. But even then, it's never guaranteed you'd find that thrill; then maybe skiing [vimming] isn't for you. Even though these activities literally for everyone (unless they have physical/mental barriers).
I honestly can't take seriously any programmer who doesn't know the basics of vim - doesn't that suggest they've never used sed, less, or read through man pages? Have they never had to ssh to a remote machine in the terminal? I do though get it, when people say "I tried it and ain't for me". I suppose, it just means they've never hit the spot that inspired them to keep going.
Why use C++ when you can use BASIC?
The learning curve can be steep but once you learn vi/Vim you can never go back to an IDE like VScode because it is so unbelievably limited.
When you get comfortable with vi it really begins to feel like you can type text in VScode but you can't edit it.
> To me the kinds of people using these editors are the kinds of people that love making everything more complex to seem smart.
"I don't understand something and instead of asking nicely I decide to throw a tantrum and offend people". Why do you think it's appropriate to say things like this? Did I or any other vim/emacs/whatever user forced you to convert to their editor of choice?
> To me the kinds of people using these editors are the kinds of people that love making everything more complex to seem smart.
If your instinct is to be denigrate people who do things differently than you, you will never understand them. However, you get the advantage of feeling superior.
Let me say why I continue using vi. I started using vi in the early 80s, then moved to vim in the mid 90s. Even people who aren't as old at me have more than a decade of using vi/vim/nvi. Those commands that seem like a burden to remember are completely transparent to me -- that is, I don't need to think about what keystroke to hit to achieve my ends. Why should I climb another learning curve?
If you tell me to just download a vi mode for vscode, I can tell you that the basic motions work, but that last 10% cause unending grief. It is like eating pasta where every 10th noodle is actually a rock disguised to look like a noodle -- completely disruptive.
I can edit quickly when I don't need to move my hands off the keyboard. Likely your dominant hand is flopping back and forth between the mouse and the keyboard when using your gui-centric editor.
> I never understood the appeal of these command-line editors with a million commands for different edge-cases. Why not just use VSCode? It has every possible extension you already need
I'd prefer to have a few dozen composable verbs and nouns than having to research and download "a million" extensions for the edge cases.
> No need to type commands just to edit text when there's a file manager
I have no idea what you mean by this. How does a file manager edit your text?
> It has remote SSH and features for vm machines
You can do that from vim as well. vim/nvi has a plugin ecosystem too. My own philosophy is to use as few of them as I can: one (the 'matchit' feature which ships with the editor).
The final thing you are missing is that nobody uses all the commands -- they find the ones that work for them and they use them without further thought once it becomes muscle memory. If the need ever arises to learn a new command or setting, I'll get around to it when the time comes. If I learn a bunch of things and don't use them, they get quickly forgotten anyway.
This matches my experience completely: more than 40 years using vi and then vim, my fingers and my brain know to do.
I've tried to use VScode, especially since people said that it could emulate vi... it can't. Some of the basics are there, but then you forget you are in a different program, and use something that works in vim... and it fails. A couple of times with catastrophic results: I lost a file completely after typing a command.
I actually repeat the experiment every year or so, but I do not see much improvement.
If I'm already in the terminal, they're perfect for quickly looking through and editing files. Heck, I've done it plenty where I'm in the VS Code embedded terminal to run some commands and then I want to quickly touch a file and so I open neovim inside the VS Code terminal!
I use zed now, Pycharm before that, Emacs before that, VSCode before that - one common thing amongst them all, I always install the “vim mode” plugin as the first thing. I always have a working vim/neovim setup beside all of them.
It’s not to look smart or because I like making things complex. I am not the one to tinker too much (hence the jump between editors, if I get too invested, I move). The benefits of VIM motions have nothing to do with the editors themselves. If you have never tried it, I would strongly recommend giving vim mode a go, in whatever editor you fancy.
> To me the kinds of people using these editors are the kinds of people that love making everything more complex to seem smart.
I finally jumped the gun almost a decade ago because I had too many Electron apps for my cheap laptop to handle and had to scale down to be able to get anything done without freezes.
At first the modal editing was difficult but it clicked immediately and these days I'm handicapped in normal typing. I still type vim motions by accident in Libreoffice which is the last program I use that doesn't support modal editing. Lately I'm getting around that by typing in markdown and using pandoc to convert it to `.odt` or `.docx`.
> every possible extension you already need
In Vim land the first step isn't to install an extension, it's to create a keybinding. It can be as simple as a one-liner, to a shell script or even command-line tools. You can run it on the filename, the file contents, or the selection. The only limit is your imagination and experience. You don't really get it yet because you're conditioned into thinking the way you're used to, not how it could be done.
It has nothing to do with looking smart, I don't care what others think. Could it be your own coping mechanism for feeling dumb about not being able to use it?
these command-line editors with a million commands for different edge-cases
Have you ever actually tried vim? You use the keyboard to move around and search for terms. You don't actually need to learn much.
Why not just use VSCode?
Because it's a bloated electron program that takes huge resources to edit text.
To me the kinds of people using these editors are the kinds of people that love making everything more complex to seem smart.
Seems like insecurity if you've never learned it yourself.
you do not need to install it anywhere...
its already everywhere ( I am vim enthusiast )
for eg: Keep right hand free for writing/eating by reserving left hand for mouse. (keep same settings for right handed mouse)
Brrrr... :p
So would the use-case mostly be for people who edit lots of files over shells? I guess I was mostly thinking of coding stuff. Or do people use it for coding too?
I mostly use IDEs for day to day coding, and pretty much every IDE supports vim keybindings, which I always have enabled. I also use vim in the terminal for small edits and one-off files, so it's not either/or.
After the initial learning curve and fiddling with settings, it just becomes natural and you can edit code or other text at blazing fast speeds. I also find that it helps with RSI by reducing arm motions reaching for the mouse.
Of course, there are other good options out there, but if vim fits your brain, it can significantly boost your editing speed. For those who say programmers don't spend that much time typing, that's true sometimes, but there are periods after the design/planning phase where we type a lot, and I want that to go as fast as possible while I have an implementation loaded into short term memory.
As someone who used to be a vim skeptic myself, I'd suggest you either give it another look or just accept that it works well for other people and go on with your day.
Of course vi/Vim is used for programming ('coding').
I've been doing that since the early nineties. First vi, later Vim.
I like it better than Visual Studio, better than Eclipse and way better than VScode.
> Or do people use it for coding too?
Over time, you may discover one of the biggest truth about computing - the immense (and sadly disregarded) value of plain text¹. Code is nothing but structured text. The cardinal job of a programmer is text manipulation.
I'm reading this thread in my editor. Why? Because I'm dealing with text - browsers are great for presentation of text, not so nice for manipulating it. What kind of manipulations? Well, I can find, sort, group, narrow, collapse/expand, translate, extract summaries for paragraphs, find all the URLs (including matching a pattern), etc. Good luck doing all that in the browser - even with the extensions.
Most developers don't even get annoyed by seemingly small things. Like how often do you need to bring the url of a given browser tab into your editor? Simplest thing, yet do it dozens of times a day and it gets vexing. For me - it takes milliseconds and a keypress - it even extracts the URL description and converts the link to markdown (if needed).
Or another example - whenever someone's screen sharing, or I'm watching a video and they show a piece of text (let's just for consistency say a url). How would you normally extract it? e.g, for your notes. For me - it takes selecting a region of screen and a keypress - my editor calls a CLI OCRing tool and voila. I don't really care that the source isn't "technically speaking" text - if I can read it, then computer for sure can "read" it too, am I right? That's text manipulation.
There may be dozens (if not hundreds) of such examples (including coding-related) in my workflow that work on top of the idea of manipulating plain text.
Once you grok the cerebral virtue of the idea of having complete and total control over text, you may find that modal editors - nvim/emacs/etc. - are the best instruments to achieve that control.
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.
I don't believe your last sentence at all -- especially if we're talking about "bespoke software for individuals."
I strongly predict it will be trivial.
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.
But the thing is -- will it be?
Which is to say, let's take two extremes. The "vim" way vs. the ultra-Emacs way, right? The thing is, it will soon become trivially easy to modify your own "text editing environment," and by you I mean everyone?
The more I read this, the more I'm strongly predicting a resurgence in this sort of individualization.
>The thing is, it will soon become trivially easy to modify your own "text editing environment,"
elisp enters the chat
Any thoughts on Neovim? Do you like it?
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.
Exactly. My journey is similar, probably because I've never had to code for a living. I started learning Vim. I dedicated 2 years to Emacs + Org-Mode.
And eventually I left. I've come to realize (for me) anything that can't do CUA keybinding easily and well, usually out of the box, is useless to me because I use other software.
So now I'm riding this weird middle space between Vim and Geany mostly because I haven't had time to dig into making something different. But I'm just about 100% certain that I'll be able to make a perfect-for-me bespoke text editor very soon, thanks to AI. I know it would have been possible in Emacs, I just didn't have the time.
[dead]
neovim is pretty flexible and extensible if you don't want to follow default behavior.
Stuff like typing "10j" made sense when text editing was high latency. Nowadays you can just hold j and stop precisely where you wanted to, even if you're ssh'ing into a server on the other side of the country. There's nothing wrong with it (and in fact I prefer it because of the 0 finger movement required).
The only times I use "precise" movement commands like that is when I'm in the odd situation of having to ssh into something from my phone.
I found that moving between empty lines is the nicest way to navigate most code across all programming languages, markup languages and just regular text. I don’t have to think, I don’t have to count, I just move and select text big chunks at a time… (not in vim, but I first saw someone have key bindings for this in vim)
This is the one thing I brought from my time of trying out vim.
I have now set all my editors to move by paragraph with ctrl+up/dn. It fits so well together with ctrl+left/right that I think it should be standard behaviour. I also set up ctrl+shift+up/dn to select, of course.
>I have now set all my editors to move by paragraph with ctrl+up/dn.
It's even simpler with Vim - just one keystroke - { or }.
On a US keyboard layout this is the same number of keys because { and } are Shift+[ and Shift+]
https://vimhelp.org/motion.txt.html#%7B
What does exclusive motion mean here?
That's because you aren't combining it with more advanced commands, or macros.
"10j" may sound useless. But "y10j50jp" is much more effective. Put that in a macro that does other stuff too, and suddenly you perform complex editions to a file containing thousands of lines of text in a few seconds.
It's slower to "stop precisely"on key hold/release, so 10j still makes more sense, only for a few lines tapping J a few times makes more sense, but not 10-20
I've tried so many times to make it work, I've really tried. But it just ends up being faster to spam j a couple of times instead of having to think about how many times I want to move, then type it, then be wrong, then try again...
For larger distances you wouldn't even see the text in the screen, so you don't even know how much to jump. In this situation I just spam ctrl+d, then tweak with j.
Relative line numbers = no thinking
Look where you want to go, there's a number next to it. Type that number and then type j.
It can be about as fast if you set key repeat delay to minimum and repeat speed to maximum. I used it for a while and got quite precise with it. Works well until someone else needs to use your computer for a moment...
Hm, I doubt the precision can match and avoid under/overshootings, especially at high enough repeat speed to match, and it's a global change that can affect even regular typing, so you're suggesting specialized training (to minimizeerrors) for a less effective workflow
The main issue with precise jumps (for me) is that they require you to
- already exactly know where you want to go
- figure out the relative distance either by looking to the side at relative line numbers or calculating
- move your hands to the numbers row to input numbers and back (I don't have small hands, but that still translates into a small amount of arm movement for me).
Whereas just using repeat input on jklhwe... only requires you to have a rough idea initially and leaves you plenty of time to figure out where exactly you want to stop while you're already getting there.
Besides: I don't like to think about random numbers while I'm coding. Doesn't exactly make the cursor feel like an extension of my body (imagine you had to tell your hand "move 10 centimeters left")
Another quite intuitive way I navigate is using "/something" and cycling through hits - usually you know some text that appears near the area you want to go. That was pretty much instant muscle memory.
> - already exactly know where you want to go
Same as with moving down by 1x10? How are you even choosing cursor direction if you don't know where to go to?
> - figure out the relative distance either by looking to the side
Ok, how is that an issue? You also have to figure out the distance by looking down when moving down with the arrows, so eyes still move?
> move your hands to the numbers row to input numbers and back
No, you could maintain your hands on the home row and use a numpad layer containing it
> imagine you had to tell your hand "move 10 centimeters left"
Imagine you had to tell your hand "move 1 centimeter left 10 times"? The mouse is that extension where you don't "move by 1 pixel X times" and move in an analog way
Oh. Now I get why we're talking past each other. There's a thing most computers are configured to do out of the box, but yours might be different for some reason.
I'm going to assume you're using Windows. In that case go to Settings > Accessibility > Keyboard and configure "Character Repeat". What this will do is repeat a key you're holding as if you're pressing it multiple times! Configure it until it feels natural.
This is what people were referring to when we said we're holding a key. We're not pressing it 10 times, just holding it down and having the computer automatically repeat it until we're happy with the result (such as having moved where we wanted to). It's a bit like moving a mouse cursor, where you're also not calculating the offset you want to move your mouse in advance.
> It's slower to "stop precisely"on key hold/release
For longer distances, unless your repeat speed is very slow, you're often either holding a key repeat and stop before a few lines and then tap or overshooting and tap to go back. So ok, it's not 1x10, but 7+1x3 or 12-1x2
(but yes, the initial leg of the journey is more mouse-like "natural", but still not that because you can't vary speed on most keyboards unlike with they mouse/hand)
For smaller distances you could just tap a few times.
No one is doing 1x10 key presses. That's now how humans process information. You repeatedly press a key one time until what you see on screen is what you want. The further away you are the faster you do it.
> press a key one time
That's "1"
> You repeatedly press
That's x10
Generally I'm using 'e' to go forward and 'b' to go backward
Whereas I have always used `w` and did not even know that `e` existed (not that I can see an obvious advantage to it). Ahh, vim.
More often than not you want 'de' or 'ye' rather than 'dw' or 'yw'
> (not that I can see an obvious advantage to it).
Precision. I use e/E more often than w/W when editing a line or creating macros, but w/W for moving around. But more often i search with f and jump to next match with ; if I didn't hit the target right away. / then n if I'm moving to another line.
I think it took me about four months of daily use to know most of the editor basics without having to pause to look up things. Another eight for it all to feel natural. And, maybe about six years later, it remains my favorite text entry and code editing environment.
I've been using the LazyVim <https://www.lazyvim.org/> neovim setup and a handful of extras, but not too many. I still have to look up some esoteric stuff, but for the most part, it's completely natural.
And for the first few years, I was a hardline keyboard-only absolutist, but lately I've been using the mouse where it makes sense, and sometimes it does.
(MacOS, iTerm2, neovim, lazyvim, love this combo)
Have you tried WezTerm yet? It also uses lua for writing its configs which makes it highly customizable.
I've switched to it from iTerm2 a couple of years ago and gradually added more and more to my config and it's super powerful.
I have various issues with it (e.g. wrapping on resize is just broken) and miss iTerm a little, but the built-in tabs aren’t too bad (unlike Kitty’s hardline stance) and it’s available cross-platform, so I can have the same config on many machines.
Ghostty is also a great option on macOS (on Linux I use Alacritty).
> unlike Kitty’s hardline stance
Are you maybe switching that up with alacritty? Kitty has built-in tabs and they work quite well.
Yes! Sorry Kitty for mixing you up!
> but lately I've been using the mouse where it makes sense
Get off my lawn, hippie
hehe
> 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".
Hokusai wrote at the age of 75 that he would only begin to understand the structure of living beings at 100, and hoped to “reach perfection at 110.” He died at 89.
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.
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.
Does anyone have a motion jump plugin they use with neovim they can recommend? I used to use a plugin where you could just to a given character in a given buffer, but I can’t remember the name or if it even works with neovim.
leap.nvim
you press a keybind and then press one or two characters , all instances of that character pair in the viewport will get get a hint (a characteror two in highlight) , hit those two hint keys and the cursor jumps to that location
its incredibly fast to navigate around your viewport with this.
https://codeberg.org/andyg/leap.nvim
+1 Leap takes a second to get used to but I love it so much. Even if you don't get to the precise character you want, you can get so close enough that normal motion commands get you the rest of the way.
I do change the bindings, tho. I have 's' leap forwards and 'S' leap backwards.
Like the nth character in the current buffer? I believe vim has that built-in: `<n>go`. I think `<n><space>` will do it relative to your current position.
Actually, `<n><space>` ignores things like new lines.
Check out folke/flash.nvim for a motion jump plugin. It’s brilliant.
I applaud this project, “setting all the options”. I think it’s a really good idea to become close friends with the software you use all the time, and getting acquainted through the lens of configuration is one way. Messing around with stuff is good.
I feel it’s worth mentioning that there is a sense in which I think it might be a bad idea. It could be that you’d now be fixating some value that may be optimal right now, rather than benefiting from future improvements to the default settings. But it all depends, of course, on how close friends you plan to be.
"Become close friends with the software you use all the time." That is a beautifully evocative phrase for a lovely idea, thank you for sharing.
If I may share an idea for which I don't have nearly as nice and succinct a summation, but I've come to view my personal computing environments through the lens of being a garden. I spend so much time within them, working, learning, playing and writing. I can see the different seasons of my life reflected through naming conventions, directory structures, scripts I've written and bookmarks I've long ignored. There are new things I want to try and explore in the spring when I hopefully have a bit more free time. I have planted seeds while children slept in my arms or in the next room, and I have enabled their dreams with the fruits of my labour. I would even say I have occasionally communed with the close and holy darkness on long, late nights.
In time everything I have created will return to dust, and probably no one will ever know this garden as I have. But it has still been a place of growth and blessing.
I've been using vim for over 20 years as my primary editor. I'm faster and more comfortable in it than I am in any other editor, but I still feel like a vim noob
I still have to look up how to do things I rarely do (like insert the contents of another file at the cursor position). And I don't really use many (if any) of vim's intermediate features, let alone advanced ones.
I've tried various ways to get more fluent, but nothing really stuck or kept my interest. This has always annoyed me a bit...
Same here. I use vim over other editors / key schemas mostly because it's easier for me than pressing a whole bunch of keys simultaneously. I use it where I can in other apps too. That's also why I only use a relatively small subset (whatever they all implement) and never spent too much time into going totally overboard with learning all its capabilities.
Also, typing just isn't really that much of task in the first place. I spend way more time trying to find out what to do and how, and then finally typing it isn't as relevant that I would need to optimize it over a certain point.
I've been using vim for 20 years as well, for everything other than Java code. I type my .vimrc by hand on each new machine to set a half dozen options.
Of the intermediate features, I use tabs and, more recently, split windows.
My favorite 'advanced' feature is visual block selection and replacement over multiple lines - super convenient.
I think vim's greatest problem is discoverability. It's a big enough problem that after six or so months working full time in neovim I went back to a GUI editor. I just about barely remember the most common commands, but I do not remember (at all) anything I only need occasionally. I also know myself well enough to know I will never remember this sort of thing well. I have a terrible memory for procedural / administrative / ritualistic knowledge.
I'm on Sublime right now. I like it a lot less than vim, but it's far less cryptic. If I need to tile four documents and move text around, I can do so trivially by dragging, without needing a PhD in vim esoterica that I would immediately forget the next day.
My time with Vi/Vim is similar, measured in decades.
There's a lot in Vim, and there's no requirement to be a tech maximalist. Settling at core features is not being a noob.
I was lucky enough that my first employer ran the very first 4.2BSD in Denmark outside academia (on a DEC-VAX/750), so i grew up with Bill Joy's newfangled "vi" and spent countless hours recap'ing the cheat sheet.
To this day stuff like "3dw" and "d}{{[P" are just second nature. Very much enjoying moders stuff like neovim and CoC/LSP too.
And yes, nvim is perferctly suitable for Java and maven with ctags/ripgrep/fzf etc. plugins
That's because you should've fixed the foundation instead.
For example,
> I frequently opened this by running q: instead of :q, and didn’t know what I had done. Now I know:
But you still haven't fixed the typo-prone keybinds! And you still haven't set up a way to get this information so that next time something unexpected happens you can open your log of commands and see exactly what you've done and decide on the spot if you need to fix it. So you'd need to wait for the next chapter of the "let's read all the manuals" quest to when discover the issue
> Digraphs are an obscure feature for typing obscure characters. For example, you can enter “½” in Insert mode with CTRL-K 1 2. There’s a big list in :digraphs. I don’t use this much, except for typing fractions, but I use this more than I thought I would.
Of course, why would you commit that big list of obscure chars to memory??? The proper interface would be an avoidable visual feedback character picker so that if yo don't remember the "1 2" sequence you can even search for "fractions" But at this point, why bother with a bad vim component when you can invest in a more general symbol input solution and use it in vim and everywhere else.
> But you still haven't fixed the typo-prone keybinds!
Which key bindings are you referring to?
It's not a trap, I promise! Just fishing for ideas.
I literally meant the ones I quoted
> by running q: instead of :q
other than that don't have a bigger list since most of the defaults are bad, so didn't use them
I stopped listening to Vim users one day. I can’t prove it but I feel like they don’t really understand efficiency, just following the traditions.
What's your definition of efficiency? Is ci" inside "long text here" efficient enough for you, compared to the same thing in traditional editors?
I’ve been using vim and now neovim for 15 years. Before that I was using TextMate. I’ve hand written my own config. I used Janus by Carlhuda, SolarVim, and now I’m on lazyvim because Folke is a goddamn wizard and I want to spend more time getting work done that dealing with breakage in my neovim config
Something I did a little while ago was read through most of Busybox vi's source code, and work out my own simple documentation page with most of its options. It doesn't do visual mode but it does still work with registers etc.
I used vi first in 1993 on Xenix, master it enough to use when nothing else is available, still not convinced.
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.)
I love neovim but I always forget the keybind I did set myself, "which key" helps a lot here. There are many very nice addons like this that can help!
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 have been using it for 15+ years as my main editor and I still feel clumsy. I move doing jjjjjjjjjjj very often. I guess I have reached a local maxima and I don't want to invest the extra time on improving
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
> single keystroke could move the cursor halfway across the file to exactly the right spot.
sorry what is this? exaggeration?
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.
Capital letters for marks work across files without plugins.
>> 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.
if someone really want to have single keystroke, there's always F<number> key that they can map to their frequently used movements, such as last edit, next function, special marker (such as `m`), etc.
This can happen if you hit * when cursor is on say a function name. it gets you to the next occurance of that word. very useful
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!
Also H, M, and L for high/middle/low of the lines currently visible on the screen.
I find myself using '' as a builtin bookmark to go back to my previous spot when I use G, like gg=G'' to apply code formatting for the whole file then return to my spot.
Then there’s Emacs, where Meta - > takes three fingers!
Yes, it's exaggeration. Modal editing cannot read your mind.
An exercise in submission.
… (For Your Love)” -Frankie Valli
"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 waste of time, you can use someone else's experience instead
> 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.
thank you. vim is a tool, a good tool but just a tool
> Vim and Neovim have more differences than I thought. Among the many changes, [...], that Q repeats the last recorded macro
I followed the link where it says:
> Q Repeat the last recorded register [count] times..
> {Visual}Q In linewise Visual mode, repeat the last recorded register for each selected line.
That's a surprise, I have both in my config since my time on Vim but I didn't know they were implemented by default in Neovim. I guess the maintainers read the same article I did many moons ago.
I'm using neovim all the time, but I don't find this "zipping through the code" to be very critical. Most of the time is spent on thinking and analyzing it, not on fast typing or jumping through it.
Maybe but I often find the bottle neck between thoughts in my head is often the speed of which I can put them in motion, with that in mind vim motions are an absolutely amazing way to interact with a keyboard efficiently.
When using any new software my first thought is often how can I map these actions to vim motions and enable a full keyboard experience.
Depends on what you are doing. When it’s a large codebase, trying to debug or understand a implementation, hitting * to cycle through the occurrences in a file, “gd” to jump to the function definition, Ctrl+o to go to previous position are crucial.
I sure use Ctrl-O, Ctrl-I, * and N / Shift-N etc.
Though for definitions I rely on LSP and Ctrl-] most of the time. Never really used gd.
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.
Another Emacs user here. I would argue that even Emacs is a bit of a struggle sometimes. More modern editors like Sublime Text, Kate, or even Notepad have an advantage of being intuitive. Typing on a letter always outputs that exact letter. The shift key does one thing and one thing only. Mouse integration allows for rather precise cursor placement in a way that utilizes a human's natural hand-eye coordination. The shortcuts that they do use are common across the OS (no need to remember if the copy you need is Ctrl+A - W, Ctrl+W, Ctrl+Shift+C, or Ctrl+C).
Part of the issue is that operating systems have gotten more advanced and more standardized since Vi and Emacs were originally built. However, there is the case that UI designers have learned a lot over the decades. I like Emacs as well, especially when I am doing sysadmin work. However, I have to admit that it is not always intuitive. And even Emacs is more intuitive compared to the modal-nature of Vi.
> have an advantage of being intuitive
Emacs is incredibly intuitive - with a caveat. Once you internalize the model, things become incredibly intuitive. I love that EVERY single keypress, mouse movement and button press is nothing but the association to a piece of Lisp - documented, always available, fully modifiable, debuggable, profilable source. The intuition required is for Lisp only; once you grok that part, Emacs becomes an irreplaceable ally - nothing even comes close to what you can do in it with text.
And btw, Emacs is inherently a modal editor - just like Vim. Only because you're not using modality for "text editing", it doesn't mean it is not.
I never understood the appeal of these command-line editors with a million commands for different edge-cases. Why not just use VSCode? It has every possible extension you already need and a simple GUI. No need to type commands just to edit text when there's a file manager... It has remote SSH and features for vm machines. To me the kinds of people using these editors are the kinds of people that love making everything more complex to seem smart.
Since you asked:
* I’m old. I learned Vim many years before VSCode existed and I have good muscle memory for using it.
* Vim defines many editing commands are available in other places such as shells, db clients, REPLs so I can bring my way of working with me across OSs.
* Learn Vim once and you know it for all time as other editors come and go.
* Vim/NeoVim has even more plugins than VSCode both its own and via LSP, etc.
* Vim is true FOSS. No one can take it away from you, control how you use it or insist they are given ownership of your work including training rights.
* I’ve worked with many VSCode users since it launched. The way I see them using it seems slow to do simple tasks and unappealing.
* Vim is getting easier to use because LLMs are making it easier to learn some of the obscure features.
I don’t mind what editor anyone else wants to use so long as I can use NeoVim. I’ve worked some jobs where the boss insisted everyone has to use what they use and I’ve never stayed long when that happens.
> Why not just use VSCode?
Learning modal editor - vim, nvim, emacs is like skiing or snowboarding. For anyone uninitiated this whole endeavor may seem dumb - you have to spend so much money, time and effort, so you can just descent from a mountain peak to its base on a piece of wood? Absurdly bananas.
Some may even try hitting the greenest, flattest, most beginner-friendly slopes with great confidence, only to find themselves face down in the snow minutes after getting on the lift. They try again. Sometimes, falling for the fourth or fifth time reinforces their belief that it's really is dumb and they just quit at that point.
Some newbie skiers, after a few successful runs, get overly excited and head to the lift for the steeper slope, only to regret their decision. If falling all the way down doesn't make them quit, they may eventually start enjoying it.
At some point, they'd gain so much experience - their movements become smooth and graceful, their speed intimidating. Suddenly, they'd discover an enormous, indescribable feeling of joy. There's so much tacit - emotional, mental and physical enlightenment that is almost impossible to convey to another soul who's never experienced it or rose to that level.
Then there's a spectrum of differences - some still fall all the time yet enjoy it nonetheless, and they enthusiastically discuss with other beginner skiers how awesome they feel. Some, after mastering the most difficult carving techniques, somehow forget their own beginner's journey and become apathetic toward rookies.
So, then why ski [vim] at all? Well, it is truly one of the most efficient, fastest, healthy ways of getting back to the base [dealing with text]. But most importantly it's tremendously fun. Often, in quite indescribable ways. I'm afraid you would never understand the appeal until you do try it. But even then, it's never guaranteed you'd find that thrill; then maybe skiing [vimming] isn't for you. Even though these activities literally for everyone (unless they have physical/mental barriers).
I honestly can't take seriously any programmer who doesn't know the basics of vim - doesn't that suggest they've never used sed, less, or read through man pages? Have they never had to ssh to a remote machine in the terminal? I do though get it, when people say "I tried it and ain't for me". I suppose, it just means they've never hit the spot that inspired them to keep going.
Why use C++ when you can use BASIC?
The learning curve can be steep but once you learn vi/Vim you can never go back to an IDE like VScode because it is so unbelievably limited.
When you get comfortable with vi it really begins to feel like you can type text in VScode but you can't edit it.
> To me the kinds of people using these editors are the kinds of people that love making everything more complex to seem smart.
"I don't understand something and instead of asking nicely I decide to throw a tantrum and offend people". Why do you think it's appropriate to say things like this? Did I or any other vim/emacs/whatever user forced you to convert to their editor of choice?
> To me the kinds of people using these editors are the kinds of people that love making everything more complex to seem smart.
If your instinct is to be denigrate people who do things differently than you, you will never understand them. However, you get the advantage of feeling superior.
Let me say why I continue using vi. I started using vi in the early 80s, then moved to vim in the mid 90s. Even people who aren't as old at me have more than a decade of using vi/vim/nvi. Those commands that seem like a burden to remember are completely transparent to me -- that is, I don't need to think about what keystroke to hit to achieve my ends. Why should I climb another learning curve?
If you tell me to just download a vi mode for vscode, I can tell you that the basic motions work, but that last 10% cause unending grief. It is like eating pasta where every 10th noodle is actually a rock disguised to look like a noodle -- completely disruptive.
I can edit quickly when I don't need to move my hands off the keyboard. Likely your dominant hand is flopping back and forth between the mouse and the keyboard when using your gui-centric editor.
> I never understood the appeal of these command-line editors with a million commands for different edge-cases. Why not just use VSCode? It has every possible extension you already need
I'd prefer to have a few dozen composable verbs and nouns than having to research and download "a million" extensions for the edge cases.
> No need to type commands just to edit text when there's a file manager
I have no idea what you mean by this. How does a file manager edit your text?
> It has remote SSH and features for vm machines
You can do that from vim as well. vim/nvi has a plugin ecosystem too. My own philosophy is to use as few of them as I can: one (the 'matchit' feature which ships with the editor).
The final thing you are missing is that nobody uses all the commands -- they find the ones that work for them and they use them without further thought once it becomes muscle memory. If the need ever arises to learn a new command or setting, I'll get around to it when the time comes. If I learn a bunch of things and don't use them, they get quickly forgotten anyway.
This matches my experience completely: more than 40 years using vi and then vim, my fingers and my brain know to do.
I've tried to use VScode, especially since people said that it could emulate vi... it can't. Some of the basics are there, but then you forget you are in a different program, and use something that works in vim... and it fails. A couple of times with catastrophic results: I lost a file completely after typing a command.
I actually repeat the experiment every year or so, but I do not see much improvement.
If I'm already in the terminal, they're perfect for quickly looking through and editing files. Heck, I've done it plenty where I'm in the VS Code embedded terminal to run some commands and then I want to quickly touch a file and so I open neovim inside the VS Code terminal!
I use zed now, Pycharm before that, Emacs before that, VSCode before that - one common thing amongst them all, I always install the “vim mode” plugin as the first thing. I always have a working vim/neovim setup beside all of them.
It’s not to look smart or because I like making things complex. I am not the one to tinker too much (hence the jump between editors, if I get too invested, I move). The benefits of VIM motions have nothing to do with the editors themselves. If you have never tried it, I would strongly recommend giving vim mode a go, in whatever editor you fancy.
> To me the kinds of people using these editors are the kinds of people that love making everything more complex to seem smart.
I finally jumped the gun almost a decade ago because I had too many Electron apps for my cheap laptop to handle and had to scale down to be able to get anything done without freezes.
At first the modal editing was difficult but it clicked immediately and these days I'm handicapped in normal typing. I still type vim motions by accident in Libreoffice which is the last program I use that doesn't support modal editing. Lately I'm getting around that by typing in markdown and using pandoc to convert it to `.odt` or `.docx`.
> every possible extension you already need
In Vim land the first step isn't to install an extension, it's to create a keybinding. It can be as simple as a one-liner, to a shell script or even command-line tools. You can run it on the filename, the file contents, or the selection. The only limit is your imagination and experience. You don't really get it yet because you're conditioned into thinking the way you're used to, not how it could be done.
It has nothing to do with looking smart, I don't care what others think. Could it be your own coping mechanism for feeling dumb about not being able to use it?
these command-line editors with a million commands for different edge-cases
Have you ever actually tried vim? You use the keyboard to move around and search for terms. You don't actually need to learn much.
Why not just use VSCode?
Because it's a bloated electron program that takes huge resources to edit text.
To me the kinds of people using these editors are the kinds of people that love making everything more complex to seem smart.
Seems like insecurity if you've never learned it yourself.
you do not need to install it anywhere... its already everywhere ( I am vim enthusiast )
for eg: Keep right hand free for writing/eating by reserving left hand for mouse. (keep same settings for right handed mouse) Brrrr... :p
So would the use-case mostly be for people who edit lots of files over shells? I guess I was mostly thinking of coding stuff. Or do people use it for coding too?
I mostly use IDEs for day to day coding, and pretty much every IDE supports vim keybindings, which I always have enabled. I also use vim in the terminal for small edits and one-off files, so it's not either/or.
After the initial learning curve and fiddling with settings, it just becomes natural and you can edit code or other text at blazing fast speeds. I also find that it helps with RSI by reducing arm motions reaching for the mouse.
Of course, there are other good options out there, but if vim fits your brain, it can significantly boost your editing speed. For those who say programmers don't spend that much time typing, that's true sometimes, but there are periods after the design/planning phase where we type a lot, and I want that to go as fast as possible while I have an implementation loaded into short term memory.
As someone who used to be a vim skeptic myself, I'd suggest you either give it another look or just accept that it works well for other people and go on with your day.
Of course vi/Vim is used for programming ('coding').
I've been doing that since the early nineties. First vi, later Vim.
I like it better than Visual Studio, better than Eclipse and way better than VScode.
> Or do people use it for coding too?
Over time, you may discover one of the biggest truth about computing - the immense (and sadly disregarded) value of plain text¹. Code is nothing but structured text. The cardinal job of a programmer is text manipulation.
I'm reading this thread in my editor. Why? Because I'm dealing with text - browsers are great for presentation of text, not so nice for manipulating it. What kind of manipulations? Well, I can find, sort, group, narrow, collapse/expand, translate, extract summaries for paragraphs, find all the URLs (including matching a pattern), etc. Good luck doing all that in the browser - even with the extensions.
Most developers don't even get annoyed by seemingly small things. Like how often do you need to bring the url of a given browser tab into your editor? Simplest thing, yet do it dozens of times a day and it gets vexing. For me - it takes milliseconds and a keypress - it even extracts the URL description and converts the link to markdown (if needed).
Or another example - whenever someone's screen sharing, or I'm watching a video and they show a piece of text (let's just for consistency say a url). How would you normally extract it? e.g, for your notes. For me - it takes selecting a region of screen and a keypress - my editor calls a CLI OCRing tool and voila. I don't really care that the source isn't "technically speaking" text - if I can read it, then computer for sure can "read" it too, am I right? That's text manipulation.
There may be dozens (if not hundreds) of such examples (including coding-related) in my workflow that work on top of the idea of manipulating plain text.
Once you grok the cerebral virtue of the idea of having complete and total control over text, you may find that modal editors - nvim/emacs/etc. - are the best instruments to achieve that control.
___
¹https://graydon2.dreamwidth.org/193447.html
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.
I don't believe your last sentence at all -- especially if we're talking about "bespoke software for individuals."
I strongly predict it will be trivial.
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.
But the thing is -- will it be?
Which is to say, let's take two extremes. The "vim" way vs. the ultra-Emacs way, right? The thing is, it will soon become trivially easy to modify your own "text editing environment," and by you I mean everyone?
The more I read this, the more I'm strongly predicting a resurgence in this sort of individualization.
>The thing is, it will soon become trivially easy to modify your own "text editing environment,"
elisp enters the chat
Any thoughts on Neovim? Do you like it?
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.
Exactly. My journey is similar, probably because I've never had to code for a living. I started learning Vim. I dedicated 2 years to Emacs + Org-Mode.
And eventually I left. I've come to realize (for me) anything that can't do CUA keybinding easily and well, usually out of the box, is useless to me because I use other software.
So now I'm riding this weird middle space between Vim and Geany mostly because I haven't had time to dig into making something different. But I'm just about 100% certain that I'll be able to make a perfect-for-me bespoke text editor very soon, thanks to AI. I know it would have been possible in Emacs, I just didn't have the time.
[dead]
neovim is pretty flexible and extensible if you don't want to follow default behavior.