Known Problems with GNU Emacs
-Copyright (C) 1987-1989, 1993-1999, 2001-2015 Free Software Foundation, Inc.
+Copyright (C) 1987-1989, 1993-1999, 2001-2016 Free Software Foundation,
+Inc.
See the end of the file for license conditions.
on the flag to output ^M at the end of each line. You can fix the
problem by adding this to your .cshrc file:
- if ($?EMACS) then
- if ("$EMACS" =~ /*) then
- unset edit
- stty -icrnl -onlcr -echo susp ^Z
- endif
+ if ($?INSIDE_EMACS && $?tcsh)
+ unset edit
+ stty -icrnl -onlcr -echo susp ^Z
endif
*** Emacs startup on GNU/Linux systems (and possibly other systems) is slow.
Emacs is linked. With LD_RUN_PATH set, the linker will include a
specified run-time search path in the executable.
-On some systems, Emacs can crash due to problems with dynamic
-linking. Specifically, on SGI Irix 6.5, crashes were reported with
-backtraces like this:
-
- (dbx) where
- 0 strcmp(0xf49239d, 0x4031184, 0x40302b4, 0x12, 0xf0000000, 0xf4923aa, 0x0, 0x492ddb2) ["/xlv22/ficus-jan23/work/irix/lib/libc/libc_n32_M3_ns/strings/strcmp.s":35, 0xfb7e480]
- 1 general_find_symbol(0xf49239d, 0x0, 0x0, 0x0, 0xf0000000, 0xf4923aa, 0x0, 0x492ddb2)
- ["/comp2/mtibuild/v73/workarea/v7.3/rld/rld.c":2140, 0xfb65a98]
- 2 resolve_symbol(0xf49239d, 0x4031184, 0x0, 0xfbdd438, 0x0, 0xf4923aa, 0x0, 0x492ddb2)
- ["/comp2/mtibuild/v73/workarea/v7.3/rld/rld.c":1947, 0xfb657e4]
- 3 lazy_text_resolve(0xd18, 0x1a3, 0x40302b4, 0x12, 0xf0000000, 0xf4923aa, 0x0, 0x492ddb2)
- ["/comp2/mtibuild/v73/workarea/v7.3/rld/rld.c":997, 0xfb64d44]
- 4 _rld_text_resolve(0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
- ["/comp2/mtibuild/v73/workarea/v7.3/rld/rld_bridge.s":175, 0xfb6032c]
-
-('rld' is the dynamic linker.) We don't know why this
-happens, but setting the environment variable LD_BIND_NOW to 1 (which
-forces the dynamic linker to bind all shared objects early on) seems
-to work around the problem.
-
Please refer to the documentation of your dynamic linker for details.
*** When you run Ispell from Emacs, it reports a "misalignment" error.
lower/raise); tex-suscript-height-ratio (how much smaller than
normal); tex-suscript-height-minimum (minimum height).
+** Screen refresh is slow when there are special characters for which no suitable font is available
+
+If the display is too slow in refreshing when you scroll to a new
+region, or when you edit the buffer, it might be due to the fact that
+some characters cannot be displayed in the default font, and Emacs is
+spending too much time in looking for a suitable font to display them.
+
+You can suspect this if you have several characters that are displayed
+as small rectangles containing a hexadecimal code inside.
+
+The solution is to install the appropriate fonts on your machine. For
+instance if you are editing a text with a lot of math symbols, then
+installing a font like 'Symbola' should solve this problem.
+
* Internationalization problems
** M-{ does not work on a Spanish PC keyboard.
** Window-manager and toolkit-related problems
+*** Emacs built with GTK+ toolkit produces corrupted display on HiDPI screen
+
+This can happen if you set GDK_SCALE=2 in the environment or in your
+'.xinitrc' file. (This setting is usually accompanied by
+GDK_DPI_SCALE=0.5.) Emacs can not support these settings correctly,
+as it doesn't use GTK+ exclusively. The result is that sometimes
+widgets like the scroll bar are displayed incorrectly, and frames
+could be displayed "cropped" to only part of the stuff that should be
+displayed.
+
+The workaround is to explicitly disable these settings when invoking
+Emacs, for example (from a Posix shell prompt):
+
+ $ GDK_SCALE=1 GDK_DPI_SCALE=1 emacs
+
*** Metacity: Resizing Emacs or ALT-Tab causes X to be unresponsive.
This happens sometimes when using Metacity. Resizing Emacs or ALT-Tab:bing
the 'xmodmap' utility to show all the keys which produce a Meta
modifier:
- xmodmap -pk | egrep -i "meta|alt"
+ xmodmap -pk | grep -Ei "meta|alt"
A more convenient way of finding out which keys produce a Meta modifier
is to use the 'xkbprint' utility, if it's available on your system:
and -g -O2) and GCC 4.2.3 (-g -O and -g -O2). You can fix this by
compiling with GCC 4.2.3 or CC 5.7, with no optimizations.
-** Irix
-
-*** Irix: Trouble using ptys, or running out of ptys.
-
-The program mkpts (which may be in '/usr/adm' or '/usr/sbin') needs to
-be set-UID to root, or non-root programs like Emacs will not be able
-to allocate ptys reliably.
-
* Runtime problems specific to MS-Windows
** Emacs on Windows 9X requires UNICOWS.DLL
A workaround is to build Emacs with MinGW runtime 3.x (the latest
version is 3.20).
+** addpm fails to run on Windows NT4, complaining about Shell32.dll
+
+This is likely to happen because Shell32.dll shipped with NT4 lacks
+the updates required by Emacs. Installing Internet Explorer 4 solves
+the problem. Note that it is NOT enough to install IE6, because doing
+so will not install the Shell32.dll update.
+
** A few seconds delay is seen at startup and for many file operations
This happens when the Net Logon service is enabled. During Emacs
working in Emacs, or to add emacs.exe to the list of applications that
are allowed to use the clipboard when the Web browser is open.
+** "Pinning" Emacs to the taskbar doesn't work on Windows 10
+
+"Doesn't work" here means that if you invoke Emacs by clicking on the
+pinned icon, a separate button appears on the taskbar, instead of the
+expected effect of the icon you clicked on being converted to that
+button.
+
+This is due to a bug in early versions of Windows 10, reportedly fixed
+in build 1511 of Windows 10 (a.k.a. "Windows 10 SP1"). If you cannot
+upgrade, read the work-around described below.
+
+First, be sure to edit the Properties of the pinned icon to invoke
+runemacs.exe, not emacs.exe. (The latter will cause an extra cmd
+window to appear when you invoke Emacs from the pinned icon.)
+
+But the real cause of the problem is the fact that the pinned icon
+(which is really a shortcut in a special directory) lacks a unique
+application-defined Application User Model ID (AppUserModelID) that
+identifies the current process to the taskbar. This identifier allows
+an application to group its associated processes and windows under a
+single taskbar button. Emacs on Windows specifies a unique
+AppUserModelID when it starts, but Windows 10, unlike previous
+versions of MS-Windows, does not propagate that ID to the pinned icon.
+
+To work around this, use some utility, such as 'win7appid', to set the
+AppUserModelID of the pinned icon to the string "Gnu.Emacs". The
+shortcut files corresponding to icons you pinned are stored by Windows
+in the following subdirectory of your user's directory (by default
+C:\Users\<UserName>\):
+
+ AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar
+
+Look for the file 'emacs.lnk' there.
+
** Windows 95 and networking.
To support server sockets, Emacs loads ws2_32.dll. If this file is
of Windows. This is caused by a deficiency in the underlying system
library function.
-** Problems with set-time-zone-rule function
+** Non-US time zones.
-The function set-time-zone-rule gives incorrect results for many
-non-US timezones. This is due to over-simplistic handling of
-daylight savings switchovers by the Windows libraries.
+Many non-US time zones are implemented incorrectly. This is due to
+over-simplistic handling of daylight savings switchovers by the
+Windows libraries.
** Files larger than 4GB report wrong size in a 32-bit Windows build
(using the location of the 32-bit X libraries on your system).
+*** Building on FreeBSD 11 fails at link time due to unresolved symbol
+
+The symbol is sendmmsg@FBSD_1.4. This is due to a faulty libgio
+library on these systems. The solution is to reconfigure Emacs while
+disabling all the features that require libgio: rsvg, dbus, gconf, and
+imagemagick.
+
*** Building Emacs for Cygwin can fail with GCC 3
As of Emacs 22.1, there have been stability problems with Cygwin
** Dumping
-*** Segfault during 'make bootstrap' under the Linux kernel.
+*** Segfault during 'make'
-In Red Hat Linux kernels, "Exec-shield" functionality is enabled by
-default, which creates a different memory layout that can break the
-emacs dumper. Emacs tries to handle this at build time, but if this
-fails, the following instructions may be useful.
+If Emacs segfaults when 'make' executes one of these commands:
-Exec-shield is enabled on your system if
+ LC_ALL=C ./temacs -batch -l loadup bootstrap
+ LC_ALL=C ./temacs -batch -l loadup dump
- cat /proc/sys/kernel/exec-shield
+the problem may be due to inadequate workarounds for address space
+layout randomization (ASLR), an operating system feature that
+randomizes the virtual address space of a process. ASLR is commonly
+enabled in Linux and NetBSD kernels, and is intended to deter exploits
+of pointer-related bugs in applications. If ASLR is enabled, the
+command:
-prints a value other than 0. (Please read your system documentation
-for more details on Exec-shield and associated commands.)
+ cat /proc/sys/kernel/randomize_va_space # GNU/Linux
+ sysctl security.pax.aslr.global # NetBSD
-Additionally, Linux kernel versions since 2.6.12 randomize the virtual
-address space of a process by default. If this feature is enabled on
-your system, then
+outputs a nonzero value.
- cat /proc/sys/kernel/randomize_va_space
+These segfaults should not occur on most modern systems, because the
+Emacs build procedure uses the command 'setfattr' or 'paxctl' to mark
+the Emacs executable as requiring non-randomized address space, and
+Emacs uses the 'personality' system call to disable address space
+randomization when dumping. However, older kernels may not support
+'setfattr', 'paxctl', or 'personality', and newer Linux kernels have a
+secure computing mode (seccomp) that can be configured to disable the
+'personality' call.
-prints a value other than 0.
+It may be possible to work around the 'personality' problem in a newer
+Linux kernel by configuring seccomp to allow the 'personality' call.
+For example, if you are building Emacs under Docker, you can run the
+Docker container with a security profile that allows 'personality' by
+using Docker's --security-opt option with an appropriate profile; see
+<https://docs.docker.com/engine/security/seccomp/>.
-When these features are enabled, building Emacs may segfault during
-the execution of this command:
+To work around the ASLR problem in either an older or a newer kernel,
+you can temporarily disable the feature while building Emacs. On
+GNU/Linux you can do so using the following command (as root).
- ./temacs --batch --load loadup [dump|bootstrap]
+ echo 0 > /proc/sys/kernel/randomize_va_space
-To work around this problem, you can temporarily disable these
-features while building Emacs. You can do so using the following
-commands (as root). Remember to re-enable them when you are done,
-by echoing the original values back to the files.
+You can re-enable the feature when you are done, by echoing the
+original value back to the file. NetBSD uses a different command,
+e.g., 'sysctl -w security.pax.aslr.global=0'.
- echo 0 > /proc/sys/kernel/exec-shield
- echo 0 > /proc/sys/kernel/randomize_va_space
+Alternatively, you can try using the 'setarch' command when building
+temacs like this, where -R disables address space randomization:
+
+ setarch $(uname -m) -R make
-Or, on x86, you can try using the 'setarch' command when running
-temacs, like this:
+ASLR is not the only problem that can break Emacs dumping. Another
+issue is that in Red Hat Linux kernels, Exec-shield is enabled by
+default, and this creates a different memory layout. Emacs should
+handle this at build time, but if this fails the following
+instructions may be useful. Exec-shield is enabled on your system if
- setarch i386 -R ./temacs --batch --load loadup [dump|bootstrap]
+ cat /proc/sys/kernel/exec-shield
-or
+prints a nonzero value. You can temporarily disable it as follows:
- setarch i386 -R make
+ echo 0 > /proc/sys/kernel/exec-shield
-(The -R option disables address space randomization.)
+As with randomize_va_space, you can re-enable Exec-shield when you are
+done, by echoing the original value back to the file.
*** temacs prints "Pure Lisp storage exhausted".