== Some notes and issues from trying out _urxvt_ as an _xterm_ replacement I've been using _xterm_ for a very long time, but I'm also aware that it's not a perfect terminal emulator (especially in today's Unicode world, [[my hacks notwithstanding XTermFreeTypeCJKFonts]]). Years ago I wrote up [[what I wanted added to _xterm_ XTermWants]], and the recommendation I've received over the years (both on that entry and elsewhere) is for _urxvt_ (aka [[rxvt-unicode http://software.schmorp.de/pkg/rxvt-unicode.html]]). I've made off and on experiments with _urxvt_, but for various reasons I've recently been trying a bit more seriously to use it regularly and to evaluate it as a serious alternative to _xterm_ for me. One of my crucial needs in an _xterm_ replacement is an equivalent of [[_xterm_'s ziconbeep feature ../sysadmin/XtermZiconbeep]], which I use to see when an iconified _xterm_ has new output. Fortunately that need was met [[a long time ago https://twitter.com/thatcks/status/370559196124958720]] through a _urxvt_ Perl extension written by [[Leah Neukirchen http://chneukirchen.org/]]; you can get the extension itself [[here http://chneukirchen.org/dotfiles/.urxvt/ziconbeep]]. In my version I took out the audible bell. Without this, _urxvt_ wouldn't be a particularly viable option for me, so I'm glad that it exists. Urxvt's big draw as an _xterm_ replacement is that it will reflow lines as you widen and narrow it. However, for a long time this didn't seem to work for me, or didn't seem to work reliably. Back in [[last September https://twitter.com/thatcks/status/910970907971244032]] I finally discovered that the issue is that ~~urxvt only reflows lines after a resize if it's already scrolled text in the window~~. This is the case both for resizing wider and for resizing narrower, which can be especially annoying (since resizing wider can sometimes 'un-scroll' a window). This is something that I can sort of work around; these days I often make it a point to start out my _urxvt_ windows in their basic 80x24 size, dump out the output that I'll want, and only then resize them to read the long lines. This mostly works but it's kind of irritating. (I'm not sure if this is a _urxvt_ bug or a deliberate design decision. Perhaps I should try reporting it to find out.) Another difference is that xterm has relatively complicated behavior on double-clicks for what it considers to be separate 'words'; you can read the full details in [[the manpage's section on character classes http://invisible-island.net/xterm/manpage/xterm.html#h2-CHARACTER-CLASSES]]. Urxvt has somewhat simpler behavior based on delimiter characters, and its default set of delimiters make it select bigger 'words' than xterm does. For instance, a standard urxvt setup will consider all of a full path to be one word, because _/_ is not a delimiter character (neither is _:_, so all of your _$PATH_ is one word as far as urxvt is concerned). I'm highly accustomed to xterm's behavior and I prefer smaller words here, because it's much easier to widen a selection than it is to narrow it. You can customize some of this behavior with urxvt's _cutchars_ resource (see [[the urxvt manpage http://pod.tst.eu/http://cvs.schmorp.de/rxvt-unicode/doc/rxvt.1.pod]]). Currently I'm using: .pn prewrap on > ! requires magic quoting for reasons. > URxvt*cutchars: "\\`\"'&()*,;<=>?@[]^{|}.#%+!/:-" This improves the situation in urxvt but isn't perfect; in practice I see various glitches, generally when several of these delimiters happen in a row (eg given '_a..._', a double-click in urxvt may select up to the entire thing). Since I'm using the default _selection_ Perl extension, possibly I could improve things by writing some complicated regular expressions (or replace the _selection_ extension entirely with a more controllable version where I understand exactly what it's doing). If I want to exactly duplicate xterm's behavior, a Perl extension is probably the only way to achieve it. (I'm not entirely allergic to writing Perl extensions for urxvt, but it's been a long time since I wrote Perl and I'm not familiar with the urxvt extensions API, so at a minimum it's going to be a pain.) Given these issues I'm not throwing myself into a complete replacement of my xterm usage with urxvt, but I am reaching for it reasonably frequently and I've taken steps to make it easier to use in my environment. This involves both making it as conveniently accessible as xterm and also teaching various bits of my window manager configuration and scripting that urxvt is a terminal window and should be treated like xterm. This whole thing has been an interesting experience overall. It's taught me both how much I'm attuned to very specific xterm behaviors and how deeply xterm has become embedded into my overall X environment.