--- a/man/xemacs-faq.texi	Thu Jan 02 22:52:44 2003 +0000
+++ b/man/xemacs-faq.texi	Fri Jan 03 12:12:40 2003 +0000
@@ -7,7 +7,7 @@
 @finalout
 @titlepage
 @title XEmacs FAQ
-@subtitle Frequently asked questions about XEmacs @* Last Modified: $Date: 2002/12/04 14:06:04 $
+@subtitle Frequently asked questions about XEmacs @* Last Modified: $Date: 2003/01/03 12:12:30 $
 @sp 1
 @author Tony Rossini <rossini@@biostat.washington.edu>
 @author Ben Wing <ben@@xemacs.org>
@@ -1500,6 +1500,11 @@
 buggy optimizers.  Please see the @file{PROBLEMS} file that comes with
 XEmacs to read what it says about your platform.
 
+If you compiled XEmacs using @samp{--use-union-type} (or the option
+@samp{USE_UNION_TYPE} in @file{config.inc} under Windows), recompile
+again without this.  This has been known to trigger compiler errors in a
+number of cases.
+
 @node Q2.0.7, Q2.0.8, Q2.0.6, Installation
 @unnumberedsubsec Q2.0.7: Libraries in non-standard locations
 
@@ -1802,18 +1807,29 @@
 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 @email{crashes@@xemacs.org}.
-Please note that the @samp{crashes} address is exclusively for crash
+maintainers would be very interested in knowing about it.  The best way
+to report a bug is using @kbd{M-x report-emacs-bug} (or by selecting
+@samp{Send Bug Report...} from the Help menu).  If that won't work
+(e.g. you can't get XEmacs working at all), send ordinary mail to
+@email{crashes@@xemacs.org}. @emph{MAKE SURE} to include the output from
+the crash, especially including the Lisp backtrace, as well as the
+XEmacs configuration from @kbd{M-x describe-installation} (or
+equivalently, the file @file{Installation} in the top of the build
+tree).  Please note that the @samp{crashes} address is exclusively for
+crash reports.  The best way to report bugs in general is through the
+@kbd{M-x report-emacs-bug} interface just mentioned, or if necessary by
+emailing @email{xemacs-beta@@xemacs.org}.  Note that the developers do
+@emph{not} usually follow @samp{comp.emacs.xemacs} on a regular basis;
+thus, this is better for general questions about XEmacs than bug
 reports.
 
-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 @file{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:
+If at all possible, include a C 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 under Unix, you need to
+locate the core file (it's called @file{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:
 
 @example
 gdb `which xemacs` core
@@ -1829,6 +1845,13 @@
 to disable core files by default.  Also see @ref{Q2.1.15}, for tips and
 techniques for dealing with a debugger.
 
+If you're under Microsoft Windows, you're out of luck unless you happen
+to have a debugging aid installed on your system, for example Visual
+C++.  In this case, the crash will result in a message giving you the
+option to enter a debugger (for example, by pressing @samp{Cancel}).  Do
+this and locate the stack-trace window. (If your XEmacs was built
+without debugging information, the stack trace may not be very useful.)
+
 When making a problem report make sure that:
 
 @enumerate
@@ -1846,12 +1869,12 @@
 What build options you are using.
 
 @item
-If the problem is related to graphics, we will also need to know what
-version of the X Window System you are running, and what window manager
-you are using.
-
-@item
-If the problem happened on a tty, please include the terminal type.
+If the problem is related to graphics and you are running Unix, we will
+also need to know what version of the X Window System you are running,
+and what window manager you are using.
+
+@item
+If the problem happened on a TTY, please include the terminal type.
 @end enumerate
 
 Much of the information above is automatically generated by @kbd{M-x
@@ -2237,7 +2260,7 @@
 decode them, do this:
 
 @example
-call debug_print (OBJECT)
+call dp (OBJECT)
 @end example
 
 where @var{OBJECT} is whatever you want to decode (it can be a variable,
@@ -2249,14 +2272,14 @@
 stack, do this:
 
 @example
-call debug_backtrace ()
+call db ()
 @end example
 
 @item
-Using @code{debug_print} and @code{debug_backtrace} has two
-disadvantages - it can only be used with a running xemacs process, and
-it cannot display the internal C structure of a Lisp Object.  Even if
-all you've got is a core dump, all is not lost.
+Using @code{dp} and @code{db} has two disadvantages - it can only be
+used with a running xemacs process, and it cannot display the internal C
+structure of a Lisp Object.  Even if all you've got is a core dump, all
+is not lost.
 
 If you're using GDB, there are some macros in the file
 @file{src/.gdbinit} in the XEmacs source distribution that should make
@@ -2319,8 +2342,8 @@
 running the XEmacs process under a debugger, the stack trace should be
 clean.
 
-@email{1CMC3466@@ibm.mtsac.edu, Curtiss} suggests upgrading to ld.so version 1.8
-if dynamic linking and debugging is a problem on Linux.
+@email{1CMC3466@@ibm.mtsac.edu, Curtiss} suggests upgrading to ld.so
+version 1.8 if dynamic linking and debugging is a problem on Linux.
 
 @item
 If you're using a debugger to get a C stack backtrace and you're
@@ -2344,9 +2367,9 @@
 could simply mean that XEmacs attempted to execute code at that address,
 e.g. through jumping to a null function pointer.  Unfortunately, under
 those circumstances, GDB under Linux doesn't know how to get a stack
-trace. (Yes, this is the third Linux-related problem I've mentioned.  I
+trace. (Yes, this is the fourth Linux-related problem I've mentioned.  I
 have no idea why GDB under Linux is so bogus.  Complain to the GDB
-authors, or to comp.os.linux.development.system).  Again, you'll have to
+authors, or to comp.os.linux.development.system.) Again, you'll have to
 use the narrowing-down process described above.
 
 @item
@@ -2365,6 +2388,10 @@
 @file{src/gdbinit}.  This had the disadvantage of not being sourced
 automatically by gdb, so you had to set that up yourself.
 
+@item
+If you are running Microsoft Windows, the the file @file{nt/README} for
+further information about debugging XEmacs.
+
 @end itemize
 
 @node Q2.1.16, Q2.1.17, Q2.1.15, Installation