TODO: manpage 900mb update
-TODO: maybe just output the error and continue on x errors, especially for XIM-management
TODO: safer command: keymap processing.
TODO: read property sequence is broken with respect to utf-8 etc.
WISH: keyboard modification via esc-sequences.
- fix a bug when parsing fontnames and another one
for empty keymaps which could result in crashes
(Kuang-che Wu).
+ - only warn on X errors, *try* to continue (frills).
- add COPYING back, which got lost somehow.
5.0 Fri Feb 11 18:31:48 CET 2005
be able to input characters outside "EUC-JP" in a normal way then,
as your input method limits you.
+ Rxvt-unicode crashes when the X Input Method changes or exits.
+ Unfortunately, this is unavoidable, as the XIM protocol is racy by
+ design. Applications can avoid some crashes at the expense of memory
+ leaks, and Input Methods can avoid some crashes by careful ordering
+ at exit time. kinput2 (and derived input methods) generally
+ succeeds, while SCIM (or similar input methods) fails. In the end,
+ however, crashes cannot be completely avoided even if both sides
+ cooperate.
+
+ So the only workaround is not to kill your Input Method Servers.
+
Rxvt-unicode uses gobs of memory, how can I reduce that?
Rxvt-unicode tries to obey the rule of not charging you for
something you don't use. One thing you should try is to configure
method limits you.</p>
</dd>
<p></p>
+<dt><strong><a name="item_rxvt_2dunicode_crashes_when_the_x_input_method_cha">Rxvt-unicode crashes when the X Input Method changes or exits.</a></strong><br />
+</dt>
+<dd>
+Unfortunately, this is unavoidable, as the XIM protocol is racy by
+design. Applications can avoid some crashes at the expense of memory
+leaks, and Input Methods can avoid some crashes by careful ordering at
+exit time. <strong>kinput2</strong> (and derived input methods) generally succeeds,
+while <strong>SCIM</strong> (or similar input methods) fails. In the end, however,
+crashes cannot be completely avoided even if both sides cooperate.
+</dd>
+<dd>
+<p>So the only workaround is not to kill your Input Method Servers.</p>
+</dd>
+<p></p>
<dt><strong><a name="item_rxvt_2dunicode_uses_gobs_of_memory_2c_how_can_i_re">Rxvt-unicode uses gobs of memory, how can I reduce that?</a></strong><br />
</dt>
<dd>
.\" ========================================================================
.\"
.IX Title "rxvt 7"
-.TH rxvt 7 "2005-02-11" "5.0" "RXVT-UNICODE"
+.TH rxvt 7 "2005-02-13" "5.1" "RXVT-UNICODE"
.SH "NAME"
RXVT REFERENCE \- FAQ, command sequences and other background information
.SH "SYNOPSIS"
use your input method. Please note, however, that you will not be able to
input characters outside \f(CW\*(C`EUC\-JP\*(C'\fR in a normal way then, as your input
method limits you.
+.IP "Rxvt-unicode crashes when the X Input Method changes or exits." 4
+.IX Item "Rxvt-unicode crashes when the X Input Method changes or exits."
+Unfortunately, this is unavoidable, as the \s-1XIM\s0 protocol is racy by
+design. Applications can avoid some crashes at the expense of memory
+leaks, and Input Methods can avoid some crashes by careful ordering at
+exit time. \fBkinput2\fR (and derived input methods) generally succeeds,
+while \fB\s-1SCIM\s0\fR (or similar input methods) fails. In the end, however,
+crashes cannot be completely avoided even if both sides cooperate.
+.Sp
+So the only workaround is not to kill your Input Method Servers.
.IP "Rxvt-unicode uses gobs of memory, how can I reduce that?" 4
.IX Item "Rxvt-unicode uses gobs of memory, how can I reduce that?"
Rxvt-unicode tries to obey the rule of not charging you for something you
input characters outside C<EUC-JP> in a normal way then, as your input
method limits you.
+=item Rxvt-unicode crashes when the X Input Method changes or exits.
+
+Unfortunately, this is unavoidable, as the XIM protocol is racy by
+design. Applications can avoid some crashes at the expense of memory
+leaks, and Input Methods can avoid some crashes by careful ordering at
+exit time. B<kinput2> (and derived input methods) generally succeeds,
+while B<SCIM> (or similar input methods) fails. In the end, however,
+crashes cannot be completely avoided even if both sides cooperate.
+
+So the only workaround is not to kill your Input Method Servers.
+
=item Rxvt-unicode uses gobs of memory, how can I reduce that?
Rxvt-unicode tries to obey the rule of not charging you for something you
be able to input characters outside "EUC-JP" in a normal way then,
as your input method limits you.
+ Rxvt-unicode crashes when the X Input Method changes or exits.
+ Unfortunately, this is unavoidable, as the XIM protocol is racy by
+ design. Applications can avoid some crashes at the expense of memory
+ leaks, and Input Methods can avoid some crashes by careful ordering
+ at exit time. kinput2 (and derived input methods) generally
+ succeeds, while SCIM (or similar input methods) fails. In the end,
+ however, crashes cannot be completely avoided even if both sides
+ cooperate.
+
+ So the only workaround is not to kill your Input Method Servers.
+
Rxvt-unicode uses gobs of memory, how can I reduce that?
Rxvt-unicode tries to obey the rule of not charging you for
something you don't use. One thing you should try is to configure
(*t)->emergency_cleanup ();
}
+#if ENABLE_FRILLS
+static void
+print_x_error (Display *dpy, XErrorEvent *event)
+{
+ char buffer[BUFSIZ];
+ char mesg[BUFSIZ];
+ char number[32];
+ char *mtype = "XlibMessage";
+ XGetErrorText(dpy, event->error_code, buffer, BUFSIZ);
+ XGetErrorDatabaseText(dpy, mtype, "XError", "X Error", mesg, BUFSIZ);
+ rxvt_warn ("An X Error occured, trying to continue after report.\n");
+ rxvt_warn ("%s: %s\n", mesg, buffer);
+ XGetErrorDatabaseText(dpy, mtype, "MajorCode", "Request Major code %d", mesg, BUFSIZ);
+ rxvt_warn (strncat (mesg, "\n", BUFSIZ), event->request_code);
+ sprintf(number, "%d", event->request_code);
+ XGetErrorDatabaseText(dpy, "XRequest", number, "", buffer, BUFSIZ);
+ rxvt_warn ("(which is %s)\n", buffer);
+ if (event->request_code >= 128) {
+ XGetErrorDatabaseText(dpy, mtype, "MinorCode", "Request Minor code %d",
+ mesg, BUFSIZ);
+ rxvt_warn (strncat (mesg, "\n", BUFSIZ), event->minor_code);
+ }
+ if ((event->error_code == BadWindow) ||
+ (event->error_code == BadPixmap) ||
+ (event->error_code == BadCursor) ||
+ (event->error_code == BadFont) ||
+ (event->error_code == BadDrawable) ||
+ (event->error_code == BadColor) ||
+ (event->error_code == BadGC) ||
+ (event->error_code == BadIDChoice) ||
+ (event->error_code == BadValue) ||
+ (event->error_code == BadAtom)) {
+ if (event->error_code == BadValue)
+ XGetErrorDatabaseText(dpy, mtype, "Value", "Value 0x%x",
+ mesg, BUFSIZ);
+ else if (event->error_code == BadAtom)
+ XGetErrorDatabaseText(dpy, mtype, "AtomID", "AtomID 0x%x",
+ mesg, BUFSIZ);
+ else
+ XGetErrorDatabaseText(dpy, mtype, "ResourceID", "ResourceID 0x%x",
+ mesg, BUFSIZ);
+ rxvt_warn (strncat (mesg, "\n", BUFSIZ), event->resourceid);
+ }
+ XGetErrorDatabaseText(dpy, mtype, "ErrorSerial", "Error Serial #%d",
+ mesg, BUFSIZ);
+ rxvt_warn (strncat (mesg, "\n", BUFSIZ), event->serial);
+}
+#endif
+
int
rxvt_xerror_handler (Display *display, XErrorEvent *event)
{
{
//TODO: GET_R is most likely not the terminal which caused the error
//TODO: maybe just output the error and continue?
+#if ENABLE_FRILLS
+ print_x_error (display, event);
+#else
old_xerror_handler (display, event);
- GET_R->destroy ();
+#endif
}
return 0;
char **s;
char buf[IMBUFSIZ];
+ SET_R (this);
+
im_destroy ();
D_MAIN ((stderr, "rxvt_IMInstantiateCallback ()"));
void rxvt_display::im_change_check ()
{
- // make sure we only call im_change_cb when a new input method
+ // try to only call im_change_cb when a new input method
// registers, as xlib crashes due to a race otherwise.
Atom actual_type, *atoms;
int actual_format;
projects / dana / urxvt.git / commitdiff