First of all, don't panic. Whenever XEmacs crashes, it tries extremely hard to auto-save all of your files before dying. (The main time that this will not happen is if the machine physically lost power or if you killed the XEmacs process using `kill -9'.) The next time you try to edit those files, you will be informed that a more recent auto-save file exists. You can use M-x recover-file to retrieve the auto-saved version of the file.
Now, XEmacs is not perfect, and there may occasionally be times, or particular sequences of actions, that cause it to crash. If you can come up with a reproducible way of doing this (or even if you have a pretty good memory of exactly what you were doing at the time), the maintainers would be very interested in knowing about it. Post a message to `comp.emacs.xemacs' or send mail to `xemacs@cs.uiuc.edu'.
If at all possible, include a stack backtrace of the core dump that was produced. This shows where exactly things went wrong, and makes it much easier to diagnose problems. To do this, you need to locate the core file (it's called `core', and is usually sitting in the directory that you started XEmacs from, or your home directory if that other directory was not writable). Then, go to that directory and execute a command like
gdb `which xemacs` core
and then issue the command `where' to get the stack backtrace. (You might have to use `dbx' or some similar debugger in place of `gdb'. If you don't have any such debugger available, complain to your system administrator.)
It's possible that a core file didn't get produced, in which case you're out of luck. Go complain to your system administrator and tell him not to disable core files by default. (If you explicitly disabled core files, then double shame on you!)
If you can't figure out what's going on, try typing ESC ESC and issuing the command
(setq debug-on-error t)
and then try and make the error happen again. This will give you a backtrace that may be enlightening. If not, try reading farther down in this FAQ; if that fails, you could try posting to `comp.emacs.xemacs' (making sure to include the backtrace) and someone may be able to help.
There are two causes of this problem. The first usually only strikes people using the prebuilt binaries. The culprit in both cases is the file `XKeysymDB'.
<xemacs_root_directory>/lib/xemacs-19.13/etc/XKeysymDB
This is highly dependent on your installation, but try with the following font as your base font for XEmacs and see what it does:
-adobe-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-1
More precisely, do the following in your resource file:
Emacs.default.attributeFont: -adobe-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-1
Try setting the DISPLAY variable using the numeric IP address of the host you are running XEmacs from.
Because they are not. You are probably trying to read some HTML files, or using W3-mode as your Web client. To display inline pictures, this requires the above programs (which can be found in the netpbm package or its older version, pbmplus). The netpbm package can be found at ftp.x.org:/contrib/utilities/ . It can also be found at ftp.cs.uiuc.edu:/pub/xemacs/aux/
Try the following Emacs-Lisp:
(setq version-control t) (setq kept-old-versions 0) (setq kept-new-versions 8) (if (string-match "XEmacs\\|Lucid" emacs-version) (setq trim-versions-without-asking t) (setq delete-old-versions t))
There have been several reports of the X server locking up under Linux. In all reported cases removing speedo and scaled fonts from the font path corrected the problem. This can be done with the command 'xset'.
It is possible that using a font server may also solve the problem.