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 aminute 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 in sarge contains large |
92 | The Debian GNU/Linux package of rxvt-unicode in sarge contains large |
8 | patches that considerably change the behaviour of rxvt-unicode. |
93 | patches that considerably change the behaviour of rxvt-unicode. |
9 | Before reporting a bug to the original rxvt-unicode author please |
94 | Before reporting a bug to the original rxvt-unicode author please |
… | |
… | |
448 | it gets worse, as rxvt-unicode then uses 8 bytes per screen cell. |
533 | it gets worse, as rxvt-unicode then uses 8 bytes per screen cell. |
449 | |
534 | |
450 | Can I speed up Xft rendering somehow? |
535 | Can I speed up Xft rendering somehow? |
451 | Yes, the most obvious way to speed it up is to avoid Xft entirely, |
536 | Yes, the most obvious way to speed it up is to avoid Xft entirely, |
452 | as it is simply slow. If you still want Xft fonts you might try to |
537 | as it is simply slow. If you still want Xft fonts you might try to |
453 | disable antialiasing (by appending ":antialiasing=false"), which |
538 | disable antialiasing (by appending ":antialias=false"), which saves |
454 | saves lots of memory and also speeds up rendering considerably. |
539 | lots of memory and also speeds up rendering considerably. |
455 | |
540 | |
456 | Rxvt-unicode doesn't seem to anti-alias its fonts, what is wrong? |
541 | Rxvt-unicode doesn't seem to anti-alias its fonts, what is wrong? |
457 | Rxvt-unicode will use whatever you specify as a font. If it needs to |
542 | Rxvt-unicode will use whatever you specify as a font. If it needs to |
458 | fall back to it's default font search list it will prefer X11 core |
543 | fall back to it's default font search list it will prefer X11 core |
459 | fonts, because they are small and fast, and then use Xft fonts. It |
544 | fonts, because they are small and fast, and then use Xft fonts. It |
… | |
… | |
531 | URxvt.color14: #73f7ff |
616 | URxvt.color14: #73f7ff |
532 | URxvt.color7: #e1dddd |
617 | URxvt.color7: #e1dddd |
533 | URxvt.color15: #e1dddd |
618 | URxvt.color15: #e1dddd |
534 | |
619 | |
535 | How can I start rxvtd in a race-free way? |
620 | How can I start rxvtd in a race-free way? |
536 | Despite it's name, rxvtd is not a real daemon, but more like a |
621 | Try "rxvtd -f -o", which tells rxvtd to open the display, create the |
537 | server that answers rxvtc's requests, so it doesn't background |
622 | listening socket and then fork. |
538 | itself. |
|
|
539 | |
|
|
540 | To ensure rxvtd is listening on it's socket, you can use the |
|
|
541 | following method to wait for the startup message before continuing: |
|
|
542 | |
|
|
543 | { rxvtd & } | read |
|
|
544 | |
623 | |
545 | What's with the strange Backspace/Delete key behaviour? |
624 | What's with the strange Backspace/Delete key behaviour? |
546 | Assuming that the physical Backspace key corresponds to the |
625 | Assuming that the physical Backspace key corresponds to the |
547 | BackSpace keysym (not likely for Linux ... see the following |
626 | BackSpace keysym (not likely for Linux ... see the following |
548 | question) there are two standard values that can be used for |
627 | question) there are two standard values that can be used for |