I dunno, I never sat down to learn vim, just used it every day for a couple years. I’m not one of those wizards who is, like, answering stack overflow questions or writing wiki articles, but I get the job done. Is it necessary to learn Vim? Seems like a chore.
Is the text editor really a bottleneck for anyone? I find that no matter how slow I type, I need to spend more time thinking of what to type anyway, if I’m doing anything interesting.
I don't understand this attitude. It's clearly more conducive to solving problems to be able to move around our environment more quickly. It's extremely useful (compared to a beginner who only knows insert and write quit) to understand the different vim modalities as well as a few commands to jump around a file or to perform regex or to call an external command.
When you're not proficient with the necessary tools, you're interrupting your flow with what you consider mundane. That you consider text editors mundane is more reason to move as much of that process into muscle memory as possible, not less!
Why are we pretending like mastery of our tools is unimportant? I hear this sort of opinion most eagerly expressed by engineers who in fact are quite handy with vim! Is this some new kind of flex where we're all pretending to take a purely academic approach to programming instead of becoming proficient with the tools of our trade?
I feel like at a certain point of efficiency there are diminishing returns. A good analogy is typing speed. You don't need to have 200 wpm to be productive. Everybody adapts to how efficient they need to be at what they do. Vim is not a requirement for being productive. If it was, it would be the most popular editor. I also don't think the person you are replying to is saying that it isn't important to "master" your tools. I think they are just saying the editor that you use isn't the most important thing and I agree with that sentiment.
You don't need to hit 200 wpm but I haven't seen too many programmers who hunt-and-pecks at the keyboard and can't touch type. Even on a Qwerty keyboard you should be able to get high double digits, if not hit/exceed 100 wpm. The two sites I like for practice are:
Typing fast for sport is fun, that I understand. But it's really weird (to me at least) how most developers say that measuring lines of code as a performance metric is an awful idea, and then there are others that more or less kinda shame people for not being good or great typists.
Am I crazy? Isn't it conflicting? Maybe those two groups don't overlap at all? Then do great typists believe measuring lines of code to be a good idea?
And being proficient at using your code editor doesn't require or exclude being fast at typing. Between the two I personally would chose mastery of vim/emacs or some other IDE over having a typing speed faster than 80 WPM. Sure, both would be great, but if I have to choose one I know which I prefer.
Full disclosure: I type on a QWERTY layout at an average of 65 WPM.
One thing I'd add is that some stuff like Home Row Mods, Caps Lock as ESC and enhancements like that seem to me like a larger productivity booster than the jump from 70 WPM to 100 WPM. But even so I might be wrong on that because I personally haven't experienced writing faster than 70 something WPM at my best.
Anyway, rant over and I apologize if I come off as rough. It's just something that's been nagging at the back of my mind and I still don't know how to properly put it into words.
Sure typing speed utility drops off pretty quickly but if it is a bit lower or makes just a part of your brain stop coding and think about more physical matters that should be in muscle memory then I think it has an effect on your ability to write a flow of code. (I saw this a great deal with regional keyboard layouts.)
Its hard to say if what you program will ultimately be better or worse as being used to micro interruptions can mean more diligence as much as they can mean forgetting an important caveat. But generally I think it means you are progressing at a slower rate toward an integrated group of skills.
For editors and IDEs it can be quite similar for refactoring, debugging and analysis of the code base. The worse you are at using them or the more indirect your proximity to the exact code base of the version you are working with, the more you rely on building/maintaining mental models which has its benefits and dangers.
I think its very hard to say anything is right or wrong. I do think that the question of where you expect to be in terms of needing each skill as your mastery of others grows is the question.
I don't see how they are related at all! Even the worst programmer can see that if we were to judge by LoC that they could add frivolous lines to juke the stats. LoC is stupid and I don't see how LoC is relevant to the conversation at hand. I do think that every programmer's had that stroke of inspiration where they can't type fast enough to get the code out of their head though
As far as typing speed, the difference between 10 wpm and 40 wpm is far greater than 70 wpm and 100 wpm. You don't have to hit 100 wpm to be a good programmer, but I have a hard time believing you can be one hunting and pecking at 10 wpm. (With exception made for the blind.)
> that measuring lines of code as a performance metric is an awful idea, and then there are others that more or less kinda shame people for not being good or great typists
I'm not on board with shaming people, nor do I think that lightning speed typing is needed. However, one I want to type my lines of code, no matter how few they might be, it's about translating thoughts into code as easily as possible. It helps not having to bother with the details of typing, but the typing more or less taking care of itself. Keeps the zone and the focus on the code, and not on the keys.
Touch typing seem like a useless skill to me. I use keyboard more for navigation than actual typing. I read many times more code than I write.
And when I write I just need to see the keyboard with the corner of my eye and my fingers just find the right keys as I'm pecking, purely through muscle memory that I've gained with zero effort just by years of experience.
I have to switch back and forth between french (azerty) and english (qwerty) many times a day. My typing speed has regressed. But I manage just fine without hitting 200 wpm. How does one practice the constant switiching?
He’s also looking at the keyboard, so maybe he’s unfamiliar with it. Perhaps when shooting the video they thought, hey, we need that cool clicky sound, and had him use a mechanical keyboard.
But in all, he types fast enough to write Linux.
Typing speed is important for typists. For programmers, I’d say that even a 50-80 wpm rate is adequate for getting your thoughts down on the file and off to the compiler.
VS Code with vim keybindings is extremely popular. If you don't know how to use vim, you just don't realize how much of a time/effort saver it is. I can't imagine not having wrist pain if I had to use the mouse every time I wanted to move my cursor around for more than a few characters/lines. Trying to not use vim feels like going back to the stone age whenever I can't use it. I like to use vim bindings even when I'm editing english.
I used vim for 5 years, afterwards I switched over to Emacs, and I couldn't disagree with you more. What's clumsy and slow is having to switch between insert mode, normal mode, and visual mode hundreds of times while working rather than just using modifier keys for special actions.
If you're entering normal mode for one or two commands at a time, that could be problem. However, if you're fast at entering normal (i.e. use jj, fd, Caps Lock as Esc, etc.), that's not a meaningful overhead.
On the other hand, having to constantly hold Control/Alt, including long chords (e.g. with prefix + count), feels much worse for me. I use Emacs keybinds on the terminal (outside of vim), but I can't imagine having to constantly press modifiers. It's not as comfortable as switching to a mode where those actions are explictly first-class.
i think what you're describing sounds a bit like visual mode which is just v
d and p for cut and paste if moving stuff around needs to be done (dd for whole line, 5dd for 5 lines, v and then j a few times in visual mode before d or y for yank (copy), etc...)
Note how you don't have to strain your pinky to hit ctrl for any of these?
I'm in two minds about this. Yes, wpm aren't everything (see the other discussion in this thread) and the same goes for the full range of your editor's functionality.
On the other hand, tools like Vim, Kakoune and Helix shouldn't be treated like your average Java IDE, for example, which shifts the line of what I'd say is reasonable learning investment. What you're dealing with there is a programming language for text manipulation. If you're fluid enough in it, you open your mind for solutions you'd never have considered before. I'd say you'd need at least intermediate Vim skills and should know macros until that effect kicks in.
I have quite some anecdotes about e.g. creating integration tests where my colleagues wouldn't test something properly just because doing so would involve 10 minutes of drudge work in their simplistic editors, instead opting for "deploy & pray" when the task was totally doable in a couple of seconds with a Vim macro. I find that at least in this regard (as for all programming languages), Benjamin Lee Whorf's quote certainly holds true: "Language shapes the way we think and determines what we can think about."
That's why I also think GP had a point. I would probably be much more in your line of thought if we were only talking about the usual contestants like refactoring snippets etc. here, although even having them handy will already influence how many of us work with our code.
Edit: As another analogy, I feel that modal editing has about the same effect on thinking as switching from roman numerals to arabic ones. The reason why it hasn't completely caught on is just that it's less intuitive and text manipulation is not as fundamentally important as calculations for our civilization.
> would involve 10 minutes of drudge work in their simplistic editors, instead opting for "deploy & pray" when the task was totally doable in a couple of seconds with a Vim macro.
I really very much doubt this. Sounds like an application of rose-tinted glasses and wishful thinking to some one-off task that then is extrapolated to all tasks.
Hey, I didn't say I do this every day. But I've had enough of these conversations that I can assure you that this low a bar is needed for some people to skip important jobs. If your doubt applies to the usefulness of knowing the system, I don't really know what to tell you -- if you can't take someone's word for it, I don't think anything less than you experiencing it yourself would convince you, anyway.
As for one-off tasks: Yes, that's what Vim bindings are good for. Just like AWK-Scripts are great for throw-away scripts. Being able to perform simple one-off tasks quickly is, incidentally, a skill I find to be far too rare even in programmers. I mean, I would've thought at least us techies see the benefit in knowing how to teach the computer to do the menial tasks for us.
> But I've had enough of these conversations that I can assure you that this low a bar is needed for some people to skip important jobs. If your doubt applies to the usefulness of knowing the system
No. My doubt extends to "omg vim is so amazing that these tedious tasks take seconds unlike in these primitive text editors".
Because my experience at work has been consistently the exact opposite: vim users routinely take longer time for most tasks precisely because it's a rather primitive text editor, and not a code assist tool.
Well, I'm not really sure if we're talking about the same thing. If you're talking about language integration, I've got no quarrel with that (see my earlier comment). The experiences I was referring to are more along the lines of text manipulation in general, not "rename class", "extract method" and the like. If you're talking about features like that, I'd readily agree with you: Trying to do the same thing with Vim macros is just picking the wrong tool for the job.
I won't beleive your assertion, however, that this invalidates the benefits of learning Vim bindings (especially since respective emulation layers are at least passable in pretty much any editor or IDE worth its salt).
If you're talking about normal minute-to-minute text handling and creation of text files without language assist (scripts, cucumber tests, any programming task not blessed by your IDE's refactoring integration) on the other hand, we're at the point where I have trouble believing you.
I get what you mean, but "minute-to-minute text handling" for me is pretty much always covered by my IDE's refactoring integration. Like, in the last few weeks, I've written a whole load of Python, Rust, and Typescript, where the IDE covers pretty much all my needs, and then maybe in total a day or so of fiddling with Dockerfiles and config files? None of which were really long enough or complicated enough that I needed anything complicated in terms of editing techniques, most of my time was spent waiting for builds to run and then trying something else out.
So yeah, you're probably right that Vim techniques are far better when you're editing those sorts of files, but those really do make up the tiniest fraction of my time, and everything else is covered by IDE refactoring tools. And if I had the choice, I would always rather have the better IDE tooling than the improved text editing, so this doesn't really sell me on the whole thing.
I would like to try Vim-mode for VSCode at some point, because I can imagine that being a kind of "best of both worlds" thing, but I've not really got round to it yet.
> If you're talking about language integration, I've got no quarrel with that
I am. Because we are talking about these mythical Java programmers who couldn't do something that Vim would have done in seconds
> I won't beleive your assertion, however, that this invalidates the benefits of learning Vim bindings
And the reason to learn them is because there's a fairy tale of some programmers not doing the job that we're led to believe could be solved in seconds in vim.
> If you're talking about normal minute-to-minute text handling and creation of text files
Are we? Let me remind you: "I have quite some anecdotes about e.g. creating integration tests where my colleagues wouldn't test something properly just because doing so would involve 10 minutes of drudge work in their simplistic editors, instead opting for "deploy & pray" when the task was totally doable in a couple of seconds with a Vim macro."
Oh look. We're literally talking about programming.
> we're at the point where I have trouble believing you.
Let's start with your fairy-tales before we come to believing or disbelieving what I wrote.
Ah, so we're arguing in bad faith. In this case, I won't try to keep some semblance of a useful discussion going. For your interest, most of our integration tests are written in a cucumber dialect and contain very verbose "business-y" messages passed in and out of the system under test.
But then, I'd guess from your tone that this won't stop you from misreading another comment of mine and accusing me of lying, so I'll just wish you a nice weekend instead.
I wrote a comment agreeing with your parent comment, but this probably applies to me:
> I hear this sort of opinion most eagerly expressed by engineers who in fact are quite handy with vim!
But to me, that makes me think that you should wonder whether there's something to that. For me, you're right, I did get really handy with vim at one point. After I had been using it to a very basic level for two or three years, I felt kind of sheepish and guilty and endeavored to learn it properly. So I bought into doing it "right" for awhile, wrote a bunch of custom script to customize it, the whole shebang. And my conclusion after that was that it wasn't really worth it. I went back to just using the basic stuff. This is also, importantly, supported in every IDE's keybindings, so I can use modal navigation and editing anywhere without needing to customize anything, which is pretty great.
It is not about only Vim as editor but Vim as keybindings too. Nowdays, most of all modern IDEs support Vim keybindings along well integrated IDE features.
This is true for tools in general but I've managed to master vim to the point I can be somewhat productive yet it never feels quite ergonomic. Moreover, I think vim-like UI is holding everyone back nowadays. Learning all the intricacies of vim feels like an exercise in brute-forcing a deliberately user-hostile design.
For example, is it really still OK to have little to no visual feedback when entering commands with range/count prefixes, or to have to fall back to custom commands and configs in order to search for strings containing "/"? Or have commands with tiny edit distance between them do radically different things (e.g. "w! " and "w !")?
Vim's modal editing implementation also can't handle non-Latin keyboard layouts so I find myself switching keyboard layouts all the time (e.g. normal mode->insert mode->layout switch->type some text->layout switch->normal mode).
It really isn't. I've spent a lot of time trying to tune langmap/keymap and looking into other options but the result is mostly unsatisfactory. Some of the issues: only translates the first letter of the command; doesn't support :commands; isn't expressive enough to remap punctuation.
Vim needs to be keyboard layout-aware in order to support non-Latin keyboards. It also needs to know whether the current input state is expecting text or a command (e.g. typing ":s/" from the normal mode should always be parsed using the Latin layout but the currently active input language should be used following the "/").
I’m definitely not going to try and endorse intentional incompetence.
I think it is just not so tricky in the first place. If you start out with “you can use hjkl for directions, and y for copy, d for delete, these can be combined with directions and prepended with numbers; remember the modes, and :w and :q” vim is already as good as most others editors. Then I’d just start using it, rather than trying to learn from the top.
My filter for when I should learn a new feature is when it solves a task I find repetitive and annoying (or I will make a post on Hackernews that says learning Vim is useless, to get a list of features that people actually use day to day). Since we all have different idiosyncrasies, this filter will be different from person to person, so I don’t really get the idea of a guide.
That said, I’m just describing what worked for me; if someone wants a guide they should go for it, we all learn differently after all.
> My filter for when I should learn a new feature is when it solves a task I find repetitive and annoying
There! You said it so well... that's the #0 reason why I go RTFM'ing, because most likely my problem fits a pattern someone already encountered and figured a solution for. Or nobody did and I put together a less annoying workflow to deal with it.
Sometimes the effort is worth it, but often it is just fun trying out new things/techniques.
If you're forced to work in the terminal, vim's great. But to get it to do something approximating an IDE, is it worth the time to tweak configs/plugins and memorize hotkeys, rather than just using a _real_ IDE?
Besides that, I just find the whole method of navigating (skipping words, skipping an X amount of lines) counterintuitive. It's nothing I can get used to, I will always miss the precision of just taking the mouse and getting the cursor exactly where I want it in one sweep and click.
> It's clearly more conducive to solving problems to be able to move around our environment more quickly.
Then vim ain't it.
My "vim-empowered" colleagues spend significantly more time trying to find symbols, related configs and tests, function definitions and interface implementations than I do. Because their hodge-podge collection of vim plugins and extensions rarely amounts to anything more than a full-text search across the whole project.
But sure, you can count the number of lines where you need to go and then the number of characters/words you need to move in the line and code it in 3 characters. By the time you've done that I've clicked there with the mouse, found the definitions and done project-wide refactoring.
Some people just like playing with tools. They do it for loads of reasons, but end of the day it’s basically a hobby tangentially related to software development.
I torment a friend of mine who talks all the time about VIM and their most recent config/workflow. But end of day, he’s happy and having fun while being productive.
In the past I was mostly the same, but then I realized that I was doing myself a disservice by not fully knowing my tools.
Every month or two I'd read a manpage for something and really experiment with using all the facilities - most of them wouldn't stick, but every now and again some would.
Just pick something like "less" or "bash", read the manpage, and try using something you've not done before. It's very helpful.
For Vim I went through the tutorial a few times a long time ago, and that really helps. (For twenty years I used emacs for "everything", and vim solely for email, via mutt and later my own client.)
Many years ago, decades actually, I used TextEdit + services shortcuts to filter text through grep, sed, awk. I found even syntax highlighting a distraction.
Then I saw someone using Vim. I was instantly hocked. The sheer speed of everything happening in the screen, I needed to learn that. And so I did and it’s been an amazing ride.
It’s a pain at the beginning, the amount of time I invested in my .vimrc will probably never payoff, mathematically speaking. But the joy and delight you get from using it everyday, the freedom and efficiency is just addictive.
It’s not for everyone, I was raised on the Mac paradigm, where “modes are evil”, so it was a step learning curve. But few programs have brought me this much joy and excitement over the years.
Bottleneck, yes but who cares. Your code or work won't be any better.
It just removes a lot of frustration, that's the thing for me. Working less on fiddling with text is focusing more on the conceptual level. Again, I'm not claiming the output is better, I'm just happier doing it.
You are right and wrong. I paired with a lot of juniors, and especially in the beginning stage of your career it is important to write as fast as your thoughts are. And in the same way, to be able to jump directly to the place where you want to change something. I belong to the Emacs tribe, and macros were really so impressive while doing my Masters for a lot of people, mass-changing classes definition through "programming" without really thinking. Still, mastery in macros impressed people and saved projects through really fast iterations, it's faster than Excel or Python. It's that a lot of times, you have a thought and want to execute on it, seeing the result immediately. What I don't like about Emacs and Vim is the lack of great debugger support. I would love a world where unit testing, functional data structures and static typing obliterate debugging, but we're not there yet. What I encountered is, that actually real mastery of tools made or broke projects. The 80/20 rule is not what I observed in reality. It is really long tails all the way.
I tried it. It's good for editing system configs on a Linux system through SSH. That's about it. A lot of people are trying to fit a square peg into a round hole. People also want to appear hip and cool, "hackery". Boring and well known is like oil to the average programmers water.
I love editing configs and fiddling around with a system over SSH with vim. Then, I have to do the main part of my job and put the changes into a YAML file for Ansible automation, which I do in VSCode :)
Yeah I think vim style modal editing is really useful, but honestly I get about 70% of the value from doing it "wrong"; using a fast key repeat and holding down hjkl, using visual mode a lot, etc.
It really doesn't need to be this mystical uber-hacker thing to be useful.
I do the same and agree, though I’m trying to push myself to be a little more sophisticated. The beauty of doing it that way is that it takes no thought.
I want to select from here to just after that letter P. With hjkl and visual mode I’m already halfway there. Whenever I try something clever I always find myself thinking “is that the end of a block? Or maybe I should cut directly to P but oh there’s another one on the line above so it’s the second, need to amend” etc etc etc.
Yeah I guess the next like 25% of the value I get from vim comes from "df(" and "ct)" type commands.
Also "dd" and "p" a lot to move lines around and "J" to consolidate them.
So maybe I do use a pretty large amount of functionality pretty frequently :)
I've been thinking maybe that other comment nailed it and most of us who downplay how useful it is to really learn vim have just already done that and forgotten that it was really useful.
> I find that no matter how slow I type, I need to spend more time thinking of what to type anyway
It true that thinking takes more time than typing/editing even you type slow and don't use any hotkeys for editing, but I have a feeling that the less time/effort I spent on typing/editing the less my thinking is interrupted.
With some practice one can use quite a few vim features relying on 'muscle memory' to spend less time/effort on editing and concentrate on what matters - thinking.
Though I no longer program, I am still a huge VIM enthusiast, but no it is not necessary to use VIM. I just love it because it made me more efficient, but at times I think that writing code really really fast might actually be a bug and not a feature.
For editing code it's amazing though. People looking over my shoulder used to think I was a wizard.
I similarly have mostly not learned vim, but every now (usually on fridays) I spend a bit of time seeing if there's an easier way to do something. My recent learning was :quickfix.
I normally build in a terminal anyways so this was a pretty nice little speedup for iterating on static analysis results or a build problem.
What vim can do that emacs often is a little too slow for and IDE:s can't is to have finished even quite complicated incisions and changes to your text before you've become conscious that you asked it to do the thing.
This means it can help keep out intrusions about editor maneuvering from your mind at work.
Some people see no value to this and fill their vim bundle with plugins that slow everything down a lot, but some of us really enjoy just surfing the high source and watching our thinking materialise on the screen seemingly effortlessly and immediately.
I use IntelliJ all day every day too, but it's mainly for admin and control stuff and certain types of refactors it can handle better. It's to my code editing as gitk is to my version control. It's where I run the tests, all the plugins, can get docs prerendered, things like that.
It's not where I can quickly navigate the code base, jumping immediately from file to file as fast as a fuzzy hint can get me, and then within the file as fast as Space+string can get me. You might have a keyboard layout with a forward slash easily available, mine doesn't so in normal mode space is /. Navigating in vim can be hjkl w b and so on, sure. But it can also be search. Just say the place and poof, you're there. It's wrong but very similar to where you want to go? n for next or try to name a new place.
This doesn't work in IntelliJ and it's a little off in emacs. I mean you can certainly technically do it but it's slow. There's waiting and the application twitches when it tries to imitate the vim way. Pretty much all finding tasks can be powered by fzf and ripgrep, and unlike IDE:s vim just does the thing when you tell it to. There's is no wait and then a dialog, there is none of 'ok, understand but Ide competent, knows many things, need more info before can do the thing' that tools like IntelliJ and Visual Studio do.
You also want jk to be Esc for sure. Esc is far away and CapsLock is for Control.
I agree with all except that Emacs is a bit too slow or a little off for these tasks. Emacs is rather easy to extend and modify to make exactly fit your task if you want to. Out of the box search is decent and very easy to make better than fzf. Ripgrep is cool and when used within Emacs you can also edit the search results and save them back to all files at once if you want to.
This issue is only cosmetic as the other commenter explained. vim won't insert the character until you indicate you're not invoking the keymap (either by waiting or by typing other characters).
If you want a plugin that makes it so that the j appears immediately regardless of whether you're trying to invoke the keymap or not, you can use something like https://github.com/nvim-zh/better-escape.vim
> remapping jk in insert mode results in lag after typing 'j'
It only creates lag if you actually want to type 'jk'. Otherwise, you keep typing like normal, and it doesn't matter. You should be able to config the delay, too. I use `fd`, and I can count the number I've noticed it.
I've re-built my neovim config like 3 times this year as I have played with several 'distributions' and styles. SpaceVim, LunarVim, AstroVim, and NVChad to name a few.
This last weekend I gave LazyVim a try and it is by far the most sane config setup I have used and I will now be sticking with it.
There is a starter repo where you clone it, delete the .git directory and start customizing.
Could you elaborate, why is LazyVim more sane? It too seems to require understanding a lot about their organization of configuration. (It doesn't help that I'm still not migrated from Vim to Neovim and lua, because I just didn't find a neovim configuration that was better than what I have.)
- Most distros seem to like wrapping functionality and having you use their own convenience functions to get things done. For example, for AstroVim, astrovim.<function> is all over their config files. This is fine if you were a distro developer and you were trying to make things easy for yourself but I do not find it easier for the user when neovim already has simple lua based functions. It is another barrier to entry as you have to learn how the distro authors put things together.
- The config for LazyVim is will thought out. For example, it has 2 directories: /config & /plugins. That makes it simple to figure out where things should go. keymaps go in keymaps.lua, options go in options.lua... it kind of makes sense.
- The plugin config for disabling a builtin plugin is the same as where you would configure your own plugins. It is literally:
return {
{ "github/myplugin.nvim", {config here if you want}},
}
- There are no weird plugin loaders and most examples you see from plugin authors are copy/paste into that bracket section.
- The LazyVim website is decent. Not perfect though. https://www.lazyvim.org/
- The starter is a great place to start your setup. https://github.com/LazyVim/starter
- The plugin manager, lazy.nvim, seems to be a lot simpler and well thought out compared to others plugin managers (like packer). It has autoloading, caching, a UI, etc.
- Folke, the distro creator, has written many popular plugins and knows quite a bit when it comes to configuring plugins. That seems to be paying off in the design.
To be fair, there are some design decisions that I don't agree with when it comes to the LazyVim layout itself. Putting everything in editor.lua or ui.lua instead of per-plugin config is not how I would have done it. It was pretty easy to figure out where the plugin settings were though because they match the categories on the website.
Note: I mainly switched to Neovim as I am find that there just seems to be much more development in the ecosystem and the number of amazing plugins coming out is staggering.
Thanks a lot. Maybe I'm starting to see what you are talking about. I have setup a working (?) lazyvim. Let's see where it goes. Some frustrations had to be overcome, most of them turning off unwanted functionality like autopairing parantheses, for example.. The custom notifications/popups also had to be disabled for now since they have some problems (cursor vanishes in light terminal? Important command outputs are only visible for a few seconds?).
Helix doesn't have tabs or folding, I find it really hard to use an editor without those features. The preconfigured LSP stuff is nice, but after you set it up in vim you usually don't have to mess with it unless you want too.
As with most engineering tools, I think using the word "better" is not necessarily correct. It's a matter of tradeoffs.
For me, I was fed up maintaining code to run my neovim setup the way I want, so I was looking for a configuration distribution or... something else.
Helix was the dead simplicity I was looking for. It has its own warts and drawbacks, but the tradeoffs are well worth it in my experience. I absolutely love Helix!
But if you want your editor to work exactly the way you want and having maximum flexibility is more important, you will not like Helix, which is extremely opinionated and has 95% of what you want in a modern text editor. The other 5% may be a deal breaker for you.
Not that I want to muck around with plugins all day, but having the ability to add a few helper plugins to ease certain tasks is a godsend in terminal editors.
Especially if you really dislike certain defaults packaged with the editor.
It's kind of weird to read about "learning" VIM, at least from someone who's been using it (er VI) for 40 years.
It's nuts, but if asked, I don't even know how to do certain things in VI; I just do them. Ask me what keys to press to go up, or down, or right or left? I dunno - I just do it. Yea it's nuts. It's like baby duckling bonding - the first editor mindset (aka EMACS vs VI) you use, you just bond to and it just is natural. Not better, just natural.
At the same time, I don't utilize it to its full strength. I probably do things that seem laborious to some, but no big deal to me.
My vim history is much like yours. I’ve tried to learn more about its features but unless they made their way into my daily workflow immediately, I just as easily forget them. Finally, I threw in the towel and decided I knew enough to get my work done and stopped.
Ha this is so true. I wrote in a comment elsewhere in this thread that I mostly just use the movement keys hjkl with a fast key repeat. But I'm still kind of wondering whether the movement keys are actually hjkl, because I'm writing this on my phone so I can't check whether those are actually the keys I use to move around, and I haven't actually thought about it in like a decade.
Same here. I remember vi commands as finger movements on the keyboard. Example formatting a block of text is !}fmt but I can't remember it except as a sequence of key presses. It was hard even to get the actual sequence of characters for this comment.
I don't think those are "bad" habits, to me it seems like you've already found your own way of using your editor.
You seem aware that there's an alternative way of doing the things you want, and seems like you've tried doing things the alternative way, but it "doesn't stick" with you.
You don't really have to start using the most absolutely 100% optimal way of achieving something in the least amount of keystrokes (unless that's actually your goal). As long as your editor doesn't get in the way, I consider it a win already.
So I don't think you're "losing" anything. If the alternative way really was something that actually benefited you, you'd have probably picked it up by now if you actually considered it better than your current habits.
For example:
> 1. instead of doing 4j I might do jjjj
> 2. if I'm in the middle of a word and want to change it, I'll do bcw instead if ciw
> 3. if I want to copy 3 lines, I'll do Shift-V+jjj+ESC, instead of just 3yy
If you want to copy all the body of a 100+ line function, I bet you probably do something like `Vi{Y` (or similar), even if it slows you down a little, because you know the slight pause is still better compared to mashing the `j` key 100 times.
Yes, you can probably do it like `yi{`, but the difference doesn't matter (especially once one of them is in muscle memory), and it's just preference.
Even something like `V50j50jjjj` for 103 lines (with the "50" being picked arbitrarily) is already a win.
1. is not bad, continuous visual feedback is awesome and more ergonomic that switching to a "counting" mental mode, especially for shorter distances (of which 4 is a part)
3. similarly, it's just a deficiency in vim that 3yy is invisible, so using a command that provides visual feedback is superior. Maybe try to fit a Shift-V to a non-modifier keybind, and depending on how ESC is convenient, a better exit would also be nice
A decade ago I decided that I should probably learn the idiomatic way to do things and went through different learn-to-vim tutorials but none of it ever stuck. I finally decided that the way I use vim is the way I use vim, and when I can’t figure out how to do something and can’t do it with another tool, I’ll learn a little more which may or may not be retained.
There’s a mountain of things vim can do and adding plugins on top of that makes it a never ending climb that I’m happy to climb as I need too.
That doesn’t really answer your question, except to say, me too, and that I’ve just let it go. (And vim is compete’s with a web browser as the program I spend the most time in).
I often use jjj and don't plan to change that. Forty years ago, when working on slow terminals, it may have made sense to optimize movement but not today. For small movements, I tend to spam keys. For larger jumps, I use an easy-motion like plugin such as Svart. Counting lines and words simply makes no sense to me for frequent operations.
You'll slow down, reason about your next best move, which slowly helps mastering those optimizations. Not only because they are shorter, but because sometimes they work, as opposed to visual selection etc.
An example: you might find doing jjjj easier when it's a one shot task, but for macros you mainly need "down to the end of the paragraph" (}) and so on.
Unconsciousness is not good at doing even simple math like counting, so habits like 4j or 3yy are hard to form.
It may even be counterproductive as non-trivial efforts to establish such habits will have cost. Less efforts will be spent on forming habits of spotting bugs in the code.
I suspect just by making sure that the cursor never leaves the middle of the screen may help better with habit formation than relative line numbers. This way, when one looks few lines below or above the middle it is easier to associate the distance to the center of the screen with numbers on the keyboard compared with distance to an arbitrary line in the screen. Plus relative line numbers will be perceived by the side vision which is rather poor in humans so they mostly help when one consciously looks into them.
But then the question should be what is the end goal here? Is it faster edits in Vim or is it to get job done?
I've got an Emacs plugin installed that's kinda like easy-motion, and actually have started to use that.. but I think I'll be sticking to eg. `hhjjjj` for the rest of my life.
I write a lot of Lisp, so I wonder of learning more structural editing commands (eg. something like `jump-to-sibling-sexp`) could help me map my intents more cleanly, but wouldnt be able to carry that into other languages and expect I'd fall right back into my old ways.
Maybe it just isn't so bad. When your findger is on a key, there's a lot of value in not moving at all. Counting is taxing and lacks feedback, which is why I hate resizing terminal panes. Maybe there's more power in learning and integrating new habits, like easy-motion or search-forward (even for short distances), than in eliminating old ones.
As an aside, the most jarring thing about going back to Vim from Emacs (which I do multiple times a day) is not having nornal-mode & co. in the mini-buffer / command-line. Love how emacs treats it as just another buffer, so even eg. visual-mode works in there.
I'm definitely not a vim master but I've made an active choice to avoid 4j style movement. The main benefit of vim, for me, is the mind-body connection. Commands are either muscle memory or like saying a short phrase in my head so it flows out naturally. Counting lines before executing breaks that natural flow
That could help and I have experimented with relative line numbers but have decided against it. I want to see absolute line numbers for matching up error messages and I find it's easier to communicate in absolute line numbers when doing code reviews or pair programming
I have a counterexample.
One member of our team tried to adopt Vim as a primary development tool for Python projects, while rest of the team used products of JetBrains. On the course of two months he tried to set up all linters, static analyzers and refactoring tools to keep up with the rest of the team, being the most unproductive developer all this time. When it became clear it won't be better, he was asked not to play cool hacker and use appropriate tools to solve the problem. End of story.
I've found learning vim--either as a plugin for IntelliJ or Chrome or Firefox or as a minor mode in Emacs or by itself--probably the most productive thing I've done on a computer. I spend all my time editing code. It's incredibly useful to learn how to do that quickly.
I went through trying to customise it perfectly but I found it is better--more portable for one thing--to learn its defaults. I enable a couple of things, like mkview and tabstop etc, but no more than 10 or 15 lines.
My only criticism relates to the fact it's an editor, not an IDE; there's vimscript and I've made various vimscripts to give it IDE-like functionality, but the plugin system, and plugin systems, or lack of a in-build one, let it down. And it doesn't seem, unlike emacs, that is was designed with extensibility in mind.
Great to see a vim tutorial that has buffers as one of the very first topics! In many vim tutorials you wade through hours of moving/editing ("This is how you delete a word.", "This is how you delete two words", ...) before you finally get to the most basic UI elements.
The author also quickly introduces helpful concepts like :h, .vimrc without going into too much detail up front.
From the first chapters this seems to be well structured according to what you need to know when learning not according to some natural structure of the topic as perceived by someone who is an expert already.
You might want to look into Neovim, many things are easier/friendlier to set up.
It’s likely also the better investment down the road, can’t imagine vim will be able to keep up with the speed Neovim is moving at.
Also rather disappointing decision in Vim 9 with regards to Vimscript vs something established e.g. Lua.
I can use vim, but I still find it easier to just open a file in nano and write.
I feel like I should be able to use a tool without thinking and without having to learn how the tool works, at least in regards to text editing.
And I feel that nano or pretty much any other editor except vim can be used the same way, just like a notepad on Windows or gedit or geany, you open a file and you start editing or you move to the desired location using the arrow keys or a mouse and start editing.
The very joke of "How to exit vim" feels like a good example of bad user experience and poorly developed tools.
Crude example:
Imagine if you couldn't drop a hammer and it was just stuck to your hand just because you didn't know that you had to type :q!.
But since I know how to use it at least the basics it is somewhat comforting knowing that pretty much any machine I'll touch will probably have vim pre-installed, so I don't have to spend time searching what is the name of the program to edit files. I have seen that some have an alias 'edit' to whichever is the default one, but thus far 'edit' hasn't worked on any of the machines I've tried.
Yes, vim can do a lot more then just edit files, but at the end of the day...
From the start of a Twitter subthread I wrote about the tutorial (thread unfortunately deleted later by accident - Twitter should have an undo feature like vim, heh):
[ Those new to vi / vim, hit the ground running with my short vi quickstart tutorial here:
I first wrote that tutorial at the request of a couple of Windows system admin friends of mine (at a company where I worked earlier), who were tasked with managing a few Unix boxes, without knowing Unix. They used the tutorial and later told me that it helped them to quickly start using vi to do their work on those boxes, including editing config files, simple shell scripts, etc.
Edit: Since vi is mostly a subset of vim, the tutorial works for vim too. ]
I can handle basic editing in vim and I have given real tries to use it as my main text editor but I just cannot find a way to get as comfortable in vim as I can in VS Code.
I don't really "get" using vim as an editor, but I love using vim bindings in vs-code. I've been using vim bindings for maybe a year now? Didn't really keep track of when I started. I definitely consider myself a novice, and maybe am using vim to 10% of it's potential, but the little bit I do use is nice.
On the other hand, I've never considered typing speed or editing speed the bottleneck in programming, it's usually debugging, solving problems, or reading files with 10k+ LOC and multi-hundred line files figuring out what they are doing.
I hated all the configuration stuff to get a usable vim ide. VS Code and its plugins Just Work™ for ide stuff with almost no setup so it was a lot easier for me to just use vs code with vim bindings than to get a good vim setup. Plus I can fall back on visual editing a lot easier this way if I forget some esoteric vim functionality and have to click through a menu.
I'd honestly point folks towards Helix[0] these days if they don't already have something keeping them on neovim/vim.
There's very little in the ways of needing to configure Helix; it has built-in most functionality that you'd find with batteries-included vim "distributions" and it works out of the box with the installed LSP servers on your system.
Helix itself looks amazing, but the keybindings make me stay away from it. Even if they are better than the original, I don't want to learn another set of "non-standard" keybindings that I need to switch between only to use an editor.
It's the opposite for me, the keybindings are the best feature IMO. It's like all the niggling little things that didn't make sense back when learning the Vim keybindings, have all been removed and replaced with things that make more of a coherent whole.
I can't use it yet because of the lack of addons/an ecosystem, but I hope to one day either move to helix or bring as much of this sensible keybindings system over to neovim as possible.
I've been using helix the last week or so. I can confirm everything "just works". My config file is not a turing-complete nightmare, it's literally 10 lines and took about 15 minutes to set up, most of that being personal preference on UI. Great program.
I've tried vim-as-IDE many times and personally I've found that I just don't have the patience/discipline to get it all set up and not have it become a huge time sink. I end up getting frustrated and start up VS code and what do you know, everything works absolutely perfectly with zero config. So why bother. New programming language? It literally pops up telling me what extension to install and < 5 seconds later it's working.
Installed helix, and nothing 'worked'. LSP wouldn't start, syntax highlighting didn't work, and once I did get them working, editing JSX caused strange issues where the autopair functionality created a duplicate of my code several lines above where I was working..
Not particularly impressed tbh.
It was very fast to start and use the fuzzy search though.
Personally I have one hell of a config, but since you’re fine with vscode defaults, the only thing I’ve really done to vim that counts was cloning ale into a specific vimfiles directory. What was your package set?
The selling point is that it's a solid editor with zero config I can use in the terminal for those "in between" tasks where it's not really worth pulling it up in an IDE but worth having some syntax highlighting and LSP support. Think like, I need to make a quick change to a python script in some far flung directory. In/out in less than a minute.
Just the fact that you're asking what my package set was is a turnoff for me. There shouldn't be a package set. It should just work. In VS Code when I need the editor to have additional features I just click the button, pick the extension with the highest number of installs, and 99% of the time it immediately does what I want. In vim you play this whole game where you google for it, gather opinions on the "best" plugin for that task, read the README, "just simply add these lines to your lua config", figure out why the keybind is conflicting with your existing keybind setup, etc etc. Goodbye afternoon!
I've tried lunarvim, astrovim, etc etc. Those work great! Until you actually do want to change something. Now you're back in config hell, and even worse, because you didn't even design this hell yourself, it's someone else's hell.
I agree with you, it would be nice to have a cloud profile, a plugin store, few other “windowing” features.
But by package set I literally mean it, e.g. mine is ale, nerdtree, snipmate, and the rest is cosmetic: scss syntax, tab guides and a couple of other syntaxes. Not some lunar/astro nvim-based heap of packages.
What I really miss in vscode and others, be it zeroconf or not, is editor programming features. E.g. I like to have sections in code that I can easily navigate. Something nmap ; /\/\/<Space>sec_<CR>$ does that. I also can create a popup with all of them + function names grepped from an unsaved source and navigate. Or highlight few more tokens. That is impossible in vscode unless you take a deep dive into its or its modules not very well documented internals. You can’t even write a module in .vscoderc, it must be formed into a package and [re]installed or get run in a special vscode mode. If the store doesn’t have what I want, I’m out of luck.
Things that failed (various degrees) for me: correct linewise indentation, readable sections on outline or minimap, non-syntactic folds, custom command mappings. Also the defaults are horrible, my last attempt was something like three pages of settings.json. Way too many afternoons, deleted my whole account to never try again. Tbf, my vimrc is also two pages long in the part that is related to settings. But at least the rest does what I want.
Correct. If you've got no background in vim, it might be a good thing Helix has broken "backwards compatibility" in order to have more cohesive key-bindings.
I think folks might be over-estimating the difference between the Helix and vim. IME, adding "ge" to Vimium[0] was good enough to avoid any conflicting muscle-memory. I think many folks configuring their vimrc are deviating equally as far or farther than the Helix defaults.
I'm not sure that I buy the purity argument -- almost all "vim modes" in other software are interpretations of the vim key-bindings and not an embeded vim/neovim engine. As a result, they all have their own caveats and folks using vim get used to functionality that exists exclusively in their vimrc. Often times vim mode just means supporting "hjkl".
Yes my problem with helix is when the keystrokes that are muscle memory in Vim don't have any actions in helix this makes it problematic to move to helix
over moving to neovim for example neovim retains most if not all the vi keystrokes not just out of respect to the vi authors
Setup how? I've used vi/vim daily as my main editor for the past 35 years or so, over that time I doubt I've put more than 20 total hours into its setup. I've been using some evolution of the same .vimrc for decades and it's only accumulated a couple dozen lines. The longest setup task I can remember was a few years ago getting MacVim to launch with one window per folder (with files as tabs, in most cases that equates to one window per repo, handy when I'm working across a couple different ones), but that was all shell work, not within vim itself.
Personally for me the setup only gets annoying when you want IDE-like features: text completion, treesitter syntax highlighting, go to definitions, ...
It's a tiny amount--I'm guessing I've probably easily logged 20,000 hours of active use in vi by this point, I can't think of any other tool I use regularly that has a better time-of-use/time-of-setup ratio. Compared to the time I've spent, say, installing Ruby gems and fixing dependency conflicts it's a rounding error, and Ruby's only been a focus for a small fraction of my career. To clarify that wasn't ever one 20 hour chunk, that's a rough guess at the total time spent setting it up on dozens of different computers across many different operating systems and window managers. It's typically well under an hour of setup per computer, and much of that time goes towards remembering where to find installers, picking fonts, etc.
I used to have crazy IDE-like setups but have realized that Vim is great for straight text manipulation (writing bash scripts, log parsing, etc) and VS code or eclipse is great for heavy duty programming. Now my vimrc is less than 50 lines and no plugins.
Never bet against a developer that has mastered vim. If vim is what they use on a daily basis, that’s not a developer you should fuck with. You’re dealing with a very dedicated individual. You don’t know what they’re capable of.
1) UI improvements like better syntax highlighting, split windows and tabs, and mouse support.
2) A cohesive language of key bindings that allows you to easily construct and perform commands like "delete everything from the cursor up to the next quotation mark" or "lower-case this paragraph".
3) A huge library of scripts and extensions to add or extend features like syntax highlighting and indentation rules for new languages, Git integration, or language server support (which provides IDE-style features like jump-to-definition, error/warning indications, and autocompletion)
Usually when nano is mentioned, it’s not a full development context, but instead e.g. crafting a systemd service file or editing crontab on a remote server. Do you really pull extensions and use mouse there? I think there’s nothing important that vim could add for gp, realistically.
Even without any plugins Vim has useful stuff you might need in a pinch.
Eg:
Column editing using visual mode.
Syntax highlighting
Tree-based undo features.
Fuzzy file finding in a project path.
Spell checking
Support for c tags
Line numbers
Mouse support
File navigation
On top of that you might want to learn vi for systems built with busybox.
Or tools that use readline like repls and sql clients.
You probably wouldn't install all your extensions on a remote server, correct, but you get the basics like syntax highlighting and mouse support by default nowadays. Even a minimal vim install is considerably more featureful than nano.
- Fuzzy file search - I can't find a way to do this in nano? Where you can search a whole directory by name for the file you want to open. This is very useful in larger projects when you need to jump about a lot.
- LSP and all its uses - jump to definition is a big one.
- Window management - while you can use a multiplexer, using one session allows copy/paste to work, saves your file/search/command history, etc.
- While often overstated, it is undeniably more efficient... once you've learnt it.
However, if you are not doing programming, but are just editing e.g. Linux config files, then I would probably stick to nano (in fact, I usually use nano for these jobs, since getting my neovim config to work when running as sudo failed).
> While often overstated, it is undeniably more efficient... once you've learnt it.
And on this note, I'd recommend not jumping in and trying to learn everything. Too easy to get overwhelmed.
Start with the bare basics and treat it like nano with syntax highlighting, then start learning and getting used to its broader functionality in small bursts.
Vim has a ton of features. I don't know much about nano, so I'm not sure, but there's a feature for most things in Vim.
I'll do a simple one then, as an example: In vim you can select a range of lines and indent or dedent those lines. With spaces or tabs as appropriate, set per filetype (or other ways of configuring). Can this be done in nano?
Its not that I wanted to use vim, but either it was the tool of choice for other people, or the tool of choice for other tools (like yay/paru on Arch linux (and yes I eventually learned default editors can be changed...)).
Kind of hard without knowing what you do and what your constraints are but at least for me vim is more widely available on the tools I use. I use neovim, but I also need to use Android studio and xcode sometimes, and there is a vim mode for each of those. So basically if you get used to it, it's a standard way to interact with several editors. Also it's just more fun and fluid to use for me but that's a matter of taste.
One thing I like about Vi vs other editors even for non full fledged development experiences like editing config files, is that Vi allows very surgical edits to change only what you want and nothing else.
You can easily control exactly what portion of the line or file you are making the edit to, and Vi will not allow you to change beyond that area without a further intentional command.
If by "only used" you really mean you never ever use anything else I don’t believe you are missing anything. Other than bragging rights of using Vim, of course /s
But if you occasionally use other editors, many of them have plugins or modes enabling Vim keybindings. In my daily work I switch between Emacs, IntelliJ, Vim and XCode, and all of them have varying degrees of Vim emulation, which makes switching a lot easier.
I have been using Vim for about 15 years now. I'm not really opinionated about Vim, Emacs, or any other IDE. There are many great tools out there. Also Vim emulators are really powerful in IDEs.
There's however one thing I don't hear very often: Vim is not a text editor with "powerful" features such as useful keybindings. It's more a language for editing text. As with programming languages your ability increases super-linearly as you learn to compose keys.
I generally prefer vim to vscode. But being able to jump to the file where highlighted functions/classes/etc are defined in vscode is very convenient and something I am not able to do in vim. I'm sure there's probably a vim plugin that can allow me to do this too but I just haven't spent the time to look for it.
I really want to use vim, but I can't because it's laggy whenever I try to use a premade setup like AstroNvim. I don't want to learn how to setup my vim enviroment. I want a VSCode-like experience in vim, out-of-the-box. I have used Helix for some time, but it has it's annoyances.
Does anybody have a good wysiwyg word processing approach using vim keybindings? Editing markdown docs as plaintext is not as good for writing prose as I would like, but editing documents without vim keybindings is also unpleasant for me.
Is the text editor really a bottleneck for anyone? I find that no matter how slow I type, I need to spend more time thinking of what to type anyway, if I’m doing anything interesting.