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.
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
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.)
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