--- rxvt-unicode/README.FAQ 2005/02/13 11:07:57 1.10 +++ rxvt-unicode/README.FAQ 2005/07/13 03:08:57 1.16 @@ -4,10 +4,10 @@ sequence "ESC [ 8 n" sets the window title to the version number. I am using Debian GNU/Linux and have a problem... - The Debian GNU/Linux package of rxvt-unicode contains large patches - that considerably change the behaviour of rxvt-unicode. Before - reporting a bug to the original rxvt-unicode author please download - and install the genuine version + The Debian GNU/Linux package of rxvt-unicode in sarge contains large + patches that considerably change the behaviour of rxvt-unicode. + Before reporting a bug to the original rxvt-unicode author please + download and install the genuine version () and try to reproduce the problem. If you cannot, chances are that the problems are specific to Debian GNU/Linux, in which case it should be reported via the @@ -47,12 +47,16 @@ If you don't plan to use rxvt (quite common...) you could also replace the rxvt terminfo file with the rxvt-unicode one. + "tic" outputs some error when compiling the terminfo entry. + Most likely it's the empty definition for "enacs=". Just replace it + by "enacs=\E[0@" and try again. + "bash"'s readline does not work correctly under rxvt. I need a termcap file entry. One reason you might want this is that some distributions or operating systems still compile some programs using the - long-obsoleted termcap (Fedora Core's bash is one example) and rely - on a termcap entry for "rxvt-unicode". + long-obsoleted termcap library (Fedora Core's bash is one example) + and rely on a termcap entry for "rxvt-unicode". You could use rxvt's termcap entry with resonable results in many cases. You can also create a termcap entry by using terminfo's @@ -64,22 +68,23 @@ rxvt-unicode|rxvt-unicode terminal (X Window System):\ :am:bw:eo:km:mi:ms:xn:xo:\ - :co#80:it#8:li#24:\ + :co#80:it#8:li#24:lm#0:\ :AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:IC=\E[%d@:\ :K1=\EOw:K2=\EOu:K3=\EOy:K4=\EOq:K5=\EOs:LE=\E[%dD:\ - :RI=\E[%dC:SF=\E[%dS:SR=\E[%dT:UP=\E[%dA:ae=^O:al=\E[L:\ - :as=^N:bl=^G:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:\ - :cr=^M:cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:dl=\E[M:do=^J:\ - :ec=\E[%dX:ei=\E[4l:ho=\E[H:i1=\E[?47l\E=\E[?1l:ic=\E[@:\ - :im=\E[4h:is=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;3;4;6l\E[4l:\ - :k0=\E[21~:k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~:\ - :k5=\E[15~:k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:\ - :kD=\E[3~:kI=\E[2~:kN=\E[6~:kP=\E[5~:kb=\177:kd=\EOB:\ - :ke=\E[?1l\E>:kh=\E[7~:kl=\EOD:kr=\EOC:ks=\E[?1h\E=:\ - :ku=\EOA:le=^H:mb=\E[5m:md=\E[1m:me=\E[m\017:mr=\E[7m:\ - :nd=\E[C:rc=\E8:sc=\E7:se=\E[27m:sf=^J:so=\E[7m:sr=\EM:\ - :st=\EH:ta=^I:te=\E[r\E[?1049l:ti=\E[?1049h:ue=\E[24m:\ - :up=\E[A:us=\E[4m:vb=\E[?5h\E[?5l:ve=\E[?25h:vi=\E[?25l:\ + :RI=\E[%dC:SF=\E[%dS:SR=\E[%dT:UP=\E[%dA:ae=\E(B:al=\E[L:\ + :as=\E(0:bl=^G:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:\ + :cm=\E[%i%d;%dH:cr=^M:cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:\ + :dl=\E[M:do=^J:ec=\E[%dX:ei=\E[4l:ho=\E[H:\ + :i1=\E[?47l\E=\E[?1l:ic=\E[@:im=\E[4h:\ + :is=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;3;4;6l\E[4l:\ + :k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~:k5=\E[15~:\ + :k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:kD=\E[3~:\ + :kI=\E[2~:kN=\E[6~:kP=\E[5~:kb=\177:kd=\EOB:ke=\E[?1l\E>:\ + :kh=\E[7~:kl=\EOD:kr=\EOC:ks=\E[?1h\E=:ku=\EOA:le=^H:\ + :mb=\E[5m:md=\E[1m:me=\E[m\017:mr=\E[7m:nd=\E[C:rc=\E8:\ + :sc=\E7:se=\E[27m:sf=^J:so=\E[7m:sr=\EM:st=\EH:ta=^I:\ + :te=\E[r\E[?1049l:ti=\E[?1049h:ue=\E[24m:up=\E[A:\ + :us=\E[4m:vb=\E[?5h\E[?5l:ve=\E[?25h:vi=\E[?25l:\ :vs=\E[?25h: Why does "ls" no longer have coloured output? @@ -227,6 +232,13 @@ All of this is not a problem when using X11 core fonts, as their bounding box data is correct. + On Solaris 9, many line-drawing characters are too wide. + Seems to be a known bug, read + . Some people use the + following ugly workaround to get non-double-wide-characters working: + + #define wcwidth(x) wcwidth(x) > 1 ? 1 : wcwidth(x) + My Compose (Multi_key) key is no longer working. The most common causes for this are that either your locale is not set correctly, or you specified a preeditStyle that is not supported @@ -280,13 +292,16 @@ representation of wchar_t. This is, of course, completely fine with respect to standards. - However, "__STDC_ISO_10646__" is the only sane way to support - multi-language apps in an OS, as using a locale-dependent (and - non-standardized) representation of wchar_t makes it impossible to - convert between wchar_t (as used by X11 and your applications) and - any other encoding without implementing OS-specific-wrappers for - each and every locale. There simply are no APIs to convert wchar_t - into anything except the current locale encoding. + However, that means rxvt-unicode only works in "POSIX", "ISO-8859-1" + and "UTF-8" locales under FreeBSD (which all use Unicode as wchar_t. + + "__STDC_ISO_10646__" is the only sane way to support multi-language + apps in an OS, as using a locale-dependent (and non-standardized) + representation of wchar_t makes it impossible to convert between + wchar_t (as used by X11 and your applications) and any other + encoding without implementing OS-specific-wrappers for each and + every locale. There simply are no APIs to convert wchar_t into + anything except the current locale encoding. Some applications (such as the formidable mlterm) work around this by carrying their own replacement functions for character set @@ -299,6 +314,22 @@ the system libraries once and for all, instead of forcing every app to carry complete replacements for them :) + I use Solaris 9 and it doesn't compile/work/etc. + Try the diff in doc/solaris9.patch as a base. It fixes the worst + problems with "wcwidth" and a compile problem. + + How can I use rxvt-unicode under cygwin? + rxvt-unicode should compile and run out of the box on cygwin, using + the X11 libraries that come with cygwin. libW11 emulation is no + longer supported (and makes no sense, either, as it only supported a + single font). I recommend starting the X-server in "-multiwindow" or + "-rootless" mode instead, which will result in similar look&feel as + the old libW11 emulation. + + At the time of this writing, cygwin didn't seem to support any + multi-byte encodings (you might try "LC_CTYPE=C-UTF-8"), so you are + likely limited to 8-bit encodings. + How does rxvt-unicode determine the encoding to use? Is there an option to switch encodings? Unlike some other terminals, rxvt-unicode has no encoding switch, @@ -502,14 +533,8 @@ URxvt.color15: #e1dddd How can I start rxvtd in a race-free way? - Despite it's name, rxvtd is not a real daemon, but more like a - server that answers rxvtc's requests, so it doesn't background - itself. - - To ensure rxvtd is listening on it's socket, you can use the - following method to wait for the startup message before continuing: - - { rxvtd & } | read + Try "rxvtd -f -o", which tells rxvtd to open the display, create the + listening socket and then fork. What's with the strange Backspace/Delete key behaviour? Assuming that the physical Backspace key corresponds to the