Improve vim responsiveness with better timeout settings

Vim is typically fast, but it can be painfully slow at times, too.

A great example of this is when you make a block selection, insert/append text, and then hit ESC to apply your action to the rest of your selection. It seems to take forever before you’re back in normal mode and can see your action applied to the selection.

After digging into the issue, I learned that it doesn’t have to be this way.

Vim has two settings that you let you control timeouts when working with map key sequences and terminal keycodes/escape sequences:

1. timeoutlen defaults to 1000 and is the delay in milliseconds that vim uses when checking for map key sequences. It’s also used when checking keycodes if ttimeoutlen is disabled.

2. ttimeoutlen defaults to -1 (disabled) and is the delay in milliseconds that vim uses when checking for keycodes.

Out of the box, my vim was taking a full second to switch between insert and normal mode because ttimeoutlen was disabled; every hit of the ESC key caused vim to wait the full timeout in anticipation of a possible keycode.

To get around this I added the following to my vimrc:

" Adjust keycode timeout length
set ttimeoutlen=100

Since doing so, I’ve noticed that vim has been much snappier and even more of a pleasure to work with than usual.

If you’re like me and use vim in tmux, it’s worth noting that I also had to adjust my tmux.conf to get the timeout settings above working as expected. tmux has its own built-in delay for escape sequences that needs to be tweaked.

Improving WordPress security through Nginx

WordPress security has always been a hot topic given its popularity and the large number of amateur developers creating add-ons for it.

Looking through my nginx error logs for a WordPress site I host, I was disgusted to see that an alarming percentage of requests were clear attempts to hijack the site via insecure plugins and themes.

Thankfully, every one of these requests ended up serving a 404 page since the site in question only uses a handful of custom-written plugins, but what if we were using published plugins with known security vulnerabilities?

I’d rather not find out.

When placed above your @php location (or other location for processing php files in your nginx.conf), this location directive will stop evil-doers dead in their tracks when they try to directly access any sort of PHP script in the wp-content directory:

location ~ ^/wp-content/.+\.php { return 444; }

You’ve likely seen other 400 HTTP status codes, but the 444 code used here is special. It’s not an actual HTTP status code, but instead it directs nginx to drop the connection and not send back any response.

Previously I had a guard in my @php location to stop visitors from potentially executing PHP scripts in /wp-content/uploads (returned a 500 response instead), but this updated location directly goes the extra mile by not allowing would-be hijackers the privilege of even receiving a 500 or 404 response.

Useful fullscreen mode for iTerm in Lion

Fullscreen mode in Lion sucks if you use multiple monitors, but it doesn’t have to suck if you’re using iTerm2.

If you disable ‘Use Lion-style Fullscreen windows’ under General > Window in iTerm2’s preferences, iTerm2 will expand to cover the entire desktop area for the monitor it’s currently displayed on and you’ll still be able to use your other monitor for other applications/windows.