ChangeLog fixes
[bpt/emacs.git] / etc / PROBLEMS
index 7e856c1..675644f 100644 (file)
@@ -1,7 +1,6 @@
 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, 2011
+Copyright (C) 1987-1989, 1993-1999, 2001-2012
   Free Software Foundation, Inc.
 See the end of the file for license conditions.
 
@@ -172,6 +171,14 @@ optimization.  To do this, configure Emacs with
 
  CFLAGS="-g -O2 -fno-optimize-sibling-calls" ./configure
 
+** Emacs compiled with GCC 4.6.1 crashes on MS-Windows when C-g is pressed
+
+This is known to happen when Emacs is compiled with MinGW GCC 4.6.1
+with the -O2 option (which is the default in the Windows build).  The
+reason is a bug in MinGW GCC 4.6.1; to work around, either add the
+`-fno-omit-frame-pointer' switch to GCC or compile without
+optimizations (`--no-opt' switch to the configure.bat script).
+
 ** Emacs crashes in x-popup-dialog.
 
 This can happen if the dialog widget cannot find the font it wants to
@@ -345,7 +352,7 @@ There are two different protocols in general use.  One of them uses
 the `flock' system call.  The other involves creating a lock file;
 `movemail' must be able to write in /usr/spool/mail in order to do
 this.  You control which one is used by defining, or not defining,
-the macro MAIL_USE_FLOCK in config.h or the m- or s- file it includes.
+the macro MAIL_USE_FLOCK in config.h or the m/ or s/ file it includes.
 IF YOU DON'T USE THE FORM OF INTERLOCKING THAT IS NORMAL ON YOUR
 SYSTEM, YOU CAN LOSE MAIL!
 
@@ -504,6 +511,12 @@ This can happen with CVS versions 1.12.8 and 1.12.9.  Upgrade to CVS
 
 ** Miscellaneous problems
 
+*** Editing files with very long lines is slow.
+
+For example, simply moving through a file that contains hundreds of
+thousands of characters per line is slow, and consumes a lot of CPU.
+This is a known limitation of Emacs with no solution at this time.
+
 *** Emacs uses 100% of CPU time
 
 This is a known problem with some versions of the Semantic package.
@@ -1218,7 +1231,7 @@ be carried out at the same time:
 2) If the connection is very slow, you might also want to consider
    switching off scroll bars, menu bar, and tool bar.  Adding the
    following forms to your .emacs file will accomplish that, but only
-   after the the initial frame is displayed:
+   after the initial frame is displayed:
 
     (scroll-bar-mode -1)
     (menu-bar-mode -1)
@@ -1237,7 +1250,7 @@ be carried out at the same time:
 4) Use lbxproxy on the remote end of the connection.  This is an interface
    to the low bandwidth X extension in most modern X servers, which
    improves performance dramatically, at the slight expense of correctness
-   of the X protocol.  lbxproxy acheives the performance gain by grouping
+   of the X protocol.  lbxproxy achieves the performance gain by grouping
    several X requests in one TCP packet and sending them off together,
    instead of requiring a round-trip for each X request in a separate
    packet.  The switches that seem to work best for emacs are:
@@ -2649,43 +2662,6 @@ of PURESIZE in puresize.h.
 But in some of the cases listed above, this problem is a consequence
 of something else that is wrong.  Be sure to check and fix the real problem.
 
-*** Linux: Emacs crashes when dumping itself on Mac PPC running Yellow Dog GNU/Linux.
-
-The crashes happen inside the function Fmake_symbol; here's a typical
-C backtrace printed by GDB:
-
-  0x190c0c0 in Fmake_symbol ()
-  (gdb) where
-  #0  0x190c0c0 in Fmake_symbol ()
-  #1  0x1942ca4 in init_obarray ()
-  #2  0x18b3500 in main ()
-  #3  0x114371c in __libc_start_main (argc=5, argv=0x7ffff5b4, envp=0x7ffff5cc,
-
-This could happen because GCC version 2.95 and later changed the base
-of the load address to 0x10000000.  Emacs needs to be told about this,
-but we currently cannot do that automatically, because that breaks
-other versions of GNU/Linux on the MacPPC.  Until we find a way to
-distinguish between the Yellow Dog and the other varieties of
-GNU/Linux systems on the PPC, you will have to manually uncomment the
-following section near the end of the file src/m/macppc.h in the Emacs
-distribution:
-
-  #if 0  /* This breaks things on PPC GNU/Linux except for Yellowdog,
-            even with identical GCC, as, ld.  Let's take it out until we
-            know what's really going on here.  */
-  /* GCC 2.95 and newer on GNU/Linux PPC changed the load address to
-     0x10000000.  */
-  #if defined __linux__
-  #if __GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 95)
-  #define DATA_SEG_BITS  0x10000000
-  #endif
-  #endif
-  #endif /* 0 */
-
-Remove the "#if 0" and "#endif" directives which surround this, save
-the file, and then reconfigure and rebuild Emacs.  The dumping process
-should now succeed.
-
 *** OpenBSD 4.0 macppc: Segfault during dumping.
 
 The build aborts with signal 11 when the command `./temacs --batch
@@ -2768,7 +2744,7 @@ value in the man page for a.out (5).
 initialized variables.  Emacs makes all initialized variables in most
 of its files pure after dumping, but the variables declared static and
 not initialized are not supposed to be pure.  On these systems you
-may need to add "#define static" to the m- or the s- file.
+may need to add "#define static" to config.h.
 
 * Runtime problems on legacy systems