Clean Japanese and Korean Characters in URXVT

I have files and directories using Japanese and Korean. Unfortunately, urxvt by default does not display these characters nicely (the hangul looks especially ugly) by default. The way to fix this is to have a good set of TrueType fonts for both Japanese and Korean, and to have URXVT use these as defaults.

If you’re on Arch Linux like me, you can install from the AUR the ttf-kochi-substitute and ttf-baekmuk fonts for Japanese and Korean fonts, respectively. (There is also ttf-sazanami and ttf-unfonts-core for more Japanese and Korean fonts, respectively — but here I’m going to use Kochi Gothic and Baekmuk Gulim in URXVT). Now, in your ~/.Xdefaults file, put this in:

urxvt*font: xft:Terminus:pixelsize=14,\
            xft:Kochi Gothic:antialias=false,\
            xft:Baekmuk Gulim

This makes it so that Terminus is used, then Kochi Gothic, then Baekmuk Gulim. It’s good to have Kochi Gothic on a higher priority than Baekmuk Gulim, since Kochi Gothic’s kanji glyphs look much better than Baekmuk’s (and since Japanese words often have kanji in them, whereas Korean files almost always have just hangul in them). Also, the pixelsize defined with Terminus is used for all succeeding fonts below. Now my URXVT looks really nice!


Xfce4-Terminal + Console Vim Glitch Workaround

I’ll try to keep this short. I’m using Xubuntu 8.04.1 + vim 7.1.138. (Xfce4-terminal is version 0.2.8).

The problem: If you have the lines and columns options set in your .vimrc file for gvim‘s default window size upon startup, you run into a strange graphics glitch if you attempt to run simple console vim inside xfce4-terminal. What you type does not get displayed, and a new line appears after every keystroke, deleting the previous line — although the data of what you typed in is still there. It is the same problem discussed here. I encountered this problem while executing the git commit -an command from xfce4-terminal, when git resorted to vim as the default text editor. (NOTE: You might need to edit xfce4-terminal’s default window size in ~/.config/Terminal/termnalrc (the MiscDefaultGeometry option) to reproduce the glitch — I had mine set to 80×19).

The solution: Make the lines and columns options in .vimrc dependent on the “gui_running” variable, like so (copied from here):

if has("gui_running")
"GUI is running or is about to start.
"Maximize gvim window.
set lines=69 columns=100
" if we're in console Vim, then we just want to leave the window size alone --
" let it simply be whatever the window size of the terminal is before vim is
" launched
"  "This is console Vim.
"  if exists("+lines")
"    set lines=69
"  endif
"  if exists("+columns")
"    set columns=100
"  endif

This works. You do not get the strange graphical glitch behavior described above, by making vim only resize the window if it is gvim, and not console vim. I have commented out the console vim settings because, as stated above, I already have a default window size of 80×19 for xfce4-terminal.

Note: If you use xterm, it doesn’t matter — even if you don’t have the special “gui_running” option in your .vimrc, console vim will work properly. So run git commands in xterm if you don’t like xfce4-terminal.