Of all the z’s my favorite by far is Ctrl-z, which send the current application to sleep and drops you back to the terminal, where you can do whatever you need before using ‘fg’ to return the slept process to the foreground.
It works with everything but I use it with vi most of all.
You can even sleep as many processes as you like and choose which one to return to the foreground as needed.
I have the following in my .zshrc that I'm sure I copied from somewhere. It allows the use of Ctrl-z to also resume programs runnings in the background instead of manually typing fg.
# Allow Ctrl-z to toggle between suspend and resume
function Resume {
fg
zle push-input
BUFFER=""
zle accept-line
}
zle -N Resume
bindkey "^Z" Resume
No. When a program is running in the shell, the default behavior is for Ctrl-z to suspend the program. Nothing needs to be done for that to happen. This snippet runs `fg` when you're back in the shell and press Ctrl-z.
That said, if you wanted to continue running in the background with `bg`, you could make that substitution to allow you to double tap Ctrl-z to do so.
Oh wow I totally misunderstood this snippet; I thought it was in fact the opposite (i.e. a shortcut to send a job to the background). Toggling back to the foreground is even better with the same shortcut! Neat!
I almost never suspend vim, because I run it exclusively inside tmux, and it's a lot easier to just open a new window/pane, run something, and close it when done.
If you need to run tmux in git bash, this worked for me:
1. Installs msys2 (which includes pacman package manager) # can be done separately from your git installation
2. pacman -S tmux # install tmux to msys2 within msys2
3. Copy tmux.exe and msys-event-2-1-7*.dll from msys2 to C:\Program Files\Git\usr\bin # may be a different version msys-event
4. Uninstall msys2! This was important to me because I found edge cases where msys2 did not honor directory links as "not msys files" and it borked things. YMMV
Nvim also has a new --listen flag (if you ever tried nvr this is now built in). So no matter where you are the file will open in your main nvim instance.
If you're using zsh with plugins, then your shell startup time is already high. Ctrl+z drops you back to an existing shell, but toggleterm spawns a new shell which can be annoying.
It's also a footgun for new terminal users, hehe. Wan't to undo something, instead you think you've suddenly nuked your program and lost all progress. So start a new one instead.
Or whatever the key shortcut is that puts gnome-terminal in "read only" mode, that I kept doing by accident for years, before I found out how to undo it (right-click, toggle "read only"), thinking it was an obscure gnome-terminal bug.
Except when you forget all about this ancient single-tasking terminal convenience, and accidentally enter ctrl-z, and can't remember how to get back again (nope, not ctrl-d).
The real issue is when you do ctrl-z from muscle memory on Windows while running nvim from cmd (through wsl runner but not from an actual shell) and then it just disappears and takes your data with it.
I use ":sh" for this purpose, but it has the problems that:
- you get a new shell, so your history is lost
- if you have a "stack" of vim's you have to return to them in stack order
- I develop a habit of typing Ctrl-d when I want to get back to vim, which means I accidentally log out of SSH sessions all the time if I actually haven't still got vim open
I think getting in the habit of using Ctrl-z instead would be a big improvement.
Yes, these are good points but I've found the benefit outweighs the annoyance. fzf for a history searcher really helps. BUT not being able to 'up arrow' the previous command is annoying at times.
So far it's a 6/10 Slightly better then not doing it.
=)
Heh, don’t get me started. I personally rarely used ^Z, I simply banged out.
However shelling out was intrinsic to my workflow. We didn’t have screen or any of the other common multi session terminal programs at the time.
One day I decided to log out. I rarely logged out. If anything I was kicked off by a system restart.
So to log out I started closing sessions. Turns out I was at least 30 deep. Some files were being edited more than once, I even had shells within shells (which typically did to play ENV shenanigans).
It’s not a trivial thing to support though. ‘jobs’, ‘bg’ and ‘fg’ need to be shell builtins. Other shell builtins might not work if they’re not POSIX fork()s and you need to handle STDIN a little more carefully.
It’s a lot of work for a feature that many alt shell users might not even be aware of.
Huh, I wouldn't have been able to say what zz does from memory despite using it all the time. I think this is because I am on my phone, away from a keyboard and it's the sort of motion where I don't ever even think about what key I'm hitting, I just do it. I'd need to be at a keyboard to access my muscle memory.
I had the exact same experience, but if I pictured pressing them in my mind's eye, I realized what they did.
It reminds me of some bilingual kids I know that can understand their dad's language perfectly, but they have a really hard time speaking it (since they always reply in their mom's language). You only learn what you practice.
I was thinking about writing down some visual keybindings map precisely for that reason, I have gathered a bunch of muscle memory about shortcuts I set up but it would take a bit of effort to remember what one was if I didn't use it for a while
I'd recommend against trying to memorize Vim keybindings by position.
1. If you want to learn a non-QWERTY layout (e.g. Dvorak or Colemak), you're going to have trouble. (Although some users to try and go to the effort of remapping to suit the layout).
2. Similarly, you might also have trouble if you get a fancy keyboard that doesn't use a row-stagger, like a kinesis, moonlander, crkbd etc.
3. Many of vim's keybindings accreted mnemonically in the first place. There's often a mnemonic explanation or back-explanation for every single keybind. Many people communicate with them ("just yank those four lines"), and they form a sort of vocabulary to the "language" of vim normal and visual modes.
I really wish the article would give easy to remember explanations. E.g. it mentions :wq means "exit after saving". Explaining :wq as "write and quit" makes it a lot easier for new vim users to remember.
But that only goes so far. Some of the key combination do have a nice mneumonic attached to it. But it definetly can't scale. ZZ is one of those, which is the case with most key combinations :/
My experience someone somewhere generally has a mnemonic for even the weirdest vim key combinations. Even ZZ probably has a mnemonic at least one person uses. Mnemonics sometimes have a lot of brains to scale on.
Gah. I never used ZZ, despite using zz all the time, so I went to my editor and started hammering the Z key and ended up closing most of my files.
Well played. This is a nice way to check whether you read the article first or last.
What's up with thirty different ways to exit vim? ZZ, :q, :wq, :x, good lord! Vim must be the most effective editor as long as you want to not use it. :)
It really should use two hands since z is a left pinky key (on qwerty, colemak, workman, qgmlwb) and left shift as well (so you should use right shift with it), but I'm aware many people don't use their right shift key. I only learned to a few years ago when relearning to type anyway.
:wq is still :q, just saving before exiting. The flavors are just different ways to deal with changes, with ZZ (:x) and ZQ (:q!) being aliases to the most useful ones.
This is not unique to vim, other editors handle it with prompts and buttons.
I use zz a lot, I also like C-d and C-u which scroll the document up and down without moving the cursor. I've mapped these to C-j and C-k to make them easier to use:
" Center screen on next/previous selection.
nmap n /<CR>zz
nmap N ?<CR>zz
" Last and next jump should center too.
nnoremap <C-o> <C-o>zz
nnoremap <C-i> <C-i>zz
The source you copied this from offers a simpler version:
" Center screen on next/previous selection.
nnoremap n nzz
nnoremap N Nzz
" Last and next jump should center too.
nnoremap <C-o> <C-o>zz
nnoremap <C-i> <C-i>zz
I use zz regularly, especially when taking notes, which tend to move the cursor towards the bottom of whatever you're using to write in. This is bad for your posture, so a regular 'zz' helps to keep my neck from straining. Another nice thing about vim is that it will scroll beyond where there is text. Once you have more than a screen of text in almost any text editor or word processor, it is often hard to get the bottom of the file to the top of the screen.
It takes the minority of users like me who visit https://news.ycombinator.com/newest often and upvote new stories that look interesting. If it gets 4-5 votes early (like within 30-45 minutes), it usually makes it to the front page.
I almost never use zz. I prefer setting scrolloff to a fairly high number like 50.
Scrolloff short for scroll offset is the number of lines vim ensures between the cursor and the modeline, as well as between the cursor and the top of the screen.
Super useful for always keeping a good amount of context visible. You can even set it so high the cursor is always centered.
The previous post about ':x' was posted by the author of the article in the OP. I suspect the author of the article using multiple HN accounts to shill this.
There are a lot of us dinos out there who haven't even used hjkl to navigate. All I do is yy, dd, p, ctrl-v to rectangle select, shift-v to line select, g or G to navigate c and the occasional s/^/#
And it's a perfectly fine way to use vi or vim as a basic editor present on every POSIX system.
Yet, as a long time user, I regret that beginners are often presented with a list of commandes to memorize and are never introduced to what makes vim actually nice: composing scopes and actions.
I have the same issue with the s command. Most people treat the parameters as something slightly magical to be googled when needed. Meanwhile, reading the ed manual was eyes-opening for me. It really helped me understand both where vim comes from and what sed does.
These movement keys are at least 40% the reason I love and use vim or vim plugins. Not having to move my hand, and being able to “drive” with only one hand are immensely beneficial.
With cursor keys, it feels like half of my editing time is spent finding the arrow keys and then finding the home typing position.
Emacs ctrl n/p/f/b are better than cursor keys often, but they require two hands.
C-f, C-e, C-b, C-a only require one hand. But I see your point.
The best part of evil-mode in Emacs is that I get to use Emacs bindings in insert mode, and then vim keys in normal mode. For instance when writing function signatures, I can hit C-f to easily jump over the closing parenthesis, or C-e to easily jump to the end of line, usually also to skip the closing parenthesis. I'm not sure how you would do that in vim without exiting back into normal mode and using for instance S-a to append at the end of the line.
I'm a long-term emacs user who recently learned vim for fun. Deciding when to exit insert mode has been part of the learning curve.
From insert mode, vim lets you run one command without explicitly switching back to normal mode. :he i_ctrl-o for details. It's very handy for positioning the cursor for more input, for example ctrl-o f)
Here's a vim pain point: a lot of commands should be case insensitive
Because it is deeply frustrating when Vim complains about :Wq "not existing" well, duh. A lot of people remap those to lower case so that Wq works (also Q!, etc)
You might know it, but all of vim's built-in commands start with lowercase letters, but it's impossible for users to define new commands starting with lowercase letters. Kind of a namespacing I guess.
I'm a native Portuguese speaker. ZZ makes a nice pun in our language: "Zalva e Zai", from the words "salva" (save) and "sai" (exit). It might work for Spanish too.
`ZZ` is great when you want to save. If you're looking at a read-only file, or just want to quit a file without unsaved changes, I personally prefer `Ctrl-w q`. I do a lot of windowing in Vim (controlled with `Ctrl-w`), and if you follow that with `q` (and you're on the last window of the session), it will quit Vim. I have Ctrl mapped to Caps Lock, so I can do this quite quickly.
> Do you waste a lot of time trying to bring the current line of code to the center, going all the way down and then all the way up to reposition the editor’s viewport? Well, I used to do that too…
I can empathize with the parent comment and understand why basic commands about Vim can be bothering them. Many of us (and perhaps the parent commenter is one of them too) come to HN to look for interesting news and articles. Something interesting that has happened in the tech world. Or some interesting knowledge about the technology tools we work with or the real life world we live in.
It so happens that rehashing of Vim's documentation on basic commands does not make it interesting enough. When articles on these basic commands (that are easily and better learnt from Vim :help) come on HN again and again, it can lead to a boring reading experience. It stops being interesting. For some people, this can reduce the real value of HN.
I'll confess that my comment may appear as elitist. But hey, at least I am being honest, from my high-horse, elitism and all. If you can get past the thorny issue of elitism, perhaps you can see my point. My point is that I appreciate why these articles appearing too often can be bothering to some. I hope you can appreciate it too.
That's not to say that there is anything wrong with these posts. If the community likes it and upvotes it enough, so be it. There is a "hide" link to hide the story if it is really bothering someone. A few basic Vim articles every week is not really a big problem even if it ends up bothering some people. I can live with it and I hope the parent commenter can live with it too.
It works with everything but I use it with vi most of all.
You can even sleep as many processes as you like and choose which one to return to the foreground as needed.