Hacker News Reader

I hit :w so reflexively and regularly in working files that swap files only occasionally saves my butt: when I've done substantial work in a new buffer that I haven't figured out how to name yet and there's a crash.

This happens just often enough that I have to regard it as useful, but it's also less common than crashes that leave me with swaps to contend with across a dozen files that really were pretty much fine. This is a frequent annoyance.

So: occasional big help vs frequent annoyance.

I don't think the problem is actually swap files themselves, though, but the user experience with them. What vim does is prompt you to choose what to do before you've even had a chance to compare the swap with what's saved, and provides no help with the comparison. What'd be nice is if it gave you some kind of visualization of a diff between the two and then prompted you for a choice.

100% agree on that last paragraph.

For what it's worth, Vim never crashes on me. For me swap files are mostly helpful with broken connections, killed VMs that apparently still had a vim session open in a faraway terminal, or other such situations.

> I don't think the problem is actually swap files themselves, though, but the user experience with them.

Agreed, the UX is 99% the reason of me hating swap files. More often than not I choose recover, only to discover the diff is literally null. Come on, you could not check for that before interrupting? And then in any case you have double the annoyance with that recovered buffer as the old swap remains and you have to delete it or you get the warning again on the next open.

It’s kind of like changing branches with git and then back again, vim notices the time stamp of an opened file changed vs the last buffer save, lets you change the file but complains on :w that the file “changed” outside, yet is unable to a) show you a diff of current buffer vs current file, nor b) realised that the filesystem state vs buffer state at last save (which vim fully knows about) produces a null diff, so the buffer changes are safe to write.

> only to discover the diff is literally null.

Note that you can save the trouble of running diff by watching for the message "Buffer contents equals file contents." Only when they're different, you'll want to write the file to another place and diff it.

What bugs me a lot is that, even if the contents are equal, it doesn't cleanup the swap file... is there maybe a command for that so I don't have to go back to my terminal, manually remove .<filename>.swp, and open up vim again?

I don’t think you even need to write, I have this shortcut[0]:

    nmap <leader>d :w !diff -u % -<CR>

It writes the buffer’s content to diff’s stdin, and diff gets passed the filename (hence the current on disk content) to compare vs stdin (hence the current buffer content).

Only I wish it were run automatically by vim in aforementioned cases before whining (case a: recover, run the above, if no diff stop complaining; case b: rewind til last save, run the above, if no diff then replay and save without complaining)

[0]: https://github.com/lloeki/vimfiles/blob/9c50f3be60e536518beb...

> I hit :w so reflexively and regularly in working files that swap files only occasionally saves my butt

I'm definitely one of those people too, and while I don't disable swap files I do depend heavily on `persistent-undo`. It literally changed the way I work when it was introduced. To some extent I treat it as an extension to swapfile functionality as it also operates across broken sessions(intentional or not).

> [...] the user experience with them

Christian Brabandt's Recover.vim¹ is a huge improvement for those few times when you do actually want to work with a swap file. General recommendation to poke around in his other repositories too, as he has written a heap of extremely useful vim things.

Edit: Especially unicode.vim² which improves `ga` no end, csv.vim³ which feels like magic, NrrwRgn⁴ for fellow emacs refugees, and ...

¹ https://github.com/chrisbra/Recover.vim

² https://github.com/chrisbra/unicode.vim

³ https://github.com/chrisbra/csv.vim

⁴ https://github.com/chrisbra/NrrwRgn

> relative lines might also be worth checking out: "set relativenumber".

I really like the behaviour of `set number relativenumber`, where it shows me my actual line number of the current line and relative numbers on the lines I'm going to operate on.

Yes, I resent that this is for newbies some how. It's a small visual aid and unless you're using a tiny terminal it's hard to be able to do a 78d by sight.

> Or typing only Q because you didn't hit the : and accidentally entering ex mode.

I'm not certain this is different (because I don't use either deliberately) but I'm forever hitting q (not even trying to quit) and entering some kind of macro recording mode.

I think the only reason I haven't yet disabled it like you suggest (after doing it for years now) is that... Well 'some kind of macro recording' does sound like it might be pretty useful if I bothered to learn to use it!

Macros are really nice, you can automate transforming several lines of text with them. The Vim plugin in Intellij supports them. Worth learning IMHO.

Indeed, I would not recommend disabling q unless you know what it does and tried it a few times.

For a quick demo, try it on this file:

    hello world!
    here's wolves
    what's up with the hackers?

Go to the first line and do:

    1. qq starts a macro named 'q'
    2. $vbgUj select last word on line, uppercase it, go down one line
    3. q to end macro recording
    4. @q run the macro
    4b. @@ repeats the last macro
    4c. 100@q runs the macro 100 times

When you want to do multi-line edits and the columns are not aligned (so block mode, Ctrl+V, doesn't work), this works wonders. You just record whatever you would do on every line plus whatever motions you use to go to the next occurrence, using things like "f|" (find the next pipe symbol) or "/example<Esc>n" (find the next instance of "example"), and then run the macro however many times. If you specify a number of times greater than the file is large, it will automatically stop at end of file, and you can also cancel if it takes too long (Ctrl+C) and undo what it did so far (u).

Alternatively, sed -i s/a/b/ my.txt is much much faster than macros, but macros can be more complex and are often easier to record (since you're just showing the computer what to do in a human way) than trying to regex the line.

I tried recording it for the lazy but asciinema is having issues (server error when uploading).

inoremap jk <Esc>

inoremap kj <Esc>

are essential to me... press both at the same time and you exit insert mode regardless of which one gets pressed slightly faster and you never leave the home row and if you press it when you are not in insert mode it's basically a nop unless you are at the start or end of the file. even if you are you might move down or up a line accidentally but i've never had that happen personally.

This is the first thing in my config, whenever I try to setup in a new system. Now "kj" and ":w" has become more like a muscle memory, even when I am just staring at the abyss...

Then you can't type words that have jk or kj in them, right? :) Depending on languages used it could be a blocker

you certainly can. it just requires you to wait whatever the timeout is set to. it doesn't come up all that often and i've used it for a long time.

I tried that, but found it annoying to occasionally get kicked out of insert mode while writing. I ended up rebinding Caps Lock to Escape instead, with Shift+CL to toggle caps; I quite like this rebinding even outside Vim. Two lines in autohotkey on Windows, or setxkbmap in X11.

Personally I get round some of these problems by using :x instead of :wq for write/quit.

It's one letter shorter and less likely to be confused.