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
+ 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009
Free Software Foundation, Inc.
See the end of the file for license conditions.
This file describes various problems that have been encountered
-in compiling, installing and running GNU Emacs. Try doing Ctl-C Ctl-t
-and browsing through the outline headers.
+in compiling, installing and running GNU Emacs. Try doing C-c C-t
+and browsing through the outline headers. (See C-h m for help on
+Outline mode.)
* Mule-UCS doesn't work in Emacs 23.
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.
** Emacs compiled with Gtk+ may loop forever if a display crashes.
-This is related to the bug above. A scenario for this is when emacs is run
+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).
-** 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
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
* Runtime problems specific to MS-Windows
+** PATH can contain unexpanded environment variables
+
+Old releases of TCC (version 9) and 4NT (up to version 8) do not correctly
+expand App Paths entries of type REG_EXPAND_SZ. When Emacs is run from TCC
+and such an entry exists for emacs.exe, exec-path will contain the
+unexpanded entry. This has been fixed in TCC 10. For more information,
+see bug#2062.
+
+** Setting w32-pass-rwindow-to-system and w32-pass-lwindow-to-system to nil
+does not prevent the Start menu from popping up when the left or right
+``Windows'' key is pressed.
+
+This was reported to happen when XKeymacs is installed. At least with
+XKeymacs Version 3.47, deactivating XKeymacs when Emacs is active is
+not enough to avoid its messing with the keyboard input. Exiting
+XKeymacs completely is reported to solve the problem.
+
** Windows 95 and networking.
To support server sockets, Emacs 22.1 loads ws2_32.dll. If this file
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
conflict between the versions of malloc in the DLL and in Emacs, which
is not resolvable due to the way Windows does dynamic linking.
-We recommend the use of the MingW port of GCC for compiling Emacs, as
+We recommend the use of the MinGW port of GCC for compiling Emacs, as
not only does it not suffer these problems, but it is also Free
software like Emacs.
+*** Building the MS-Windows port with Visual Studio fails compiling emacs.rc
+
+If the build fails with the following message then the problem
+described here most likely applies:
+
+../nt/emacs.rc(1) : error RC2176 : old DIB in icons\emacs.ico; pass it
+through SDKPAINT
+
+The Emacs icon contains a high resolution PNG icon for Vista, which is
+not recognized by older versions of the resource compiler. There are
+several workarounds for this problem:
+ 1. Use Free MinGW tools to compile, which do not have this problem.
+ 2. Install the latest Windows SDK.
+ 3. Replace emacs.ico with an older or edited icon.
+
** Linking
*** Building Emacs with a system compiler fails to link because of an
** Bootstrapping
Bootstrapping (compiling the .el files) is normally only necessary
-with CVS builds, since they the .elc files are pre-compiled in releases.
+with CVS builds, since the .elc files are pre-compiled in releases.
*** "No rule to make target" with Ubuntu 8.04 make 3.81-3build1
config.bat. To resolve this, move the DJGPP's `bin' subdirectory to
the front of your PATH environment variable.
+*** When Emacs compiled with DJGPP runs on Windows 2000 and later, it cannot
+find your HOME directory.
+
+This was reported to happen when you click on "Save for future
+sessions" button in a Customize buffer. You might see an error
+message like this one:
+
+ basic-save-buffer-2: c:/FOO/BAR/~dosuser/: no such directory
+
+(The telltale sign is the "~USER" part at the end of the directory
+Emacs complains about, where USER is your username or the literal
+string "dosuser", which is the default username set up by the DJGPP
+startup file DJGPP.ENV.)
+
+This happens when the functions `user-login-name' and
+`user-real-login-name' return different strings for your username as
+Emacs sees it. To correct this, make sure both USER and USERNAME
+environment variables are set to the same value. Windows 2000 and
+later sets USERNAME, so if you want to keep that, make sure USER is
+set to the same value. If you don't want to set USER globally, you
+can do it in the [emacs] section of your DJGPP.ENV file.
+
*** When Emacs compiled with DJGPP runs on Vista, it runs out of memory.
If Emacs running on Vista displays "!MEM FULL!" in the mode line, you