For me, it was how I learned Vim. The awkward keyboard pushed me towards learning more efficient keystrokes, so now I'm very comfortable with Vim.

I would learn it on the bus, and at the time I didn't have a data plan, so I could only access things I had already downloaded. The `:help` documentation is very thorough.

It's actually a bit more nuanced: `:x` is like `:wq`, but only writes if changes have been made. `:x!` has the same semantics as `:wq!`.

The fact that everyone says the meme is dead, but in this small thread there are 5 different people posting how to exit, and none of them are the same says there is still pretty good substance behind that meme.

I think we're all kind of implicitly acknowledging the truth of the meme. I mean that was definitely a conscious part of my own comment.

I feel like the default behavior should be to not write unless changes have been made. I may be misunderstanding here, but what would be getting written if nothing's been changed?

It would overwrite changes made by external programs.

Metadata about the file like modification time.

> Also, without some sort of indicator, Vim’s modal design is awkward here—it’s very easy to forget which mode you’re in.

With `bash`, you can show which mode you're in by putting this in your `~/.inputrc`:

    show-mode-in-prompt on

It makes your prompt look like this:

    [foo@bar ~]$ # before turning it on
    @[foo@bar ~]$ # after
    @[foo@bar ~]$ set -o vi
    (ins)[foo@bar ~]$ # and after I press esc:
    (cmd)[foo@bar ~]$

Customize these with `emacs-mode-string`, `vi-ins-mode-string`, and `vi-cmd-mode-string`.

> [...] but I found it difficult to remember to put `;tput bel` on every command that would be slow [...]

What I do in these situations (assuming the job is still in the foreground, and can be interrupted), is suspend the task with ctrl+z and resume with `fg`, chaining it with some other command:

    fg; notify-send "done"

This uses the "job control" feature of `bash`, so it requires no extra setup. Your approach has the simple advantage however, that once it's set up, it just works, automatically.

Cool. I didn't know about "Ctrl+T, Ctrl+Z"; I've always used "Alt+D, Alt+Enter" to duplicate tabs. This other shortcut might come in handy if I want to immediately edit the URL.

With the mouse, you can Ctrl+drag to duplicate a tab.

Not as quick as you're asking for, but what I do, after running "git log" to jog my memory of what the commit message was, is this:

  git commit --fixup=':/message regexp'

This will find the youngest commit where the message matches the "message regexp" pattern. See also: https://git-scm.com/docs/gitrevisions

Lead sheets?

This is incredible. I'm learning so much by just reading the source code and trying it out.

It's called the Imperative Mood[0]. I like to think of it as though I'm completing this statement: "If you apply this patch, this commit will [Do The Thing™]". Here's a few examples:

If I were to apply this patch, this commit will…

- Simplify FooWidget

- Add optional table support

- Remove trailing whitespace

- Update fizzbuzz to 1.2.0

- Merge branch 'feature/ABC-123-foobar'

- Revert "Add foo to bar"

[0]: https://en.wikipedia.org/wiki/Imperative_mood

Thanks, that's a really clear explanation. I'm going to try that out and see if it sticks for me.

Not quite there with the scanning part, but https://supercook.com comes close.