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
+ 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
Free Software Foundation, Inc.
See the end of the file for license conditions.
* Crash bugs
+** Emacs crashes when running in a terminal, if compiled with GCC 4.5.0
+This version of GCC is buggy: see
+
+ http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6031
+ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43904
+
+You can work around this error in gcc-4.5 by omitting sibling call
+optimization. To do this, configure Emacs with
+
+ CFLAGS="-g -O2 -fno-optimize-sibling-calls" ./configure
+
** Emacs crashes in x-popup-dialog.
This can happen if the dialog widget cannot find the font it wants to
problem, you should look for a way to configure Emacs so that it uses
terminfo when built.
-** Emacs crashes when using the Exceed 6.0 X server.
+** Emacs crashes when using some version of the Exceed X server.
-If you are using Exceed 6.1, upgrade to a later version. This was
-reported to prevent the crashes.
+Upgrading to a newer version of Exceed has been reported to prevent
+these crashes. You should consider switching to a free X server, such
+as Xming or Cygwin/X.
** Emacs crashes with SIGSEGV in XtInitializeWidgetClass.
server that results in an endless loop. This is not fixed in any known
Gtk+ version (2.14.4 being current).
-** Emacs compiled with Gtk+ crashes on startup on Cygwin.
-
-A typical error message is
- ***MEMORY-ERROR***: emacs[5172]: GSlice: failed to allocate 504 bytes
- (alignment: 512): Function not implemented
-
-Emacs supplies its own malloc, but glib (part of Gtk+) calls memalign and on
-Cygwin, that becomes the Cygwin supplied memalign. As malloc is not the
-Cygwin malloc, the Cygwin memalign always returns ENOSYS. A fix for this
-problem would be welcome.
-
* General runtime problems
** Lisp problems
Many Spanish keyboards seem to ignore that combination. Emacs can't
do anything about it.
-** Characters from the mule-unicode charsets aren't displayed under X.
+** International characters aren't displayed under X.
+
+*** Missing X fonts
XFree86 4 contains many fonts in iso10646-1 encoding which have
minimal character repertoires (whereas the encoding part of the font
mule-unicode-e000-ffff:-gnu-unifont-*-iso10646-1,\
mule-unicode-0100-24ff:-gnu-unifont-*-iso10646-1
+*** Athena/Lucid toolkit limitations
+
+The Athena/Lucid toolkit cannot display UTF-8 strings in the menu, so
+if you have UTF-8 buffer names, the buffer menu won't display the
+names properly. The GTK+ toolkit works properly.
+
** The UTF-8/16/7 coding systems don't encode CJK (Far Eastern) characters.
Emacs directly supports the Unicode BMP whose code points are in the
substituted with the Unicode `replacement character', and you lose
information.
-** Mule-UCS loads very slowly.
-
-Changes to Emacs internals interact badly with Mule-UCS's `un-define'
-library, which is the usual interface to Mule-UCS. Apply the
-following patch to Mule-UCS 0.84 and rebuild it. That will help,
-though loading will still be slower than in Emacs 20. (Some
-distributions, such as Debian, may already have applied such a patch.)
-
---- lisp/un-define.el 6 Mar 2001 22:41:38 -0000 1.30
-+++ lisp/un-define.el 19 Apr 2002 18:34:26 -0000
-@@ -610,13 +624,21 @@ by calling post-read-conversion and pre-
-
- (mapcar
- (lambda (x)
-- (mapcar
-- (lambda (y)
-- (mucs-define-coding-system
-- (nth 0 y) (nth 1 y) (nth 2 y)
-- (nth 3 y) (nth 4 y) (nth 5 y) (nth 6 y))
-- (coding-system-put (car y) 'alias-coding-systems (list (car x))))
-- (cdr x)))
-+ (if (fboundp 'register-char-codings)
-+ ;; Mule 5, where we don't need the eol-type specified and
-+ ;; register-char-codings may be very slow for these coding
-+ ;; system definitions.
-+ (let ((y (cadr x)))
-+ (mucs-define-coding-system
-+ (car x) (nth 1 y) (nth 2 y)
-+ (nth 3 y) (nth 4 y) (nth 5 y)))
-+ (mapcar
-+ (lambda (y)
-+ (mucs-define-coding-system
-+ (nth 0 y) (nth 1 y) (nth 2 y)
-+ (nth 3 y) (nth 4 y) (nth 5 y) (nth 6 y))
-+ (coding-system-put (car y) 'alias-coding-systems (list (car x)))))
-+ (cdr x)))
- `((utf-8
- (utf-8-unix
- ?u "UTF-8 coding system"
-
-Note that Emacs has native support for Unicode, roughly equivalent to
-Mule-UCS's, so you may not need it.
-
-** Mule-UCS compilation problem.
-
-Emacs of old versions and XEmacs byte-compile the form `(progn progn
-...)' the same way as `(progn ...)', but Emacs of version 21.3 and the
-later process that form just as interpreter does, that is, as `progn'
-variable reference. Apply the following patch to Mule-UCS 0.84 to
-make it compiled by the latest Emacs.
-
---- mucs-ccl.el 2 Sep 2005 00:42:23 -0000 1.1.1.1
-+++ mucs-ccl.el 2 Sep 2005 01:31:51 -0000 1.3
-@@ -639,10 +639,14 @@
- (mucs-notify-embedment 'mucs-ccl-required name)
- (setq ccl-pgm-list (cdr ccl-pgm-list)))
- ; (message "MCCLREGFIN:%S" result)
-- `(progn
-- (setq mucs-ccl-facility-alist
-- (quote ,mucs-ccl-facility-alist))
-- ,@result)))
-+ ;; The only way the function is used in this package is included
-+ ;; in `mucs-package-definition-end-hook' value, where it must
-+ ;; return (possibly empty) *list* of forms. Do this. Do not rely
-+ ;; on byte compiler to remove extra `progn's in `(progn ...)'
-+ ;; form.
-+ `((setq mucs-ccl-facility-alist
-+ (quote ,mucs-ccl-facility-alist))
-+ ,@result)))
-
- ;;; Add hook for embedding translation informations to a package.
- (add-hook 'mucs-package-definition-end-hook
-
** Accented ISO-8859-1 characters are displayed as | or _.
Try other font set sizes (S-mouse-1). If the problem persists with
** Window-manager and toolkit-related problems
+*** Metacity: Resizing Emacs or ALT-Tab causes X to be unresponsive.
+
+This happens sometimes when using Metacity. Resizing Emacs or ALT-Tab:bing
+makes the system unresponsive to the mouse or the keyboard. Killing Emacs
+or shifting out from X11 and back again usually cures it (i.e. Ctrl-Alt-F1
+and then Alt-F7). A bug for it is here:
+https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/231034.
+Note that a permanent fix seems to be to disable "assistive technologies".
+
*** Gnome: Emacs receives input directly from the keyboard, bypassing XIM.
This seems to happen when gnome-settings-daemon version 2.12 or later
* Runtime problems on character terminals
+** The meta key does not work on xterm.
+Typing M-x rings the terminal bell, and inserts a string like ";120~".
+For recent xterm versions (>= 216), Emacs uses xterm's modifyOtherKeys
+feature to generate strings for key combinations that are not
+otherwise usable. One circumstance in which this can cause problems
+is if you have specified the X resource
+
+ xterm*VT100.Translations
+
+to contain translations that use the meta key. Then xterm will not
+use meta in modified function-keys, which confuses Emacs. To fix
+this, you can remove the X resource or put this in your init file:
+
+ (xterm-remove-modify-other-keys)
+
** Emacs spontaneously displays "I-search: " at the bottom of the screen.
This means that Control-S/Control-Q (XON/XOFF) "flow control" is being
First of all, many terminals have a set-up mode which controls whether
they generate XON/XOFF flow control characters. This must be set to
-"no XON/XOFF" in order for Emacs to work. Sometimes there is an
+"no XON/XOFF" in order for Emacs to work. (For example, on a VT220
+you may select "No XOFF" in the setup menu.) Sometimes there is an
escape sequence that the computer can send to turn flow control off
and on. If so, perhaps the termcap `ti' string should turn flow
control off, and the `te' string should turn it on.
Some versions of rlogin (and possibly telnet) do not pass flow
control characters to the remote system to which they connect.
On such systems, emacs on the remote system cannot disable flow
-control on the local system.
+control on the local system. Sometimes `rlogin -8' will avoid this
+problem.
One way to cure this is to disable flow control on the local host
(the one running rlogin, not the one running rlogind) using the
stty command, before starting the rlogin process. On many systems,
-"stty start u stop u" will do this.
+"stty start u stop u" will do this. On some systems, use
+"stty -ixon" instead.
Some versions of tcsh will prevent even this from working. One way
around this is to start another shell before starting rlogin, and
changes the keyboard layout depends on your Windows version; for XP,
in the Languages tab, click "Details" and then "Key Settings".)
-** Cygwin build of Emacs hangs after rebasing Cygwin DLLs
-
-Usually, on Cygwin, one needs to rebase the DLLs if an application
-aborts with a message like this:
-
- C:\cygwin\bin\python.exe: *** unable to remap C:\cygwin\bin\cygssl.dll to
- same address as parent(0xDF0000) != 0xE00000
-
-However, since Cygwin DLL 1.5.17 was released, after such rebasing,
-Emacs hangs.
-
-This was reported to happen for Emacs 21.2 and also for the pretest of
-Emacs 22.1 on Cygwin.
-
-To work around this, build Emacs like this:
-
- LDFLAGS='-Wl,--enable-auto-import -Wl,--enable-auto-image-base' ./configure
- make LD='$(CC)'
- make LD='$(CC)' install
-
-This produces an Emacs binary that is independent of rebasing.
-
-Note that you _must_ use LD='$(CC)' in the last two commands above, to
-prevent GCC from passing the "--image-base 0x20000000" option to the
-linker, which is what it does by default. That option produces an
-Emacs binary with the base address 0x20000000, which will cause Emacs
-to hang after Cygwin DLLs are rebased.
-
** Interrupting Cygwin port of Bash from Emacs doesn't work.
Cygwin 1.x builds of the ported Bash cannot be interrupted from the
(using the location of the 32-bit X libraries on your system).
-*** Building the Cygwin port for MS-Windows can fail with some GCC versions
-
-Building Emacs 22 with Cygwin builds of GCC 3.4.4-1 and 3.4.4-2 is
-reported to either fail or cause Emacs to segfault at run time. In
-addition, the Cygwin GCC 3.4.4-2 has problems with generating debug
-info. Cygwin users are advised not to use these versions of GCC for
-compiling Emacs. GCC versions 4.0.3, 4.0.4, 4.1.1, and 4.1.2
-reportedly build a working Cygwin binary of Emacs, so we recommend
-these GCC versions. Note that these versions of GCC, 4.0.3, 4.0.4,
-4.1.1, and 4.1.2, are currently the _only_ versions known to succeed
-in building Emacs (as of v22.1).
+*** Building Emacs for Cygwin can fail with GCC 3
+
+As of Emacs 22.1, there have been stability problems with Cygwin
+builds of Emacs using GCC 3. Cygwin users are advised to use GCC 4.
+
+*** Building the native MS-Windows port fails due to unresolved externals
+
+The linker error messages look like this:
+
+ oo-spd/i386/ctags.o:ctags.c:(.text+0x156e): undefined reference to `_imp__re_set_syntax'
+ collect2: ld returned 1 exit status
+
+This happens because GCC finds an incompatible header regex.h
+somewhere on the include path, before the version of regex.h supplied
+with Emacs. One such incompatible version of regex.h is part of the
+GnuWin32 Regex package.
+
+The solution is to remove the incompatible regex.h from the include
+path, when compiling Emacs. Alternatively, re-run the configure.bat
+script with the "-isystem C:/GnuWin32/include" switch (adapt for your
+system's place where you keep the GnuWin32 include files) -- this will
+cause the compiler to search headers in the directories specified by
+the Emacs Makefile _before_ it looks in the GnuWin32 include
+directories.
*** Building the native MS-Windows port with Cygwin GCC can fail.
HCoop / bpt / emacs.git / blobdiff