Escaping from alternative charset (weird characters in tmux)

When I'm playing mud, sometimes my terminal run into a queer mode that leaves the characters all messed up:

After some research I found that it's because the terminal went into the 'Alternative charset' mode, that translate some characters to symbols (See the last section of man 5 termcap). As for the reason why it went into this mode, it's because that I accidentally echoed '^N' into the terminal. To escape, you can simply echo '^O' to restore the state. most common way:

$ cat
^O
^D

or you can use echo, if your shell supports entering special characters

$ echo ^V^O

If you want to reproduce this, just change the ^O above to ^N then you'll find yourself in the AC mode again.

Some in-depth explanation and other more complicated cases are described here:
http://www.in-ulm.de/~mascheck/various/alternate_charset/

Lock on suspend & Systemd

Ever since I switched to systemd, I found that the acpi-support LOCK_SCREEN(in /etc/default/acpi-support) setting doesn't work anymore. While acpi_listen still shows that the lid closing event is detected, my screenlock program(i3lock) wasn't getting executed whatsoever.

With a little bit of tracing I found that the lid event and relevant scripts are indeed executed but after invoking the 'CheckPolicy' function in the /etc/acpi/lid.sh the script halted. This is because the script checks the system to see if there are other program being in charge of power management and if there is acpi gets aborted.

So, to enforce screen locking after resume (or before sleep), we'll need to setup a service in systemd that gets executed at the appropriate time. After a bit of searching and playing with the options, I found this ready-to-use unit file by Karsten Gebbert:
https://github.com/krgn/systemd/blob/master/i3lock@.service

to use this, download the .service file to /etc/systemd/system and enable the service with the following command:

(sudo) systemctl enable i3lock@[user].service

Where [user] should be replaced by the username whose password would be used to unlock.

To check if the service is enabled correctly you can either just try to suspend and see if the i3lock is fired up or check the list of currently enabled services:

 systemctl list-unit-files | grep i3lock

if you have successfully enabled it, there should be message like this:

i3lock@.service                            enabled

Note on the file name:
With an @ in the file name means this file is a template and can be enabled with specified instance name if provided. In this case the instance name will be [user] and it will replace the %i variable in the file.