QUERY
Aidan> That's not true. The X code, while filled with calls to
Aidan> ABORT(), only calls it in truly exceptional conditions,
Aidan> that indicate programming errors somewhere, the sort of
Aidan> place where an assertion would be a better choice since the
Aidan> check can be turned off in a production build. This patch
Aidan> changes them to assertions
I really, really am scared by this. If these conditions should
manifest, there's big trouble ahead. Internal X11 code is not subject
to XEmacs coding discipline, is very difficult to debug, and generally
is very poorly behaved under stress. We do not want X11 internal code
called at all in any of these circumstances; if we don't think they're
continuable in a beta test version, why should we risk user data by
continuing in a production version?
BTW, there's gratuitous whitespace corruption in this hunk:
Index: src/event-Xt.c
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/event-Xt.c,v
retrieving revision 1.91
diff -u -u -r1.91 event-Xt.c
--- src/event-Xt.c 2005/12/24 19:54:01 1.91
+++ src/event-Xt.c 2006/06/25 10:13:10
@@ -1122,7 +1122,7 @@
This _might_ be possible within an XKB framework, changing
the keyboard to a US XKB layout for a moment at startup,
- storing the correspondance, and changing it back. But that
+ storing the correspondence, and changing it back. But that
won't work on non-XKB servers, it makes our already slow
startup slower, and it's not clear that it's really any
easier or more maintainable than storing a correspondence in
--
School of Systems and Information Engineering
http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.