Tell HN: Vim users, `:x` is like `:wq` but writes only when changes are made
`:x` leaves the modification time of files untouched if nothing was changed.
:help :x
Like ":wq", but write only when changes have been made.
278 comments
[ 3.0 ms ] story [ 288 ms ] threadMy life just began again. Thank you
As in "escape-q-dammit"
I just remap Caps Lock to Esc system wise (a setting in both Linuxes and MacOs) and use both shift for Caps Lock (setting on Linux, Idk about MacOS)
I have always found the "jk" solution quite elegant although I don't use it
The benefit of using it system wise is that it then works with all programs that have a vi mode (zsh, gdbtui, etc.)
https://news.ycombinator.com/item?id=34168031
Edit: apparently ^C also ignores abbreviations. :ab lhs rhs, then ilhs^[ writes rhs, but ilhs^C writes lhs.
Shift + ZZ -> :x (save only if needed and quit)
Shift + ZQ -> :q! (quit without saving)
And actual advantage here is that `ZZ` can be your "quietly quit anything" key. It'll close quickfix, locationlist, previewwindow, etc without complaining.
Compare vim or its clones with any KDE application, which always has keybindings shown in menus, and always a complete list of rebindable keybindings in the settings menu.
https://vimdoc.sourceforge.net/htmldoc/usr_02.html#02.7
To exit, use the "ZZ" command. This command writes the file and exits.
I remember reading about it 17 years ago in this manual. Tbf, it could have been in another section back then, but that is no excuse for seeking some “easy” tutorials instead of R-ing the TFM. There must be a name for this syndrome when people look for documentation and learning materials in anywhere but the documentation and the learning materials.
A possible correct solution is already given as an example in my previous post.
Granted, it would be nice to see more apps using the solution you described. But personally I don’t find a list of commands in a table that much different from a list of commands in a text wrt discoverability.
Another nuance discussed here https://news.ycombinator.com/item?id=34287407#34293277
Shift + ZA -> :up (save only if needed without quitting.)
by adding to your .vimrc:
That’s a real “geez, our keymap is almost exhausted!” keybind.
Nevertheless there are such thing as adding a confirmation message in case of a dangerous operation (and, if necessary, and option to disable such warnings). For example, C compilers usually have warnings, and you can disable any warnings that you do not want.
So most people do :wq so that it saves and then quit or do :q! to quit without saving changes. Most people stop using :q.
This also appears to only write when changes have been made (according to some testing in neovim on my local machine).
That's insane. What if you need to type the following words in all caps?
The last would make that command from normal mode particularly annoying. Unless you meant when not in input mode... duh.> This command is not supported in Vim9 script, because it is too easily confused with a variable name.
So you can’t just write “x”, but must instead go for something bland like “exit”, or something exciting like “exe'x'”. (I’m presuming “execute 'x'” will work, but my mental model of how you’d unsupport the command in Vim9 script could be wrong.)
`:x` is one of only like 8 commands I know!
I'm surprised that it's apparently not one of the basic commands everyone knows?
What most didn't know (myself included) is that the behavior is slightly different from wq.
https://news.ycombinator.com/item?id=34288446
\s
Been using :x from the start about 4 years ago and I never accidentally encrypted a file.
https://www.programmerhat.com/vim-zz/
Blame my hand geometry or the keyboard or muscle memory or 10,000 other things, I just noted it was super hard and unnatural for me to type that. (The downvoting on that is pretty epic, though.)
I only knew about :x. So thus far I’ve only edited with :x, and then used :q! to quit without writing the changes.
After that, I switched to `:wq` (and sometimes `:w` `:q`) which is much safer against over-typing.
Even worse for me, because my laptop keyboard has some kind of horrible encoding causing latency on the shift key, so I'm constantly doing :Wq when I type fast enough... Yeah I had the suspicion it was human error - but I've tested using a single finger for shift and w, so it's definitely the keyboard.
[edit]
Looks like that feature is not necessarily built in by default though.
The advantage of `ZZ` is that it can be used as a general "close this window" command. It'll work on unmodifiable buffers as well without complaining.
ZZ is just.. random?
I also think the bikeshed should be lime green :)
I'm toying with either disabling it,
or, mapping it down to a lower x. 1. Does anyone see anything this could interfere with?2. Does anyone know a better way to turn off the `:X` encryption option?
Sadly, having to remap definitely dulls the shine of `:x`.
Otherwise, I feel a remap is just a valid option as any to disable it. I'm not sure there's a way (a quick skim of the docs made me think `set key=` would do it but that didn't work for me, or at least I didn't understand what it does) but either way you'd still have to add config.
But again, as I say to everyone I see using commands to quit and keeps getting brought up here: `ZZ` is the same thing.
That said, given that neovim doesn't have this feature at all makes it less of an issue to me.
I suppose one could naively type the same thing twice, but I feel like some caution also goes a long way. Driving without looking at the road is generally dangerous
Any time I accidentally shift-mod my saves, I immediately see the encryption prompt, and back out with SIGINT. I don't really buy the problem, so to speak
I understand how it manifests... but I find it not that difficult to avoid
My answer to lacking feedback isn't moving forward headstrong - it's verify the delicate combination went through fine
Which is still to prompt? A person could take their chances.
Besides, wouldn't that form of intentionally aversive conditioning actually boost the learning rate and create hyperassociations to the behavior your're attempting to stimulus extinct or just learn over?
FWIW, I switched to :wq for a while but I'm back to using :x instead of :wq. I'm just very careful now. :)
https://news.ycombinator.com/item?id=34290590
vimrc excerpt:
I hate having to get the shift key timing correct so much that I also aliased : to ; for commands, but that's more radical and gets me into trouble on remote systems that are not my own, not sure if I recommend it. I'd recommend vim to change the default for everyone, though (fat chance, I know).Another annoying thing in vim is whatever the heck Q does. Try to type :q, fail, retry, and now suddenly you have an extra window to close or something. Solution: nnoremap Q <nop>
> vim encryption uses old, obsolete algorithms that are poorly implemented. Since insecure cryptography is worse than no cryptgraphy, the community voted in favor of removing all crypto.
Your blaming the victim instead of the software.
I still type :Q and :W as well, but that is not what is being discussed.
Have you ever irrevocably bricked your system, as @waisbrot mentioned they have twice, from typing :W or :Q? Have you ever bricked your system from typing :X? If so, that isn’t a “use :x vs :wq” problem, that’s seems more of a use common sense problem.
Not sure how you get "irrevocably bricked your system" from "encrypted my file", but you do you, I guess
You should also let the OP do the OP. They said they made a mistake. Simply, without complaining, and they do something else now. It's that simple
> I've twice encrypted my file with password like `cd tmp`, then saved the config file, breaking my system.
I get “irrevocably bricked system” from the fact that they “broke their system” and I am inferring it could only be something worth mentioning if it were irreversible.
I originally was trying to point out that parent was off-topic, because :x and :X are different. But a fleet of downvotes flooded in, so I defended my viewpoint for the catharsis.
So, `:wq!`, or as I call it "write the fucking file and quit, _with feeling_"
nnoremap <space> :
Has done wonders for my fingers.
(though I prefer ZZ)
I was a TA for an introductory CS class that taught C++ and, in passing, vi. A hour before one assignment was due, a student showed up in a panic. “I just had it working but then the computer corrupted my file. Look! Can I have an extension?” The other TA and I smirked: What a lame excuse! We offered some generic advice about starting earlier and visiting office hours. He left in a huff.
A few minutes later, a second student appeared with the same story, and then a third and fourth.
We eventually tracked the problem down to some handwritten notes, where someone had written a largish :x for “save and quit.” The students were doing things like spamming :X (since it didn’t seem to respond the first time—-and it was over a sluggish ssh connection) or a reflexive quit-and-compile cycle. I think we eventually recovered one or two assignments by guessing what they might have done.
We obviously apologized profusely and the next class started with a discussion of :x versus :X—-and emacs!
The editor thing wasn’t a big deal: a few minutes of “Beware :X! If you no longer trust vi, feel free to use emacs or nano, which are also installed on our system. They work a bit differently [details, resources]. You can write your code locally too, but if so, make sure it runs on our system with the autograder. Here are a few options for that too.”
It is a huge learning curve, but the ease of remote editing and the speed increase is really incredible. Being able to rapidly move around a file with just a keyboard is a super power, but it just takes muscle memory which means a lot of practice and time.
It may or may not be worth it, but it definitely is not a cultist offering. There is a large value add.
0: https://github.com/hakluke/how-to-exit-vim
This would have just been an entry "Save if needed" in the File menu, right below "Save", and users would probably find it by accident while looking at the menu, even while not actively looking for new ways to save a file.
(Not getting into the fact that a well programmed Save function would, IMO, not do anything if there are no changes, i.e. if I was the one writing the code, the Save button would be greyed out, or in the case of vim, :wq would not write anything if no changes had been made... but that's a different discussion)
[1]: https://github.com/nvim-telescope/telescope.nvim
CLI has poor discoverability? Sure; but even on the terminal, discoverability can still be good:
A couple of nice examples of discoverability in keyboard-focused programs:
- emacs' which-key[0]; there's a vim port[1] too. This shows you (some) of the available keybindings for the next input, and a short label. So you don't have to remember what `SPC h p ...` or all the options under `SPC f...`.. but it still helps to recall that `SPC h` is for 'help' related commands, `SPC f` for file related commands.
- emacs' magit[2][3]. Magit is so good at discoverability, that I'd rate it as the best tool for using git with. I've learned more about git from using it.
[0] https://github.com/justbur/emacs-which-key
[1] https://github.com/liuchengxu/vim-which-key
[2] https://magit.vc/
[3] https://emacsair.me/2017/09/01/magit-walk-through/
In practice (which is what matters, ultimately), most CLI tools don't have this desirable property of "discoverable by accident".
I'd use "CLI" more precisely to refer to command-line invocation of programs (using some shell like bash, fish, or powershell).
For programs like vim or nano, I think "TUI" (text-based UI, or sometimes terminal UI) is more suitable.
> yes, they can, but only with a great deal of extra effort from the devs, compared to the instantaneous visual feedback that a new entry provides on a GUI.
Right.
I'd say instantaneous visual feedback is what helps discoverability. Both menus in a GUI, and the menus in a TUI like in the examples above, exhibit that.
But, I wouldn't go so far as to say that a GUI menu is inherently discoverable. e.g. The image editor GIMP doesn't have good discoverability, despite being a GUI program with menus.
Whereas e.g. nano is a TUI program, but its essential features are much more discoverable compared to vim. The new tmux-alternative zellij borrows the same "show the keymap at the bottom" feature.
Agree! I also consider that distinction but didn't think of it when writing. Luckily we knew we were talking about the same thing :)
You're right about the GIMP example, but I think that just means that being a GUI program is not an automatic, free-pass guarantee to discoverability. GUIs make software capabilities more evident by the mere fact that they are there right in your line of sight, but of course it still needs a touch of good organization. But that becomes then a matter of visual design and information overload, which is a whole new area.
TUI programs can be perfectly discoverable, as any well written Ncurses app can show. I don't use many, but the first one that comes to mind is Aptitude. You can just run it and, again, most if not all of the possible actions and settings of the program are right there in front of you to explore or notice.
[1] Or a standard GUI. Emacs can be run as a GUI (not terminal).
Just in this thread we've seen options for: close unless there are changes, discard changes and close, save and close, save if changed and close, and save with encryption and close. These would not be menu items.
In a GUI, you would have close (which would always prompt if there were changes, unless you turned it off globally), save (which wouldn't do anything if there were no changes), and perhaps some extra setting somewhere about an encryption key. Which would mean you'd lose the option to unconditionally save (useful sometimes if you have something watching the file and you're testing), and you'd have an extra dialog box which pops up sometimes. In terms of discoverability, it's unconditionally better, but it's not unconditionally better in all other ways.
both :xa and :wqa work for this though.
No, the command would simply not exist because having so many commands would take up too much screen space.
It saves automatically when you press compile or change focus to another window. This is how both VSCode and Intellij work. Together with a local history that allows you to go back in time to any point earlier during the day.
Writing things in stone or reverting to older state is something reserved for git.
While we're at it :earlier and :later are undo/redo but instead of using an undo stack they use change points in time, so your undo history is never overwritten :)
I need it so rarely that I have a hard time remembering what the command was again whenever I need it. Needed it a few weeks ago, so now it's at the front of my mind again :D
This solves the problem mentioned by OP because I can just `:q` anytime.
Second, in a large Excel file, the auto save is constantly slowing me down because there’s a slight hang after every cell change.
Although I don't use autosave, I don't think it matters that much with vim because you can always use undotree[0]
0: https://github.com/mbbill/undotree