… | |
… | |
24 | |
24 | |
25 | =head1 FREQUENTLY ASKED QUESTIONS |
25 | =head1 FREQUENTLY ASKED QUESTIONS |
26 | |
26 | |
27 | =over 4 |
27 | =over 4 |
28 | |
28 | |
|
|
29 | =item Isn't rxvt supposed to be small? Don't all those features bloat? |
|
|
30 | |
|
|
31 | I often get asked about this, and I think, no, they didn't cause extra |
|
|
32 | bloat. If you compare a minimal rxvt and a minimal urxvt, you can see |
|
|
33 | that the urxvt binary is larger (due to some encoding tables always being |
|
|
34 | compiled in), but it actually uses less memory (RSS) after startup. Even |
|
|
35 | with C<--disable-everything>, this comparison is a bit unfair, as many |
|
|
36 | features unique to urxvt (locale, encoding conversion, iso14755 etc.) are |
|
|
37 | already in use in this mode. |
|
|
38 | |
|
|
39 | text data bss drs rss filename |
|
|
40 | 98398 1664 24 15695 1824 rxvt --disable-everything |
|
|
41 | 188985 9048 66616 18222 1788 urxvt --disable-everything |
|
|
42 | |
|
|
43 | When you C<--enable-everything> (which _is_ unfair, as this involves xft |
|
|
44 | and full locale/XIM support which are quite bloaty inside libX11 and my |
|
|
45 | libc), the two diverge, but not unreasnobaly so. |
|
|
46 | |
|
|
47 | text data bss drs rss filename |
|
|
48 | 163431 2152 24 20123 2060 rxvt --enable-everything |
|
|
49 | 1035683 49680 66648 29096 3680 urxvt --enable-everything |
|
|
50 | |
|
|
51 | The very large size of the text section is explained by the east-asian |
|
|
52 | encoding tables, which, if unused, take up disk space but nothing else |
|
|
53 | and can be compiled out unless you rely on X11 core fonts that use those |
|
|
54 | encodings. The BSS size comes from the 64k emergency buffer that my c++ |
|
|
55 | compiler allocates (but of course doesn't use unless you are out of |
|
|
56 | memory). Also, using an xft font instead of a core font immediately adds a |
|
|
57 | few megabytes of RSS. Xft indeed is responsible for a lot of RSS even when |
|
|
58 | not used. |
|
|
59 | |
|
|
60 | Of course, due to every character using two or four bytes instead of one, |
|
|
61 | a large scrollback buffer will ultimately make rxvt-unicode use more |
|
|
62 | memory. |
|
|
63 | |
|
|
64 | Compared to e.g. Eterm (5112k), aterm (3132k) and xterm (4680k), this |
|
|
65 | still fares rather well. And compared to some monsters like gnome-terminal |
|
|
66 | (21152k + extra 4204k in separate processes) or konsole (22200k + extra |
|
|
67 | 43180k in daemons that stay around after exit, plus half aminute of |
|
|
68 | startup time, including the hundreds of warnings it spits out), it fares |
|
|
69 | extremely well *g*. |
|
|
70 | |
|
|
71 | =item Why C++, isn't that unportable/bloated/uncool? |
|
|
72 | |
|
|
73 | Is this a question? :) It comes up very often. The simple answer is: I had |
|
|
74 | to write it, and C++ allowed me to write and maintain it in a fraction |
|
|
75 | of the time and effort (which is a scarce resource for me). Put even |
|
|
76 | shorter: It simply wouldn't exist without C++. |
|
|
77 | |
|
|
78 | My personal stance on this is that C++ is less portable than C, but in |
|
|
79 | the case of rxvt-unicode this hardly matters, as its portability limits |
|
|
80 | are defined by things like X11, pseudo terminals, locale support and unix |
|
|
81 | domain sockets, which are all less portable than C++ itself. |
|
|
82 | |
|
|
83 | Regarding the bloat, see the above question: It's easy to write programs |
|
|
84 | in C that use gobs of memory, an certainly possible to write programs in |
|
|
85 | C++ that don't. C++ also often comes with large libraries, but this is |
|
|
86 | not necessarily the case with GCC. Here is what rxvt links against on my |
|
|
87 | system with a minimal config: |
|
|
88 | |
|
|
89 | libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x00002aaaaabc3000) |
|
|
90 | libc.so.6 => /lib/libc.so.6 (0x00002aaaaadde000) |
|
|
91 | libdl.so.2 => /lib/libdl.so.2 (0x00002aaaab01d000) |
|
|
92 | /lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000) |
|
|
93 | |
|
|
94 | And here is rxvt-unicode: |
|
|
95 | |
|
|
96 | libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x00002aaaaabc3000) |
|
|
97 | libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00002aaaaada2000) |
|
|
98 | libc.so.6 => /lib/libc.so.6 (0x00002aaaaaeb0000) |
|
|
99 | libdl.so.2 => /lib/libdl.so.2 (0x00002aaaab0ee000) |
|
|
100 | /lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000) |
|
|
101 | |
|
|
102 | No large bloated libraries (of course, none were linked in statically), |
|
|
103 | except maybe libX11 :) |
|
|
104 | |
|
|
105 | =item Does it support tabs, can I have a tabbed rxvt-unicode? |
|
|
106 | |
|
|
107 | rxvt-unicode does not directly support tabs. It will work fine with |
|
|
108 | tabbing functionality of many window managers or similar tabbing programs, |
|
|
109 | and its embedding-features allow it to be embedded into other programs, |
|
|
110 | as witnessed by F<doc/rxvt-tabbed> or the upcoming C<Gtk2::URxvt> perl |
|
|
111 | module, which features a tabbed urxvt (murxvt) terminal as an example |
|
|
112 | embedding application. |
|
|
113 | |
29 | =item How do I know which rxvt-unicode version I'm using? |
114 | =item How do I know which rxvt-unicode version I'm using? |
30 | |
115 | |
31 | The version number is displayed with the usage (-h). Also the escape |
116 | The version number is displayed with the usage (-h). Also the escape |
32 | sequence C<ESC [ 8 n> sets the window title to the version number. |
117 | sequence C<ESC [ 8 n> sets the window title to the version number. When |
|
|
118 | using the @@RXVT_NAME@@c client, the version displayed is that of the |
|
|
119 | daemon. |
33 | |
120 | |
34 | =item I am using Debian GNU/Linux and have a problem... |
121 | =item I am using Debian GNU/Linux and have a problem... |
35 | |
122 | |
36 | The Debian GNU/Linux package of rxvt-unicode in sarge contains large |
123 | The Debian GNU/Linux package of rxvt-unicode in sarge contains large |
37 | patches that considerably change the behaviour of rxvt-unicode. Before |
124 | patches that considerably change the behaviour of rxvt-unicode. Before |