1 | FREQUENTLY ASKED QUESTIONS |
1 | FREQUENTLY ASKED QUESTIONS |
|
|
2 | Isn't rxvt supposed to be small? Don't all those features bloat? |
|
|
3 | I often get asked about this, and I think, no, they didn't cause |
|
|
4 | extra bloat. If you compare a minimal rxvt and a minimal urxvt, you |
|
|
5 | can see that the urxvt binary is larger (due to some encoding tables |
|
|
6 | always being compiled in), but it actually uses less memory (RSS) |
|
|
7 | after startup. Even with "--disable-everything", this comparison is |
|
|
8 | a bit unfair, as many features unique to urxvt (locale, encoding |
|
|
9 | conversion, iso14755 etc.) are already in use in this mode. |
|
|
10 | |
|
|
11 | text data bss drs rss filename |
|
|
12 | 98398 1664 24 15695 1824 rxvt --disable-everything |
|
|
13 | 188985 9048 66616 18222 1788 urxvt --disable-everything |
|
|
14 | |
|
|
15 | When you "--enable-everything" (which _is_ unfair, as this involves |
|
|
16 | xft and full locale/XIM support which are quite bloaty inside libX11 |
|
|
17 | and my libc), the two diverge, but not unreasnobaly so. |
|
|
18 | |
|
|
19 | text data bss drs rss filename |
|
|
20 | 163431 2152 24 20123 2060 rxvt --enable-everything |
|
|
21 | 1035683 49680 66648 29096 3680 urxvt --enable-everything |
|
|
22 | |
|
|
23 | The very large size of the text section is explained by the |
|
|
24 | east-asian encoding tables, which, if unused, take up disk space but |
|
|
25 | nothing else and can be compiled out unless you rely on X11 core |
|
|
26 | fonts that use those encodings. The BSS size comes from the 64k |
|
|
27 | emergency buffer that my c++ compiler allocates (but of course |
|
|
28 | doesn't use unless you are out of memory). Also, using an xft font |
|
|
29 | instead of a core font immediately adds a few megabytes of RSS. Xft |
|
|
30 | indeed is responsible for a lot of RSS even when not used. |
|
|
31 | |
|
|
32 | Of course, due to every character using two or four bytes instead of |
|
|
33 | one, a large scrollback buffer will ultimately make rxvt-unicode use |
|
|
34 | more memory. |
|
|
35 | |
|
|
36 | Compared to e.g. Eterm (5112k), aterm (3132k) and xterm (4680k), |
|
|
37 | this still fares rather well. And compared to some monsters like |
|
|
38 | gnome-terminal (21152k + extra 4204k in separate processes) or |
|
|
39 | konsole (22200k + extra 43180k in daemons that stay around after |
|
|
40 | exit, plus half a minute of startup time, including the hundreds of |
|
|
41 | warnings it spits out), it fares extremely well *g*. |
|
|
42 | |
|
|
43 | Why C++, isn't that unportable/bloated/uncool? |
|
|
44 | Is this a question? :) It comes up very often. The simple answer is: |
|
|
45 | I had to write it, and C++ allowed me to write and maintain it in a |
|
|
46 | fraction of the time and effort (which is a scarce resource for me). |
|
|
47 | Put even shorter: It simply wouldn't exist without C++. |
|
|
48 | |
|
|
49 | My personal stance on this is that C++ is less portable than C, but |
|
|
50 | in the case of rxvt-unicode this hardly matters, as its portability |
|
|
51 | limits are defined by things like X11, pseudo terminals, locale |
|
|
52 | support and unix domain sockets, which are all less portable than |
|
|
53 | C++ itself. |
|
|
54 | |
|
|
55 | Regarding the bloat, see the above question: It's easy to write |
|
|
56 | programs in C that use gobs of memory, an certainly possible to |
|
|
57 | write programs in C++ that don't. C++ also often comes with large |
|
|
58 | libraries, but this is not necessarily the case with GCC. Here is |
|
|
59 | what rxvt links against on my system with a minimal config: |
|
|
60 | |
|
|
61 | libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x00002aaaaabc3000) |
|
|
62 | libc.so.6 => /lib/libc.so.6 (0x00002aaaaadde000) |
|
|
63 | libdl.so.2 => /lib/libdl.so.2 (0x00002aaaab01d000) |
|
|
64 | /lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000) |
|
|
65 | |
|
|
66 | And here is rxvt-unicode: |
|
|
67 | |
|
|
68 | libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x00002aaaaabc3000) |
|
|
69 | libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00002aaaaada2000) |
|
|
70 | libc.so.6 => /lib/libc.so.6 (0x00002aaaaaeb0000) |
|
|
71 | libdl.so.2 => /lib/libdl.so.2 (0x00002aaaab0ee000) |
|
|
72 | /lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000) |
|
|
73 | |
|
|
74 | No large bloated libraries (of course, none were linked in |
|
|
75 | statically), except maybe libX11 :) |
|
|
76 | |
|
|
77 | Does it support tabs, can I have a tabbed rxvt-unicode? |
|
|
78 | rxvt-unicode does not directly support tabs. It will work fine with |
|
|
79 | tabbing functionality of many window managers or similar tabbing |
|
|
80 | programs, and its embedding-features allow it to be embedded into |
|
|
81 | other programs, as witnessed by doc/rxvt-tabbed or the upcoming |
|
|
82 | "Gtk2::URxvt" perl module, which features a tabbed urxvt (murxvt) |
|
|
83 | terminal as an example embedding application. |
|
|
84 | |
2 | How do I know which rxvt-unicode version I'm using? |
85 | How do I know which rxvt-unicode version I'm using? |
3 | The version number is displayed with the usage (-h). Also the escape |
86 | The version number is displayed with the usage (-h). Also the escape |
4 | sequence "ESC [ 8 n" sets the window title to the version number. |
87 | sequence "ESC [ 8 n" sets the window title to the version number. |
|
|
88 | When using the rxvtc client, the version displayed is that of the |
|
|
89 | daemon. |
5 | |
90 | |
6 | I am using Debian GNU/Linux and have a problem... |
91 | I am using Debian GNU/Linux and have a problem... |
7 | The Debian GNU/Linux package of rxvt-unicode contains large patches |
92 | The Debian GNU/Linux package of rxvt-unicode in sarge contains large |
8 | that considerably change the behaviour of rxvt-unicode. Before |
93 | patches that considerably change the behaviour of rxvt-unicode. |
9 | reporting a bug to the original rxvt-unicode author please download |
94 | Before reporting a bug to the original rxvt-unicode author please |
10 | and install the genuine version |
95 | download and install the genuine version |
11 | (<http://software.schmorp.de#rxvt-unicode>) and try to reproduce the |
96 | (<http://software.schmorp.de#rxvt-unicode>) and try to reproduce the |
12 | problem. If you cannot, chances are that the problems are specific |
97 | problem. If you cannot, chances are that the problems are specific |
13 | to Debian GNU/Linux, in which case it should be reported via the |
98 | to Debian GNU/Linux, in which case it should be reported via the |
14 | Debian Bug Tracking System (use "reportbug" to report the bug). |
99 | Debian Bug Tracking System (use "reportbug" to report the bug). |
15 | |
100 | |
16 | For other problems that also affect the Debian package, you can and |
101 | For other problems that also affect the Debian package, you can and |
17 | probably should use the Debian BTS, too, because, after all, it's |
102 | probably should use the Debian BTS, too, because, after all, it's |
18 | also a bug in the Debian version and it serves as a reminder for |
103 | also a bug in the Debian version and it serves as a reminder for |
19 | other users that might encounter the same issue. |
104 | other users that might encounter the same issue. |
|
|
105 | |
|
|
106 | I am maintaining rxvt-unicode for distribution/OS XXX, any |
|
|
107 | recommendation? |
|
|
108 | You should build one binary with the default options. configure now |
|
|
109 | enables most useful options, and the trend goes to making them |
|
|
110 | runtime-switchable, too, so there is usually no drawback to enbaling |
|
|
111 | them, except higher disk and possibly memory usage. The perl |
|
|
112 | interpreter should be enabled, as important functionality (menus, |
|
|
113 | selection, likely more in the future) depends on it. |
|
|
114 | |
|
|
115 | You should not overwrite the "perl-ext-common" snd "perl-ext" |
|
|
116 | resources system-wide (except maybe with "defaults"). This will |
|
|
117 | result in useful behaviour. If your distribution aims at low memory, |
|
|
118 | add an empty "perl-ext-common" resource to the app-defaults file. |
|
|
119 | This will keep the perl interpreter disabled until the user enables |
|
|
120 | it. |
|
|
121 | |
|
|
122 | If you can/want build more binaries, I recommend building a minimal |
|
|
123 | one with "--disable-everything" (very useful) and a maximal one with |
|
|
124 | "--enable-everything" (less useful, it will be very big due to a lot |
|
|
125 | of encodings built-in that increase download times and are rarely |
|
|
126 | used). |
|
|
127 | |
|
|
128 | I need to make it setuid/setgid to support utmp/ptys on my OS, is this |
|
|
129 | safe? |
|
|
130 | Likely not. While I honestly try to make it secure, and am probably |
|
|
131 | not bad at it, I think it is simply unreasonable to expect all of |
|
|
132 | freetype + fontconfig + xft + xlib + ... + rxvt-unicode itself to |
|
|
133 | all be secure. Also, rxvt-unicode disables some options when it |
|
|
134 | detects that it runs setuid or setgid, which is not nice. |
|
|
135 | |
|
|
136 | Elevated privileges are only required for utmp and pty operations on |
|
|
137 | some systems (for example, GNU/Linux doesn't need any extra |
|
|
138 | privileges for ptys, but some need it for utmp support). If |
|
|
139 | rxvt-unicode doesn't support the library/setuid helper that your OS |
|
|
140 | needs I'll be happy to assist you in implementing support for it. |
|
|
141 | |
|
|
142 | So, while setuid/setgid operation is supported and not a problem on |
|
|
143 | your typical single-user-no-other-logins unix desktop, always |
|
|
144 | remember that its an awful lot of code, most of which isn't checked |
|
|
145 | for security issues regularly. |
20 | |
146 | |
21 | When I log-in to another system it tells me about missing terminfo data? |
147 | When I log-in to another system it tells me about missing terminfo data? |
22 | The terminal description used by rxvt-unicode is not as widely |
148 | The terminal description used by rxvt-unicode is not as widely |
23 | available as that for xterm, or even rxvt (for which the same |
149 | available as that for xterm, or even rxvt (for which the same |
24 | problem often arises). |
150 | problem often arises). |
… | |
… | |
45 | URxvt.termName: rxvt |
171 | URxvt.termName: rxvt |
46 | |
172 | |
47 | If you don't plan to use rxvt (quite common...) you could also |
173 | If you don't plan to use rxvt (quite common...) you could also |
48 | replace the rxvt terminfo file with the rxvt-unicode one. |
174 | replace the rxvt terminfo file with the rxvt-unicode one. |
49 | |
175 | |
|
|
176 | "tic" outputs some error when compiling the terminfo entry. |
|
|
177 | Most likely it's the empty definition for "enacs=". Just replace it |
|
|
178 | by "enacs=\E[0@" and try again. |
|
|
179 | |
50 | "bash"'s readline does not work correctly under rxvt. |
180 | "bash"'s readline does not work correctly under rxvt. |
51 | I need a termcap file entry. |
181 | I need a termcap file entry. |
52 | One reason you might want this is that some distributions or |
182 | One reason you might want this is that some distributions or |
53 | operating systems still compile some programs using the |
183 | operating systems still compile some programs using the |
54 | long-obsoleted termcap (Fedora Core's bash is one example) and rely |
184 | long-obsoleted termcap library (Fedora Core's bash is one example) |
55 | on a termcap entry for "rxvt-unicode". |
185 | and rely on a termcap entry for "rxvt-unicode". |
56 | |
186 | |
57 | You could use rxvt's termcap entry with resonable results in many |
187 | You could use rxvt's termcap entry with resonable results in many |
58 | cases. You can also create a termcap entry by using terminfo's |
188 | cases. You can also create a termcap entry by using terminfo's |
59 | infocmp program like this: |
189 | infocmp program like this: |
60 | |
190 | |
… | |
… | |
62 | |
192 | |
63 | Or you could use this termcap entry, generated by the command above: |
193 | Or you could use this termcap entry, generated by the command above: |
64 | |
194 | |
65 | rxvt-unicode|rxvt-unicode terminal (X Window System):\ |
195 | rxvt-unicode|rxvt-unicode terminal (X Window System):\ |
66 | :am:bw:eo:km:mi:ms:xn:xo:\ |
196 | :am:bw:eo:km:mi:ms:xn:xo:\ |
67 | :co#80:it#8:li#24:\ |
197 | :co#80:it#8:li#24:lm#0:\ |
68 | :AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:IC=\E[%d@:\ |
198 | :AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:IC=\E[%d@:\ |
69 | :K1=\EOw:K2=\EOu:K3=\EOy:K4=\EOq:K5=\EOs:LE=\E[%dD:\ |
199 | :K1=\EOw:K2=\EOu:K3=\EOy:K4=\EOq:K5=\EOs:LE=\E[%dD:\ |
70 | :RI=\E[%dC:SF=\E[%dS:SR=\E[%dT:UP=\E[%dA:ae=^O:al=\E[L:\ |
200 | :RI=\E[%dC:SF=\E[%dS:SR=\E[%dT:UP=\E[%dA:ae=\E(B:al=\E[L:\ |
71 | :as=^N:bl=^G:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:\ |
201 | :as=\E(0:bl=^G:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:\ |
72 | :cr=^M:cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:dl=\E[M:do=^J:\ |
202 | :cm=\E[%i%d;%dH:cr=^M:cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:\ |
73 | :ec=\E[%dX:ei=\E[4l:ho=\E[H:i1=\E[?47l\E=\E[?1l:ic=\E[@:\ |
203 | :dl=\E[M:do=^J:ec=\E[%dX:ei=\E[4l:ho=\E[H:\ |
|
|
204 | :i1=\E[?47l\E=\E[?1l:ic=\E[@:im=\E[4h:\ |
74 | :im=\E[4h:is=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;3;4;6l\E[4l:\ |
205 | :is=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;3;4;6l\E[4l:\ |
75 | :k0=\E[21~:k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~:\ |
206 | :k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~:k5=\E[15~:\ |
76 | :k5=\E[15~:k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:\ |
207 | :k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:kD=\E[3~:\ |
77 | :kD=\E[3~:kI=\E[2~:kN=\E[6~:kP=\E[5~:kb=\177:kd=\EOB:\ |
208 | :kI=\E[2~:kN=\E[6~:kP=\E[5~:kb=\177:kd=\EOB:ke=\E[?1l\E>:\ |
78 | :ke=\E[?1l\E>:kh=\E[7~:kl=\EOD:kr=\EOC:ks=\E[?1h\E=:\ |
209 | :kh=\E[7~:kl=\EOD:kr=\EOC:ks=\E[?1h\E=:ku=\EOA:le=^H:\ |
79 | :ku=\EOA:le=^H:mb=\E[5m:md=\E[1m:me=\E[m\017:mr=\E[7m:\ |
210 | :mb=\E[5m:md=\E[1m:me=\E[m\017:mr=\E[7m:nd=\E[C:rc=\E8:\ |
80 | :nd=\E[C:rc=\E8:sc=\E7:se=\E[27m:sf=^J:so=\E[7m:sr=\EM:\ |
211 | :sc=\E7:se=\E[27m:sf=^J:so=\E[7m:sr=\EM:st=\EH:ta=^I:\ |
81 | :st=\EH:ta=^I:te=\E[r\E[?1049l:ti=\E[?1049h:ue=\E[24m:\ |
212 | :te=\E[r\E[?1049l:ti=\E[?1049h:ue=\E[24m:up=\E[A:\ |
82 | :up=\E[A:us=\E[4m:vb=\E[?5h\E[?5l:ve=\E[?25h:vi=\E[?25l:\ |
213 | :us=\E[4m:vb=\E[?5h\E[?5l:ve=\E[?25h:vi=\E[?25l:\ |
83 | :vs=\E[?25h: |
214 | :vs=\E[?25h: |
84 | |
215 | |
85 | Why does "ls" no longer have coloured output? |
216 | Why does "ls" no longer have coloured output? |
86 | The "ls" in the GNU coreutils unfortunately doesn't use terminfo to |
217 | The "ls" in the GNU coreutils unfortunately doesn't use terminfo to |
87 | decide wether a terminal has colour, but uses it's own configuration |
218 | decide wether a terminal has colour, but uses it's own configuration |
… | |
… | |
225 | that doesn't work, you might be forced to use a different font. |
356 | that doesn't work, you might be forced to use a different font. |
226 | |
357 | |
227 | All of this is not a problem when using X11 core fonts, as their |
358 | All of this is not a problem when using X11 core fonts, as their |
228 | bounding box data is correct. |
359 | bounding box data is correct. |
229 | |
360 | |
|
|
361 | On Solaris 9, many line-drawing characters are too wide. |
|
|
362 | Seems to be a known bug, read |
|
|
363 | <http://nixdoc.net/files/forum/about34198.html>. Some people use the |
|
|
364 | following ugly workaround to get non-double-wide-characters working: |
|
|
365 | |
|
|
366 | #define wcwidth(x) wcwidth(x) > 1 ? 1 : wcwidth(x) |
|
|
367 | |
230 | My Compose (Multi_key) key is no longer working. |
368 | My Compose (Multi_key) key is no longer working. |
231 | The most common causes for this are that either your locale is not |
369 | The most common causes for this are that either your locale is not |
232 | set correctly, or you specified a preeditStyle that is not supported |
370 | set correctly, or you specified a preeditStyle that is not supported |
233 | by your input method. For example, if you specified OverTheSpot and |
371 | by your input method. For example, if you specified OverTheSpot and |
234 | your input method (e.g. the default input method handling Compose |
372 | your input method (e.g. the default input method handling Compose |
… | |
… | |
278 | As you might have guessed, FreeBSD does neither define this symobl |
416 | As you might have guessed, FreeBSD does neither define this symobl |
279 | nor does it support it. Instead, it uses it's own internal |
417 | nor does it support it. Instead, it uses it's own internal |
280 | representation of wchar_t. This is, of course, completely fine with |
418 | representation of wchar_t. This is, of course, completely fine with |
281 | respect to standards. |
419 | respect to standards. |
282 | |
420 | |
|
|
421 | However, that means rxvt-unicode only works in "POSIX", "ISO-8859-1" |
|
|
422 | and "UTF-8" locales under FreeBSD (which all use Unicode as wchar_t. |
|
|
423 | |
283 | However, "__STDC_ISO_10646__" is the only sane way to support |
424 | "__STDC_ISO_10646__" is the only sane way to support multi-language |
284 | multi-language apps in an OS, as using a locale-dependent (and |
425 | apps in an OS, as using a locale-dependent (and non-standardized) |
285 | non-standardized) representation of wchar_t makes it impossible to |
426 | representation of wchar_t makes it impossible to convert between |
286 | convert between wchar_t (as used by X11 and your applications) and |
427 | wchar_t (as used by X11 and your applications) and any other |
287 | any other encoding without implementing OS-specific-wrappers for |
428 | encoding without implementing OS-specific-wrappers for each and |
288 | each and every locale. There simply are no APIs to convert wchar_t |
429 | every locale. There simply are no APIs to convert wchar_t into |
289 | into anything except the current locale encoding. |
430 | anything except the current locale encoding. |
290 | |
431 | |
291 | Some applications (such as the formidable mlterm) work around this |
432 | Some applications (such as the formidable mlterm) work around this |
292 | by carrying their own replacement functions for character set |
433 | by carrying their own replacement functions for character set |
293 | handling with them, and either implementing OS-dependent hacks or |
434 | handling with them, and either implementing OS-dependent hacks or |
294 | doing multiple conversions (which is slow and unreliable in case the |
435 | doing multiple conversions (which is slow and unreliable in case the |
… | |
… | |
296 | emulator). |
437 | emulator). |
297 | |
438 | |
298 | The rxvt-unicode author insists that the right way to fix this is in |
439 | The rxvt-unicode author insists that the right way to fix this is in |
299 | the system libraries once and for all, instead of forcing every app |
440 | the system libraries once and for all, instead of forcing every app |
300 | to carry complete replacements for them :) |
441 | to carry complete replacements for them :) |
|
|
442 | |
|
|
443 | I use Solaris 9 and it doesn't compile/work/etc. |
|
|
444 | Try the diff in doc/solaris9.patch as a base. It fixes the worst |
|
|
445 | problems with "wcwidth" and a compile problem. |
|
|
446 | |
|
|
447 | How can I use rxvt-unicode under cygwin? |
|
|
448 | rxvt-unicode should compile and run out of the box on cygwin, using |
|
|
449 | the X11 libraries that come with cygwin. libW11 emulation is no |
|
|
450 | longer supported (and makes no sense, either, as it only supported a |
|
|
451 | single font). I recommend starting the X-server in "-multiwindow" or |
|
|
452 | "-rootless" mode instead, which will result in similar look&feel as |
|
|
453 | the old libW11 emulation. |
|
|
454 | |
|
|
455 | At the time of this writing, cygwin didn't seem to support any |
|
|
456 | multi-byte encodings (you might try "LC_CTYPE=C-UTF-8"), so you are |
|
|
457 | likely limited to 8-bit encodings. |
301 | |
458 | |
302 | How does rxvt-unicode determine the encoding to use? |
459 | How does rxvt-unicode determine the encoding to use? |
303 | Is there an option to switch encodings? |
460 | Is there an option to switch encodings? |
304 | Unlike some other terminals, rxvt-unicode has no encoding switch, |
461 | Unlike some other terminals, rxvt-unicode has no encoding switch, |
305 | and no specific "utf-8" mode, such as xterm. In fact, it doesn't |
462 | and no specific "utf-8" mode, such as xterm. In fact, it doesn't |
… | |
… | |
388 | Now you can start your terminal with "LC_CTYPE=ja_JP.UTF-8" and |
545 | Now you can start your terminal with "LC_CTYPE=ja_JP.UTF-8" and |
389 | still use your input method. Please note, however, that you will not |
546 | still use your input method. Please note, however, that you will not |
390 | be able to input characters outside "EUC-JP" in a normal way then, |
547 | be able to input characters outside "EUC-JP" in a normal way then, |
391 | as your input method limits you. |
548 | as your input method limits you. |
392 | |
549 | |
|
|
550 | Rxvt-unicode crashes when the X Input Method changes or exits. |
|
|
551 | Unfortunately, this is unavoidable, as the XIM protocol is racy by |
|
|
552 | design. Applications can avoid some crashes at the expense of memory |
|
|
553 | leaks, and Input Methods can avoid some crashes by careful ordering |
|
|
554 | at exit time. kinput2 (and derived input methods) generally |
|
|
555 | succeeds, while SCIM (or similar input methods) fails. In the end, |
|
|
556 | however, crashes cannot be completely avoided even if both sides |
|
|
557 | cooperate. |
|
|
558 | |
|
|
559 | So the only workaround is not to kill your Input Method Servers. |
|
|
560 | |
393 | Rxvt-unicode uses gobs of memory, how can I reduce that? |
561 | Rxvt-unicode uses gobs of memory, how can I reduce that? |
394 | Rxvt-unicode tries to obey the rule of not charging you for |
562 | Rxvt-unicode tries to obey the rule of not charging you for |
395 | something you don't use. One thing you should try is to configure |
563 | something you don't use. One thing you should try is to configure |
396 | out all settings that you don't need, for example, Xft support is a |
564 | out all settings that you don't need, for example, Xft support is a |
397 | resource hog by design, when used. Compiling it out ensures that no |
565 | resource hog by design, when used. Compiling it out ensures that no |
… | |
… | |
406 | it gets worse, as rxvt-unicode then uses 8 bytes per screen cell. |
574 | it gets worse, as rxvt-unicode then uses 8 bytes per screen cell. |
407 | |
575 | |
408 | Can I speed up Xft rendering somehow? |
576 | Can I speed up Xft rendering somehow? |
409 | Yes, the most obvious way to speed it up is to avoid Xft entirely, |
577 | Yes, the most obvious way to speed it up is to avoid Xft entirely, |
410 | as it is simply slow. If you still want Xft fonts you might try to |
578 | as it is simply slow. If you still want Xft fonts you might try to |
411 | disable antialiasing (by appending ":antialiasing=false"), which |
579 | disable antialiasing (by appending ":antialias=false"), which saves |
412 | saves lots of memory and also speeds up rendering considerably. |
580 | lots of memory and also speeds up rendering considerably. |
413 | |
581 | |
414 | Rxvt-unicode doesn't seem to anti-alias its fonts, what is wrong? |
582 | Rxvt-unicode doesn't seem to anti-alias its fonts, what is wrong? |
415 | Rxvt-unicode will use whatever you specify as a font. If it needs to |
583 | Rxvt-unicode will use whatever you specify as a font. If it needs to |
416 | fall back to it's default font search list it will prefer X11 core |
584 | fall back to it's default font search list it will prefer X11 core |
417 | fonts, because they are small and fast, and then use Xft fonts. It |
585 | fonts, because they are small and fast, and then use Xft fonts. It |
… | |
… | |
489 | URxvt.color14: #73f7ff |
657 | URxvt.color14: #73f7ff |
490 | URxvt.color7: #e1dddd |
658 | URxvt.color7: #e1dddd |
491 | URxvt.color15: #e1dddd |
659 | URxvt.color15: #e1dddd |
492 | |
660 | |
493 | How can I start rxvtd in a race-free way? |
661 | How can I start rxvtd in a race-free way? |
494 | Despite it's name, rxvtd is not a real daemon, but more like a |
662 | Try "rxvtd -f -o", which tells rxvtd to open the display, create the |
495 | server that answers rxvtc's requests, so it doesn't background |
663 | listening socket and then fork. |
496 | itself. |
|
|
497 | |
|
|
498 | To ensure rxvtd is listening on it's socket, you can use the |
|
|
499 | following method to wait for the startup message before continuing: |
|
|
500 | |
|
|
501 | { rxvtd & } | read |
|
|
502 | |
664 | |
503 | What's with the strange Backspace/Delete key behaviour? |
665 | What's with the strange Backspace/Delete key behaviour? |
504 | Assuming that the physical Backspace key corresponds to the |
666 | Assuming that the physical Backspace key corresponds to the |
505 | BackSpace keysym (not likely for Linux ... see the following |
667 | BackSpace keysym (not likely for Linux ... see the following |
506 | question) there are two standard values that can be used for |
668 | question) there are two standard values that can be used for |