When I get comfortable and productive with a tool I often stop learning new parts of it. Like in the past year I’ve forced myself to start using ^W to delete to the start of a word when editing command-lines in the shell. I’ve been using a UNIX shell all day every day since the mid 1990s.
Pamela Fox demonstrates in this rare display of developer humility that one needn’t be a power user of their editor to get stuff done. I appreciate that, especially in contrast to the evasions of past guests who can’t seem to admit that they actually have any practices that they would personally cop to being bad.
Setting that aside, though, I’m trying to understand the advantage of (neo)vi(m) keybindings over the conventions of GUI text editing contexts. For example, on a Mac, command+arrow takes you to the beginning or end of a line (horizontally) or document (vertically). Option lets you move by word. Doing any of that and adding the shift key selects text. IIRC, Windows has similar equivalents. Combine those keyboard conventions with the command palette and multiple-select patterns popularized by Sublime Text and you have a pretty efficient workflow with a much shallower learning curve. I can imagine if a good portion of your day is spent in an environment without a GUI, it would make sense to get pretty good at vim or emacs, but I would genuinely like to know, what is the case for GUI users to learn vim deeply?
I’m sure there’s no particularly good argument in favor of it, and I no longer actually recommend it to anyone, but having typed vimtutor one day 18 years ago, I’m too far gone to learn anything else. If you go through vimtutor and that’s not the path your life takes you’ll probably end up happier and better-adjusted than I am.
I was a GUI user, but switched to vim(likes) for accessibility reasons.
So for me it’s not about what I can do, but how. I can do everything in my entire setup and never have to press more than one key per hand at a time, and rarely have to hold a modifier key at all.
My editor, web browser, window manager, email client, etc etc all work like that.
But yeah, I would never really recommend any of this to anyone who doesn’t need it.
Another vote for accessibility here. I have cerebral palsy and was developing wrist pain when using modifier keys. I switched to a vim layout and made extensive customisations to eliminate the need for modifier keys. This is purely anecdotal, but the problems have not recurred since I made these changes.
I really need to do a full post on this, but some of the specific vim motions i miss in vscode:
vi{char} selects everything inside a quote/parenthesis/curly braces/sentence.
"Ayappends your selection to the a copy-register, which makes it easy to go through and collect a bunch of different little things to paste all at once
zf lets you create new ad hoc folds over arbitray parts of the file
ctrl-A jumps to the next number on the line and increments it
guu lowercases the entire line
Each one is those is only a small boost to my productivity, but when I have 200 small boosts it adds up. That said, I avoid vim emulation in other editors. It’s easier for me to switch between two sets of muscle memory if they’re very different.
I’d love to read it. You have a great blog. Based on this summary alone, I’m not sure how or if I would use these features, but perhaps if I could see how you use them, in other words, in what context, that would be very interesting.
Have you tried reporting those? I got some vi behaviours fixed that way. vi(char) may be easy to add since I remember using di(char) and that worked fine.
Option lets you move by word. Doing any of that and adding the shift key selects text.
Vim lets you use ctrl+arrow to jump by words as well. Useful in insert mode when you do not want to go back to the command mode for some reason. People should be able to discover that just by muscle memory, so it’s somewhat awkward that she did not stumble upon it. Yikes.
Vim’s [v]isual mode lets you move around your cursor to prepare a selection (instead of holding shift all the time) and then [d]elete it, [y]ank to [p]aste elsewhere. Among other possibilities. She would probably like it, since you can e.g. search using slash to locate where you want to place the end of the selection.
Or on a one uses Pos 1, End, Ctrl, etc. when hot on an Apple device.
I think they are just good, proper Editors of which there aaactually see rest few, GUI or not. They’re usually slow, resource hungry, inflexible, hard to impossible to configure, lack features one wants or just have but been designed well. Sometimes they suffer from instability, as in new versions (minor or major) breaking things.
That’s a general theme with software. It also applies to editors of course and when you have something reliable then you stick with it. For many people that’s something like vim or emacs.
It’s often the first editor that’s “good enough”. And if you are at any time SSH into something chances are you get to learn vim or nvi in the end. Even if nowadays some systems have other defaults. They tend to not be really great.
And once you know it you end up using it locally now and then, then it becomes a habit.
I think it’s easy to overestimate how much choice there is when you have a few requirements for editors.
This is hilarious and so frustrating at the same time.
I only know a few basic vim commands (h.j,k,l, yy, x, dd, /, gg, G, b, e, %, v, V, :s, :bnext, :bprev, ==, *, n, N, $ ,^, :, :w, :q, :q! etc). Watching Pamela makes me think… how much easier would my life be if I learned another dozen?
Here’s the strategy I used when switching from Emacs to Vim:
Look up all the letters and symbols in Vim and what they do. Categorize then and write them all down on a piece of paper (it just has to be enough detail for you to remember). Then keep the piece of paper next to you as you edit, and refer to it whenever you’re trying to do something that feels clunky with the commands you know.
I was very surprised how effective this was. After a week I was as fast at editing in Vim as Emacs (after a decade of Emacs use; this is mostly Emac’s fault), and after two weeks I was pretty fluent in Vim.
So, this is funny, but I’ve found myself using both the Godot and Tic-80 built in text editors for a lot of things, and only missing Vim keybinds at the extremes.
I realise that it’s not related to tic-80 but you reminded me…
I played a bit of TIS-100 on Steam recently where you program a series of extremely limited pseudo assemblers. I found the built-in editor to be so frustratingly not-vim that I played the game by finding the save files on my file system and editing them directly in vim, then reloading the game in Steam to run them.
vi was the first text editor I used learning C in college (before that I guess I had written Basic in EDIT.COM in DOS). And I have never completely stopped using it, even though I switched to Emacs full time within a year of starting with vi. But I also never learned anything more than what you see in this video.
I can definitely relate to this, I use vi/vim for all my development (Security Ops / Engineer person here) but I am also bad at using multiple files so I usually just use tmux to open a few different panes with files. I think it’s time I revisited vimtutor again…
I was trying to think what my own worst practice is, then I realized that rather than figuring out how to mock Kafka and FTP, I had the CI build 15 docker images, updated a docker compose file and restarted a container just to fix simple errors/typos.
It took me trying to reimplement vi based on the posix spec (https://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html) to learn how to use it powerfully, and mostly I don’t.
When I get comfortable and productive with a tool I often stop learning new parts of it. Like in the past year I’ve forced myself to start using ^W to delete to the start of a word when editing command-lines in the shell. I’ve been using a UNIX shell all day every day since the mid 1990s.
“Any feature I cannot immediately remember does not exist.”
Pamela Fox demonstrates in this rare display of developer humility that one needn’t be a power user of their editor to get stuff done. I appreciate that, especially in contrast to the evasions of past guests who can’t seem to admit that they actually have any practices that they would personally cop to being bad.
Setting that aside, though, I’m trying to understand the advantage of (neo)vi(m) keybindings over the conventions of GUI text editing contexts. For example, on a Mac, command+arrow takes you to the beginning or end of a line (horizontally) or document (vertically). Option lets you move by word. Doing any of that and adding the shift key selects text. IIRC, Windows has similar equivalents. Combine those keyboard conventions with the command palette and multiple-select patterns popularized by Sublime Text and you have a pretty efficient workflow with a much shallower learning curve. I can imagine if a good portion of your day is spent in an environment without a GUI, it would make sense to get pretty good at vim or emacs, but I would genuinely like to know, what is the case for GUI users to learn vim deeply?
I’m sure there’s no particularly good argument in favor of it, and I no longer actually recommend it to anyone, but having typed
vimtutorone day 18 years ago, I’m too far gone to learn anything else. If you go throughvimtutorand that’s not the path your life takes you’ll probably end up happier and better-adjusted than I am.I was a GUI user, but switched to vim(likes) for accessibility reasons.
So for me it’s not about what I can do, but how. I can do everything in my entire setup and never have to press more than one key per hand at a time, and rarely have to hold a modifier key at all.
My editor, web browser, window manager, email client, etc etc all work like that.
But yeah, I would never really recommend any of this to anyone who doesn’t need it.
I think I can relate to that. Started using touch input and key-navigation because I had to reduce the wrist pain from using a mouse.
Another vote for accessibility here. I have cerebral palsy and was developing wrist pain when using modifier keys. I switched to a vim layout and made extensive customisations to eliminate the need for modifier keys. This is purely anecdotal, but the problems have not recurred since I made these changes.
I really need to do a full post on this, but some of the specific vim motions i miss in vscode:
vi{char}selects everything inside a quote/parenthesis/curly braces/sentence."Ayappends your selection to theacopy-register, which makes it easy to go through and collect a bunch of different little things to paste all at oncezflets you create new ad hoc folds over arbitray parts of the fileguulowercases the entire lineEach one is those is only a small boost to my productivity, but when I have 200 small boosts it adds up. That said, I avoid vim emulation in other editors. It’s easier for me to switch between two sets of muscle memory if they’re very different.
I’d love to read it. You have a great blog. Based on this summary alone, I’m not sure how or if I would use these features, but perhaps if I could see how you use them, in other words, in what context, that would be very interesting.
Have you tried reporting those? I got some vi behaviours fixed that way. vi(char) may be easy to add since I remember using di(char) and that worked fine.
Vim lets you use ctrl+arrow to jump by words as well. Useful in insert mode when you do not want to go back to the command mode for some reason. People should be able to discover that just by muscle memory, so it’s somewhat awkward that she did not stumble upon it. Yikes.
Vim’s [v]isual mode lets you move around your cursor to prepare a selection (instead of holding shift all the time) and then [d]elete it, [y]ank to [p]aste elsewhere. Among other possibilities. She would probably like it, since you can e.g. search using slash to locate where you want to place the end of the selection.
Or on a one uses Pos 1, End, Ctrl, etc. when hot on an Apple device.
I think they are just good, proper Editors of which there aaactually see rest few, GUI or not. They’re usually slow, resource hungry, inflexible, hard to impossible to configure, lack features one wants or just have but been designed well. Sometimes they suffer from instability, as in new versions (minor or major) breaking things.
That’s a general theme with software. It also applies to editors of course and when you have something reliable then you stick with it. For many people that’s something like vim or emacs.
It’s often the first editor that’s “good enough”. And if you are at any time SSH into something chances are you get to learn vim or nvi in the end. Even if nowadays some systems have other defaults. They tend to not be really great.
And once you know it you end up using it locally now and then, then it becomes a habit.
I think it’s easy to overestimate how much choice there is when you have a few requirements for editors.
Was screaming the whole time “Hit the b key, it’ll make your life so much better!”
Also vimtutor.
As someone who just made the switch to NeoVim and the whole ecosystem it was still painful to watch! You gotta learn your tools…
And vim adventures!
This is hilarious and so frustrating at the same time.
I only know a few basic vim commands (h.j,k,l, yy, x, dd, /, gg, G, b, e, %, v, V, :s, :bnext, :bprev, ==, *, n, N, $ ,^, :, :w, :q, :q! etc). Watching Pamela makes me think… how much easier would my life be if I learned another dozen?
Here’s the strategy I used when switching from Emacs to Vim:
Look up all the letters and symbols in Vim and what they do. Categorize then and write them all down on a piece of paper (it just has to be enough detail for you to remember). Then keep the piece of paper next to you as you edit, and refer to it whenever you’re trying to do something that feels clunky with the commands you know.
I was very surprised how effective this was. After a week I was as fast at editing in Vim as Emacs (after a decade of Emacs use; this is mostly Emac’s fault), and after two weeks I was pretty fluent in Vim.
Really enjoying these videos. Keep it up!
Thank you!
Hi all! Here’s this week’s episode of my new YouTube channel “Worst Practices in Software Development”. Thanks for watching!
So, this is funny, but I’ve found myself using both the Godot and Tic-80 built in text editors for a lot of things, and only missing Vim keybinds at the extremes.
I realise that it’s not related to tic-80 but you reminded me…
I played a bit of TIS-100 on Steam recently where you program a series of extremely limited pseudo assemblers. I found the built-in editor to be so frustratingly not-vim that I played the game by finding the save files on my file system and editing them directly in vim, then reloading the game in Steam to run them.
vi was the first text editor I used learning C in college (before that I guess I had written Basic in EDIT.COM in DOS). And I have never completely stopped using it, even though I switched to Emacs full time within a year of starting with vi. But I also never learned anything more than what you see in this video.
I can definitely relate to this, I use vi/vim for all my development (Security Ops / Engineer person here) but I am also bad at using multiple files so I usually just use tmux to open a few different panes with files. I think it’s time I revisited vimtutor again…
I was trying to think what my own worst practice is, then I realized that rather than figuring out how to mock Kafka and FTP, I had the CI build 15 docker images, updated a docker compose file and restarted a container just to fix simple errors/typos.