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.
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
** Keyboard problems
+*** Unable to enter the M-| key on some German keyboards.
+Some users have reported that M-| suffers from "keyboard ghosting".
+This can't be fixed by Emacs, as the keypress never gets passed to it
+at all (as can be verified using "xev"). You can work around this by
+typing `ESC |' instead.
+
*** "Compose Character" key does strange things when used as a Meta key.
If you define one key to serve as both Meta and Compose Character, you
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!
** 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.
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)
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:
Option "Device" "/dev/input/mice"
EndSection
+*** Emacs is slow to exit in X
+
+After you use e.g. C-x C-c to exit, it takes many seconds before the
+Emacs window disappears. If Emacs was started from a terminal, you
+see the message:
+
+ Error saving to X clipboard manager.
+ If the problem persists, set `x-select-enable-clipboard-manager' to nil.
+
+As the message suggests, this problem occurs when Emacs thinks you
+have a clipboard manager program running, but has trouble contacting it.
+If you don't want to use a clipboard manager, you can set the
+suggested variable. Or you can make Emacs not wait so long by
+reducing the value of `x-selection-timeout', either in .emacs or with
+X resources.
+
+Sometimes this problem is due to a bug in your clipboard manager.
+Updating to the latest version of the manager can help.
+For example, in the Xfce 4.8 desktop environment, the clipboard
+manager in versions of xfce4-settings-helper before 4.8.2 is buggy;
+https://bugzilla.xfce.org/show_bug.cgi?id=7588 .
+
* Runtime problems on character terminals
** The meta key does not work on xterm.
global-font-lock-mode RET" or by customizing the variable
`global-font-lock-mode'.
+** Unexpected characters inserted into the buffer when you start Emacs.
+See eg http://debbugs.gnu.org/11129
+
+This can happen when you start Emacs in -nw mode in an Xterm.
+For example, in the *scratch* buffer, you might see something like:
+
+ 0;276;0c
+
+This is more likely to happen if you are using Emacs over a slow
+connection, and begin typing before Emacs is ready to respond.
+
+This occurs when Emacs tries to query the terminal to see what
+capabilities it supports, and gets confused by the answer.
+To avoid it, set xterm-extra-capabilities to a value other than
+`check' (the default). See that variable's documentation (in
+term/xterm.el) for more details.
+
* Runtime problems specific to individual Unix variants
** GNU/Linux
built in editor to print (this is possibly the only useful purpose it
has):
-(setq printer-name "") ;; notepad takes the default
-(setq lpr-command "notepad") ;; notepad
-(setq lpr-switches nil) ;; not needed
-(setq lpr-printer-switch "/P") ;; run notepad as batch printer
+(setq printer-name "") ; notepad takes the default
+(setq lpr-command "notepad") ; notepad
+(setq lpr-switches nil) ; not needed
+(setq lpr-printer-switch "/P") ; run notepad as batch printer
** Antivirus software interacts badly with the MS-Windows version of Emacs.
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
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