Merge from emacs-23 branch, up to 2010-05-20T22:16:19Z!juri@jurta.org.

[bpt/emacs.git] / etc / PROBLEMS

diff --git a/etc/PROBLEMS b/etc/PROBLEMS
index 093d815..7e856c1 100644 (file)
--- a/etc/PROBLEMS
+++ b/etc/PROBLEMS
@@ -1,7 +1,7 @@
 Known Problems with GNU Emacs
 
 Copyright (C) 1987, 1988, 1989, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-  2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
+  2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011
   Free Software Foundation, Inc.
 See the end of the file for license conditions.
 
@@ -102,7 +102,7 @@ This can be another symptom of stale *.elc files in your load-path.
 The following command will print any duplicate Lisp files that are
 present in load-path:
 
-    emacs -q -batch -f list-load-path-shadows
+    emacs -batch -f list-load-path-shadows
 
 If this command prints any file names, some of these files are stale,
 and should be deleted or their directories removed from your
@@ -235,19 +235,18 @@ necessary but missing, please report it via M-x report-emacs-bug.
 On platforms such as Solaris, you can also work around this problem by
 configuring your compiler to use the native linker instead of GNU ld.
 
-** Emacs compiled with Gtk+ crashes when closing a display (x-close-connection).
+** When Emacs is compiled with Gtk+, closing a display kills Emacs.
 
-This happens because of bugs in Gtk+.  Gtk+ 2.10 seems to be OK.  See bug
-http://bugzilla.gnome.org/show_bug.cgi?id=85715.
+There is a long-standing bug in GTK that prevents it from recovering
+from disconnects: http://bugzilla.gnome.org/show_bug.cgi?id=85715.
 
-** Emacs compiled with Gtk+ may loop forever if a display crashes.
+Thus, for instance, when Emacs is run as a server on a text terminal,
+and an X frame is created, and the X server for that frame crashes or
+exits unexpectedly, Emacs must exit to prevent a GTK error that would
+result in an endless loop.
 
-This is related to the bug above.  A scenario for this is when emacs is run
-as a server, and an X frame is created.  If the X server for the frame
-crashes or exits unexpectedly and an attempt is made to create a new
-frame on another X display, then a Gtk+ error happens in the emacs
-server that results in an endless loop.  This is not fixed in any known
-Gtk+ version (2.14.4 being current).
+If you need Emacs to be able to recover from closing displays, compile
+it with the Lucid toolkit instead of GTK.
 
 * General runtime problems
 
@@ -1661,6 +1660,19 @@ the script:
 exec 2> >(exec cat >&2 2>/dev/null)
 exec ssh "$@"
 
+*** GNU/Linux: Truncated svn annotate output with SSH.
+http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7791
+
+The symptoms are: you are accessing a svn repository over SSH.
+You use vc-annotate on a large (several thousand line) file, and the
+result is truncated around the 1000 line mark.  It works fine with
+other access methods (eg http), or from outside Emacs.
+
+This may be a similar libc/SSH issue to the one mentioned above for CVS.
+A similar workaround seems to be effective: create a script with the
+same contents as the one used above for CVS_RSH, and set the SVN_SSH
+environment variable to point to it.
+
 *** GNU/Linux: On Linux-based GNU systems using libc versions 5.4.19 through
 5.4.22, Emacs crashes at startup with a segmentation fault.
 
@@ -3245,5 +3257,3 @@ Local variables:
 mode: outline
 paragraph-separate: "[  \f]*$"
 end:
-
-arch-tag: 49fc0d95-88cb-4715-b21c-f27fb5a4764a