Newer Older
Dave Love's avatar
Dave Love committed
1 2 3
This file describes various problems that have been encountered
in compiling, installing and running GNU Emacs.

4 5 6 7 8 9 10 11 12 13 14 15 16 17
* Characters are displayed as empty boxes or with wrong font under X.

This can occur when two different versions of FontConfig are used.
For example, XFree86 4.3.0 has one version and Gnome usually comes
with a newer version.  Emacs compiled with --with-gtk will then use
the newer version.  In most cases the problem can be temporarily
fixed by stopping the application that has the error (it can be
Emacs or any other application), removing ~/.fonts.cache-1,
and then start the application again.
If removing ~/.fonts.cache-1 and restarting doesn't help, the
application with problem must be recompiled with the same version
of FontConfig as the rest of the system uses.  For KDE, it is
sufficient to recompile Qt.

18 19 20 21 22 23
* Process output truncated on Mac OS X (Carbon) when using pty's.

There appears to be a problem with the implementation of pty's on the
Mac OS X that causes process output to be truncated.  To avoid this,
leave process-connection-type set to its default value of nil.

24 25
* Emacs crashes on Mac OS X (Carbon) after system software upgrade.

26 27 28
This problem seems to be now solved by Steven Tamm's patch to
unexmacosx.c on Nov 24, 2002.

29 30 31 32 33
Between Mac OS X release 10.2.1 and 10.2.2 there was an incompatible
change in the memory allocator that causes a EXC_BAD_ACCESS error near
xrealloc().  Relinking the application (by deleting src/temacs and
running make) will solve the problem.  It appears to be caused by some
problems with the unexec code and its interaction with libSystem.B.
Dave Love's avatar
Dave Love committed

Dave Love's avatar
Dave Love committed
35 36 37
* Characters from the mule-unicode charsets aren't displayed under X.

XFree86 4 contains many fonts in iso10646-1 encoding which have
Dave Love's avatar
Dave Love committed
38 39 40 41 42 43 44 45
minimal character repertoires (whereas the encoding part of the font
name is meant to be a reasonable indication of the repertoire
according to the XLFD spec).  Emacs may choose one of these to display
characters from the mule-unicode charsets and then typically won't be
able to find the glyphs to display many characters.  (Check with C-u
C-x = .)  To avoid this, you may need to use a fontset which sets the
font for the mule-unicode sets explicitly.  E.g. to use GNU unifont,
include in the fontset spec:
Dave Love's avatar
Dave Love committed
46 47 48 49 50


Dave Love's avatar
Dave Love committed
51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70
* The UTF-8/16/7 coding systems don't encode CJK (Far Eastern) characters.

Emacs by default only supports the parts of the Unicode BMP whose code
points are in the ranges 0000-33ff and e000-ffff.  This excludes: most
of CJK, Yi and Hangul, as well as everything outside the BMP.

If you read UTF-8 data with code points outside these ranges, the
characters appear in the buffer as raw bytes of the original UTF-8
(composed into a single quasi-character) and they will be written back
correctly as UTF-8, assuming you don't break the composed sequences.
If you read such characters from UTF-16 or UTF-7 data, they are
substituted with the Unicode `replacement character', and you lose

To edit such UTF data, turn on Utf-Translate-Cjk mode, which makes
many common CJK characters available for encoding and decoding and can
be extended by updating the tables it uses.  This also allows you to
save as UTF buffers containing characters decoded by the chinese-,
japanese- and korean- coding systems, e.g. cut and pasted from
Simon Josefsson's avatar
Simon Josefsson committed

72 73 74 75 76 77 78
* Problems with file dialogs in Emacs built with Open Motif.

When Emacs 21 is built with Open Motif 2.1, it can happen that the
graphical file dialog boxes do not work properly.  The "OK", "Filter"
and "Cancel" buttons do not respond to mouse clicks.  Dragging the
file dialog window usually causes the buttons to work again.

Richard M. Stallman's avatar
Richard M. Stallman committed
The solution is to use LessTif instead.  LessTif is a free replacement
80 81 82 83 84 85
for Motif.  See the file INSTALL for information on how to do this.

Another workaround is not to use the mouse to trigger file prompts,
but to use the keyboard.  This way, you will be prompted for a file in
the minibuffer instead of a graphical file dialog.

86 87 88 89 90
* Emacs reports a BadAtom error (from X) running on Solaris 7 or 8.

This happens when Emacs was built on some other version of Solaris.
Rebuild it on Solaris 8.

Dave Love's avatar
Dave Love committed
91 92 93 94 95 96 97 98 99 100 101
* 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-

Dave Love's avatar
Dave Love committed
103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133
   (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)))
       ?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.

Eli Zaretskii's avatar
Eli Zaretskii committed
134 135 136 137 138
* Building Emacs with GCC 2.9x fails in the `src' directory.

This may happen if you use a development version of GNU `cpp' from one
of the GCC snapshots between Oct 2000 and Feb 2001, or from a released
version of GCC newer than 2.95.2 which was prepared around those
139 140 141 142 143 144
dates; similar problems were reported with some snapshots of GCC 3.1
around Sep 30 2001.  The preprocessor in those versions is
incompatible with a traditional Unix cpp (e.g., it expands ".." into
". .", which breaks relative file names that reference the parent
directory; or inserts TAB characters before lines that set Make
Eli Zaretskii's avatar
Eli Zaretskii committed
145 146

The solution is to make sure the preprocessor is run with the
147 148 149 150 151
`-traditional' option.  The `configure' script does that automatically
when it detects the known problems in your cpp, but you might hit some
unknown ones.  To force the `configure' script to use `-traditional',
run the script like this:

  CPP='gcc -E -traditional' ./configure ...
153 154 155

(replace the ellipsis "..." with any additional arguments you pass to
the script).
Eli Zaretskii's avatar
Eli Zaretskii committed
156 157 158 159

Note that this problem does not pertain to the MS-Windows port of
Emacs, since it doesn't use the preprocessor to generate Makefiles.

160 161
* Building Emacs with a system compiler fails to link because of an
undefined symbol such as __eprintf which does not appear in Emacs.
162 163 164 165 166 167 168 169 170 171 172 173

This can happen if some of the libraries linked into Emacs were built
with GCC, but Emacs itself is being linked with a compiler other than
GCC.  Object files compiled with GCC might need some helper functions
from libgcc.a, the library which comes with GCC, but the system
compiler does not instruct the linker to search libgcc.a during the
link stage.

A solution is to link with GCC, like this:

  	make CC=gcc

174 175 176
Since the .o object files already exist, this will not recompile Emacs
with GCC, but just restart by trying again to link temacs.

177 178 179 180 181 182 183 184 185 186
* Building the MS-Windows port with Cygwin GCC can fail.

Emacs may not build using recent Cygwin builds of GCC, such as Cygwin
version 1.1.8, using the default configure settings.  It appears to be
necessary to specify the -mwin32 flag when compiling, and define
__MSVCRT__, like so:

  configure --with-gcc --cflags -mwin32 --cflags -D__MSVCRT__

* Building the MS-Windows port with Leim fails in the `leim' directory.
187 188 189

The error message might be something like this:

 Converting d:/emacs-21.3/leim/CXTERM-DIC/4Corner.tit to quail-package...
191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207
 Invalid ENCODE: value in TIT dictionary
 NMAKE : fatal error U1077: '"../src/obj-spd/i386/emacs.exe"' : return code

This can happen if the Leim distribution is unpacked with a program
which converts the `*.tit' files to DOS-style CR-LF text format.  The
`*.tit' files in the leim/CXTERM-DIC directory require Unix-style line
endings to compile properly, because Emacs reads them without any code
or EOL conversions.

The solution is to make sure the program used to unpack Leim does not
change the files' line endings behind your back.  The GNU FTP site has
in the `/gnu/emacs/windows' directory a program called `djtarnt.exe'
which can be used to unpack `.tar.gz' and `.zip' archives without
mangling them.

208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228
* 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

  #if 0  /* This breaks things on PPC GNU/Linux except for Yellowdog,
230 231 232 233 234 235 236 237 238 239 240 241 242 243 244
	    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 /* 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.

Dave Love's avatar
Dave Love committed
245 246 247
* JPEG images aren't displayed.

This has been reported when Emacs is built with jpeg-6a library.
Dave Love's avatar
Dave Love committed
248 249 250
Upgrading to jpeg-6b solves the problem.  Configure checks for the
correct version, but this problem could occur if a binary built
against a shared libjpeg is run on a system with an older version.
Dave Love's avatar
Dave Love committed

252 253 254 255 256 257 258 259 260 261 262 263 264 265
* Building `ctags' for MS-Windows with the MinGW port of GCC fails.

This might happen due to a bug in the MinGW header assert.h, which
defines the `assert' macro with a trailing semi-colon.  The following
patch to assert.h should solve this:

*** include/assert.h.orig	Sun Nov  7 02:41:36 1999
--- include/assert.h	Mon Jan 29 11:49:10 2001
*** 41,47 ****
   * If not debugging, assert does nothing.
! #define assert(x)	((void)0);

  #else /* debugging enabled */

269 270 271 272 273
--- 41,47 ----
   * If not debugging, assert does nothing.
! #define assert(x)	((void)0)

  #else /* debugging enabled */


278 279 280

* Improving performance with slow X connections

281 282 283 284
There are several ways to improve this performance, any subset of which can
be carried out at the same time:

1) If you don't need X Input Methods (XIM) for entering text in some
Dave Love's avatar
Dave Love committed
285 286 287 288
   language you use, you can improve performance on WAN links by using
   the X resource useXIM to turn off use of XIM.  This does not affect
   the use of Emacs' own input methods, which are part of the Leim
289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305

2) If the connection is very slow, you might also want to consider
   switching off scroll bars, menu bar, and tool bar.

3) Use ssh to forward the X connection, and enable compression on this
   forwarded X connection (ssh -XC remotehostname emacs ...).

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
   several X requests in one TCP packet and sending them off together,
   instead of requiring a round-trip for each X request in a seperate
   packet.  The switches that seem to work best for emacs are:
    -noatomsfile  -nowinattr  -cheaterrors -cheatevents
   Note that the -nograbcmap option is known to cause problems.
   For more about lbxproxy, see:
Dave Love's avatar
Dave Love committed
307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355

* Getting a Meta key on the FreeBSD console

By default, neither Alt nor any other key acts as a Meta key on
FreeBSD, but this can be changed using kbdcontrol(1).  Dump the
current keymap to a file with the command

  $ kbdcontrol -d >emacs.kbd

Edit emacs.kbd, and give the key you want to be the Meta key the
definition `meta'.  For instance, if your keyboard has a ``Windows''
key with scan code 105, change the line for scan code 105 in emacs.kbd
to look like this

  105   meta   meta   meta   meta   meta   meta   meta   meta    O

to make the Windows key the Meta key.  Load the new keymap with

  $ kbdcontrol -l emacs.kbd

* Emacs' xterm-mouse-mode doesn't work on the Gnome terminal.

A symptom of this bug is that double-clicks insert a control sequence
into the buffer.  The reason this happens is an apparent
incompatibility of the Gnome terminal with Xterm, which also affects
other programs using the Xterm mouse interface.  A problem report has
been filed.

* Emacs pauses for several seconds when changing the default font

This has been reported for fvwm 2.2.5 and the window manager of KDE
2.1.  The reason for the pause is Xt waiting for a ConfigureNotify
event from the window manager, which the window manager doesn't send.
Xt stops waiting after a default timeout of usually 5 seconds.

A workaround for this is to add something like

emacs.waitForWM: false

to your X resources.  Alternatively, add `(wait-for-wm . nil)' to a
frame's parameter list, like this:

   (modify-frame-parameters nil '((wait-for-wm . nil)))

(this should go into your `.emacs' file).

* Underlines appear at the wrong position.

This is caused by fonts having a wrong UNDERLINE_POSITION property.
356 357 358 359 360 361 362 363
Examples are the font 7x13 on XFree prior to version 4.1, or the jmk
neep font from the Debian xfonts-jmk package.  To circumvent this
problem, set x-use-underline-position-properties to nil in your

To see what is the value of UNDERLINE_POSITION defined by the font,
type `xlsfonts -lll FONT' and look at the font's UNDERLINE_POSITION

Gerd Moellmann's avatar
Gerd Moellmann committed
365 366 367 368 369
* When using Xaw3d scroll bars without arrows, the very first mouse
click in a scroll bar might be ignored by the scroll bar widget.  This
is probably a bug in Xaw3d; when Xaw3d is compiled with arrows, the
problem disappears.

370 371 372
* There are known binary incompatibilities between Xaw, Xaw3d, neXtaw,
XawM and the few other derivatives of Xaw.  So when you compile with
one of these, it may not work to dynamically link with another one.
373 374 375 376 377 378 379
For example, strange problems, such as Emacs exiting when you type
"C-x 1", were reported when Emacs compiled with Xaw3d and libXaw was
used with neXtaw at run time.

The solution is to rebuild Emacs with the toolkit version you actually
want to use, or set LD_PRELOAD to preload the same toolkit version you
built Emacs with.

381 382 383 384 385 386
* Clicking C-mouse-2 in the scroll bar doesn't split the window.

This currently doesn't work with scroll-bar widgets (and we don't know
a good way of implementing it with widgets).  If Emacs is configured
--without-toolkit-scroll-bars, C-mouse-2 on the scroll bar does work.

387 388 389 390 391 392 393 394 395 396 397 398
* Emacs aborts inside the function `tparam1'.

This can happen if Emacs was built without terminfo support, but the
terminal's capabilities use format that is only supported by terminfo.
If your system has ncurses installed, this might happen if your
version of ncurses is broken; upgrading to a newer version of ncurses
and reconfiguring and rebuilding Emacs should solve this.

All modern systems support terminfo, so even if ncurses is not the
problem, you should look for a way to configure Emacs so that it uses
terminfo when built.

399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414
* Error messages about undefined colors on X.

The messages might say something like this:

   Unable to load color "grey95"

(typically, in the `*Messages*' buffer), or something like this:

  Error while displaying tooltip: (error Undefined color lightyellow)

These problems could happen if some other X program has used up too
many colors of the X palette, leaving Emacs with insufficient system
resources to load all the colors it needs.

A solution is to exit the offending X programs before starting Emacs.

415 416
* Colors are not available on a tty or in xterm.

Dave Love's avatar
Dave Love committed
417 418 419 420 421
Emacs 21 supports colors on character terminals and terminal
emulators, but this support relies on the terminfo or termcap database
entry to specify that the display supports color.  Emacs looks at the
"Co" capability for the terminal to find out how many colors are
supported; it should be non-zero to activate the color support within
422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438
Emacs.  (Most color terminals support 8 or 16 colors.)  If your system
uses terminfo, the name of the capability equivalent to "Co" is

In addition to the "Co" capability, Emacs needs the "op" (for
``original pair'') capability, which tells how to switch the terminal
back to the default foreground and background colors.  Emacs will not
use colors if this capability is not defined.  If your terminal entry
doesn't provide such a capability, try using the ANSI standard escape
sequence \E[00m (that is, define a new termcap/terminfo entry and make
it use your current terminal's entry plus \E[00m for the "op"

Finally, the "NC" capability (terminfo name: "ncv") tells Emacs which
attributes cannot be used with colors.  Setting this capability
incorrectly might have the effect of disabling colors; try setting
this capability to `0' (zero) and see if that helps.

Dave Love's avatar
Dave Love committed
440 441
Emacs uses the database entry for the terminal whose name is the value
of the environment variable TERM.  With `xterm', a common terminal
entry that supports color is `xterm-color', so setting TERM's value to
Dave Love's avatar
Dave Love committed
443 444
`xterm-color' might activate the color support on an xterm-compatible

Beginning with version 21.4, Emacs supports the --color command-line
447 448 449 450
option which may be used to force Emacs to use one of a few popular
modes for getting colors on a tty.  For example, --color=ansi8 sets up
for using the ANSI-standard escape sequences that support 8 colors.

Dave Love's avatar
Dave Love committed
451 452 453 454
Some modes do not use colors unless you turn on the Font-lock mode.
Some people have long ago set their `~/.emacs' files to turn on
Font-lock on X only, so they won't see colors on a tty.  The
recommended way of turning on Font-lock is by typing "M-x
455 456
global-font-lock-mode RET" or by customizing the variable

458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480
* Emacs on a tty switches the cursor to large blinking block.

This was reported to happen on some GNU/Linux systems which use
ncurses version 5.0, but could be relevant for other versions as well.
These versions of ncurses come with a `linux' terminfo entry, where
the "cvvis" capability (termcap "vs") is defined as "\E[?25h\E[?8c"
(show cursor, change size).  This escape sequence switches on a
blinking hardware text-mode cursor whose size is a full character
cell.  This blinking cannot be stopped, since a hardware cursor
always blinks.

A work-around is to redefine the "cvvis" capability so that it
enables a *software* cursor.  The software cursor works by inverting
the colors of the character at point, so what you see is a block
cursor that doesn't blink.  For this to work, you need to redefine
the "cnorm" capability as well, so that it operates on the software
cursor instead of the hardware cursor.

To this end, run "infocmp linux > linux-term", edit the file
`linux-term' to make both the "cnorm" and "cvvis" capabilities send
the sequence "\E[?25h\E[?17;0;64c", and then run "tic linux-term" to
produce a modified terminfo entry.

481 482 483
Alternatively, if you want a blinking underscore as your Emacs cursor,
change the "cvvis" capability to send the "\E[?25h\E[?0c" command.

484 485 486 487 488
* Problems in Emacs built with LessTif.

The problems seem to depend on the version of LessTif and the Motif
emulation for which it is set up.

Dave Love's avatar
Dave Love committed
489 490 491 492 493 494 495
Only the Motif 1.2 emulation seems to be stable enough in LessTif.
Lesstif 0.92-17's Motif 1.2 emulation seems to work okay on FreeBSD.
On GNU/Linux systems, lesstif-0.92.6 configured with "./configure
--enable-build-12 --enable-default-12" is reported to be the most
successful.  The binary GNU/Linux package
lesstif-devel-0.92.0-1.i386.rpm was reported to have problems with
menu placement.
496 497

On some systems, even with Motif 1.2 emulation, Emacs occasionally
Dave Love's avatar
Dave Love committed
498 499 500
locks up, grabbing all mouse and keyboard events.  We still don't know
what causes these problems; they are not reproducible by Emacs

* Known problems with the MS-Windows port of Emacs 21.2.

Frames are not refreshed while the File or Font dialog or a pop-up menu
Jason Rumney's avatar
Jason Rumney committed
is displayed. This also means help text for pop-up menus is not
506 507 508 509
displayed at all.  This is because message handling under Windows is
synchronous, so we cannot handle repaint (or any other) messages while
waiting for a system function to return the result of the dialog or
pop-up menu interaction.

Jason Rumney's avatar
Jason Rumney committed
511 512 513
Windows 95 and Windows NT up to version 4.0 do not support help text
for menus.  Help text is only available in later versions of Windows.

Jason Rumney's avatar
Jason Rumney committed
514 515 516 517
There are problems with display if mouse-tracking is enabled and the
mouse is moved off a frame, over another frame then back over the first
frame.  A workaround is to click the left mouse button inside the frame
after moving back into it.

Jason Rumney's avatar
Jason Rumney committed
519 520
Some minor flickering still persists during mouse-tracking, although
not as severely as in 21.1.
521 522 523 524 525 526 527

Emacs can sometimes abort when non-ASCII text, possibly with null
characters, is copied and pasted into a buffer.

An inactive cursor remains in an active window after the Windows
Manager driven switch of the focus, until a key is pressed.

Windows input methods are not recognized by Emacs (as of v21.2).  Some
529 530
of these input methods cause the keyboard to send characters encoded
in the appropriate coding system (e.g., ISO 8859-1 for Latin-1
531 532 533 534 535 536 537 538
characters, ISO 8859-8 for Hebrew characters, etc.).  To make this
work, set the keyboard coding system to the appropriate value after
you activate the Windows input method.  For example, if you activate
the Hebrew input method, type "C-x RET k iso-8859-8 RET".  (Emacs
ought to recognize the Windows language-change event and set up the
appropriate keyboard encoding automatically, but it doesn't do that

Dave Love's avatar
Dave Love committed
539 540 541
Windows uses UTF-16 encoding to deal with multilingual text (text not
encodable in the `system codepage') in the clipboard.  To deal with
this, load the library `utf-16' and use `set-selection-coding-system'
Dave Love's avatar
Dave Love committed
to set the clipboard coding system to `utf-16-le-with-signature-dos'.

544 545 546 547
The %b specifier for format-time-string does not produce abbreviated
month names with consistent widths for some locales on some versions
of Windows. This is caused by a deficiency in the underlying system
library function.

549 550
* The `configure' script doesn't find the jpeg library.

551 552 553 554 555 556 557 558 559
There are reports that this happens on some systems because the linker
by default only looks for shared libraries, but jpeg distribution by
default only installs a nonshared version of the library, `libjpeg.a'.

If this is the problem, you can configure the jpeg library with the
`--enable-shared' option and then rebuild libjpeg.  This produces a
shared version of libjpeg, which you need to install.  Finally, rerun
the Emacs configure script, which should now find the jpeg library.
Alternatively, modify the generated src/Makefile to link the .a file
explicitly, and edit src/config.h to define HAVE_JPEG.

562 563
* Building Emacs over NFS fails with ``Text file busy''.

564 565 566 567 568 569 570
This was reported to happen when building Emacs on a GNU/Linux system
(RedHat Linux 6.2) using a build directory automounted from Solaris
(SunOS 5.6) file server, but it might not be limited to that
configuration alone.  Presumably, the NFS server doesn't commit the
files' data to disk quickly enough, and the Emacs executable file is
left ``busy'' for several seconds after Emacs has finished dumping
itself.  This causes the subsequent commands which invoke the dumped
Emacs executable to fail with the above message.

Eli Zaretskii's avatar
Eli Zaretskii committed
573 574 575 576 577
In some of these cases, a time skew between the NFS server and the
machine where Emacs is built is detected and reported by GNU Make
(it says that some of the files have modification time in the future).
This might be a symptom of NFS-related problems.

578 579 580 581 582 583 584 585 586 587
If the NFS server runs on Solaris, apply the Solaris patch 105379-05
(Sunos 5.6: /kernel/misc/nfssrv patch).  If that doesn't work, or if
you have a different version of the OS or the NFS server, you can
force the NFS server to use 1KB blocks, which was reported to fix the
problem albeit at a price of slowing down file I/O.  You can force 1KB
blocks by specifying the "-o  rsize=1024,wsize=1024" options to the
`mount' command, or by adding ",rsize=1024,wsize=1024" to the mount
options in the appropriate system configuration file, such as

588 589 590 591
Alternatively, when Make fails due to this problem, you could wait for
a few seconds and then invoke Make again.  In one particular case,
waiting for 10 or more seconds between the two Make invocations seemed
to work around the problem.

593 594 595 596 597 598 599 600 601
Similar problems can happen if your machine NFS-mounts a directory
onto itself.  Suppose the Emacs sources live in `/usr/local/src' and
you are working on the host called `marvin'.  Then an entry in the
`/etc/fstab' file like the following is asking for trouble:

    marvin:/usr/local/src /usr/local/src ...options.omitted...

The solution is to remove this line from `etc/fstab'.

602 603 604
* Emacs binary is not in executable format, and cannot be run.

This was reported to happen when Emacs is built in a directory mounted
Stefan Monnier's avatar
Stefan Monnier committed
605 606
via NFS, for some combinations of NFS client and NFS server.
Usually, the file `emacs' produced in these cases is full of
607 608 609 610 611 612 613
binary null characters, and the `file' utility says:

    emacs: ASCII text, with no line terminators

We don't know what exactly causes this failure.  A work-around is to
build Emacs in a directory on a local disk.

Dave Love's avatar
Dave Love committed
* Accented ISO-8859-1 characters are displayed as | or _.
615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633

Try other font set sizes (S-mouse-1).  If the problem persists with
other sizes as well, your text is corrupted, probably through software
that is not 8-bit clean.  If the problem goes away with another font
size, it's probably because some fonts pretend to be ISO-8859-1 fonts
when they are really ASCII fonts. In particular the schumacher-clean
fonts have this bug in some versions of X.

To see what glyphs are included in a font, use `xfd', like this:

  xfd -fn -schumacher-clean-medium-r-normal--12-120-75-75-c-60-iso8859-1

If this shows only ASCII glyphs, the font is indeed the source of the

The solution is to remove the corresponding lines from the appropriate
`fonts.alias' file, then run `mkfontdir' in that directory, and then run
`xset fp rehash'.

Dave Love's avatar
Dave Love committed
634 635 636
* Large file support is disabled on HP-UX.  See the comments in

* Crashes when displaying GIF images in Emacs built with version
Dave Love's avatar
Dave Love committed
libungif-4.1.0 are resolved by using version libungif-4.1.0b1.
Dave Love's avatar
Dave Love committed
639 640 641
Configure checks for the correct version, but this problem could occur
if a binary built against a shared libungif is run on a system with an
older version.

Colin Walters's avatar
Colin Walters committed
* Font Lock displays portions of the buffer in incorrect faces.
644 645 646 647 648 649 650

By far the most frequent cause of this is a parenthesis `(' or a brace
`{' in column zero.  Font Lock assumes that such a paren is outside of
any comment or string.  This is of course not true in general, but the
vast majority of well-formatted program source files don't have such
parens, and therefore this assumption is used to allow optimizations
in Font Lock's syntactical analysis.  These optimizations avoid some
pathological cases where jit-lock, the Just-in-Time fontification
652 653 654 655
introduced with Emacs 21.1, could significantly slow down scrolling
through the buffer, especially scrolling backwards, and also jumping
to the end of a very large buffer.

Beginning with version 21.4, a parenthesis or a brace in column zero
657 658 659
is highlighted in bold-red face if it is inside a string or a comment,
to indicate that it could interfere with Font Lock (and also with
indentation) and should be moved or escaped with a backslash.

661 662 663 664 665 666 667 668 669
If you don't use large buffers, or have a very fast machine which
makes the delays insignificant, you can avoid the incorrect
fontification by setting the variable
`font-lock-beginning-of-syntax-function' to a nil value.  (This must
be done _after_ turning on Font Lock.)

Another alternative is to avoid a paren in column zero.  For example,
in a Lisp string you could precede the paren with a backslash.

670 671 672
* When running on KDE, colors or fonts are not as specified for Emacs,
or messed up.

For example, you could see background you set for Emacs only in the
674 675 676 677 678 679
empty portions of the Emacs display, while characters have some other

This happens because KDE's defaults apply its color and font
definitions even to applications that weren't compiled for KDE.  The
solution is to uncheck the "Apply fonts and colors to non-KDE apps"
Glenn Morris's avatar
Glenn Morris committed
680 681
option in Preferences->Look&Feel->Style (KDE 2).  In KDE 3, this option
is in the "Colors" section, rather than "Style".
682 683 684 685 686 687 688 689 690 691 692 693 694

Alternatively, if you do want the KDE defaults to apply to other
applications, but not to Emacs, you could modify the file `'
(should be in the `/usr/share/apps/kdisplay/app-defaults/' directory)
so that it doesn't set the default background and foreground only for
Emacs.  For example, make sure the following resources are either not
present or commented out:


695 696 697 698 699 700 701 702
* Interrupting Cygwin port of Bash from Emacs doesn't work.

Cygwin 1.x builds of the ported Bash cannot be interrupted from the
MS-Windows version of Emacs.  This is due to some change in the Bash
port or in the Cygwin library which apparently make Bash ignore the
keyboard interrupt event sent by Emacs to Bash.  (Older Cygwin ports
of Bash, up to b20.1, did receive SIGINT from Emacs.)

703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719
* Dired is very slow.

This could happen if invocation of the `df' program takes a long
time.  Possible reasons for this include:

  - ClearCase mounted filesystems (VOBs) that sometimes make `df'
    response time extremely slow (dozens of seconds);

  - slow automounters on some old versions of Unix;

  - slow operation of some versions of `df'.

To work around the problem, you could either (a) set the variable
`directory-free-space-program' to nil, and thus prevent Emacs from
invoking `df'; (b) use `df' from the GNU Fileutils package; or
(c) use CVS, which is Free Software, instead of ClearCase.

720 721 722 723 724 725 726 727 728 729 730
* Accessing remote files with ange-ftp hangs the MS-Windows version of Emacs.

If the FTP client is the Cygwin port of GNU `ftp', this appears to be
due to some bug in the Cygwin DLL or some incompatibility between it
and the implementation of asynchronous subprocesses in the Windows
port of Emacs.  Specifically, some parts of the FTP server responses
are not flushed out, apparently due to buffering issues, which
confuses ange-ftp.

The solution is to downgrade to an older version of the Cygwin DLL
(version 1.3.2 was reported to solve the problem), or use the stock
731 732 733 734
Windows FTP client, usually found in the `C:\WINDOWS' or 'C:\WINNT'
directory.  To force ange-ftp use the stock Windows client, set the
variable `ange-ftp-ftp-program-name' to the absolute file name of the
client's executable.  For example:
735 736 737 738 739 740 741 742

 (setq ange-ftp-ftp-program-name "c:/windows/ftp.exe")

If you want to stick with the Cygwin FTP client, you can work around
this problem by putting this in your `.emacs' file:

 (setq ange-ftp-ftp-program-args '("-i" "-n" "-g" "-v" "--prompt" "")

Dave Love's avatar
Dave Love committed
743 744
* Versions of the W3 package released before Emacs 21.1 don't run
under Emacs 21.  This fixed in W3 version 4.0pre.47.
Dave Love's avatar
Dave Love committed

Gerd Moellmann's avatar
Gerd Moellmann committed
746 747 748 749 750
* On AIX, if linking fails because libXbsd isn't found, check if you
are compiling with the system's `cc' and CFLAGS containing `-O5'.  If
so, you have hit a compiler bug.  Please make sure to re-configure
Emacs so that it isn't compiled with `-O5'.

* Compiling on AIX 4.3.x or 4.4 fails.
Eli Zaretskii's avatar
Eli Zaretskii committed

Pavel Janík's avatar
Pavel Janík committed
This could happen if you use /bin/c89 as your compiler, instead of
754 755 756 757
the default `cc'.  /bin/c89 treats certain warnings, such as benign
redefinitions of macros, as errors, and fails the build.  A solution
is to use the default compiler `cc'.

* Old versions of the PSGML package use the obsolete variables
Dave Love's avatar
Dave Love committed
`before-change-function' and `after-change-function', which are no
Pavel Janík's avatar
Pavel Janík committed
longer used by Emacs.  Please use PSGML 1.2.3 or later.

762 763 764 765 766 767 768 769 770 771
* PSGML conflicts with sgml-mode.

PSGML package uses the same names of some variables (like keymap)
as built-in sgml-mode.el because it was created as a replacement
of that package.  The conflict will be shown if you load
sgml-mode.el before psgml.el.  E.g. this could happen if you edit
HTML page and then start to work with SGML or XML file.  html-mode
(from sgml-mode.el) is used for HTML file and loading of psgml.el
(for sgml-mode or xml-mode) will cause an error.

772 773 774 775 776 777 778
* The LDAP support rely on ldapsearch program from OpenLDAP version 2.

It can fail to work with ldapsearch program from OpenLDAP version 1.
Version 1 of OpenLDAP is now deprecated.  If you are still using it,
please upgrade to version 2.  As a temporary workaround, remove
argument "-x" from the variable `ldap-ldapsearch-args'.

779 780
* The `oc-unicode' package doesn't work with Emacs 21.

Dave Love's avatar
Dave Love committed
This package tries to define more private charsets than there are free
Dave Love's avatar
Dave Love committed
782 783 784 785
slots now.  The current built-in Unicode support is actually more
flexible.  (Use option `utf-translate-cjk-mode' if you need CJK
support.)  Files encoded as emacs-mule using oc-unicode aren't
generally read correctly by Emacs 21.

787 788 789 790 791 792 793 794 795 796 797
* Using epop3.el package causes Emacs to signal an error.

The error message might be something like this:

  "Lisp nesting exceeds max-lisp-eval-depth"

This happens because epop3 redefines the function gethash, which is a
built-in primitive beginning with Emacs 21.1.  We don't have a patch
for epop3 that fixes this, but perhaps a newer version of epop3
corrects that.

798 799 800 801 802 803 804 805
* ps-print commands fail to find prologue files ps-prin*.ps.

This can happen if you use an old version of X-Symbol package: it
defines compatibility functions which trick ps-print into thinking it
runs in XEmacs, and look for the prologue files in a wrong directory.

The solution is to upgrade X-Symbol to a later version.

806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821
* lpr commands don't work on MS-Windows with some cheap printers.

This problem may also strike other platforms, but the solution is
likely to be a global one, and not Emacs specific.

Many cheap inkjet, and even some cheap laser printers, do not
print plain text anymore, they will only print through graphical
printer drivers. A workaround on MS-Windows is to use Windows' basic
built in editor to print (this is possibly the only useful purpose it

(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

Gerd Moellmann's avatar
Gerd Moellmann committed
822 823 824 825 826 827
* On systems with shared libraries you might encounter run-time errors
from the dynamic linker telling you that it is unable to find some
shared libraries, for instance those for Xaw3d or image support.
These errors mean Emacs has been linked with a library whose shared
library is not in the default search path of the dynamic linker.

828 829 830
Similar problems could prevent Emacs from building, since the build
process invokes Emacs several times.

Gerd Moellmann's avatar
Gerd Moellmann committed
831 832 833 834 835 836 837 838
On many systems, it is possible to set LD_LIBRARY_PATH in your
environment to specify additional directories where shared libraries
can be found.

Other systems allow to set LD_RUN_PATH in a similar way, but before
Emacs is linked.  With LD_RUN_PATH set, the linker will include a
specified run-time search path in the executable.

Richard M. Stallman's avatar
Richard M. Stallman committed
On some systems, Emacs can crash due to problems with dynamic
840 841 842 843 844 845 846 847 848 849 850 851 852 853
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]

Richard M. Stallman's avatar
Richard M. Stallman committed
854 855
(`rld' is the dynamic linker.)  We don't know yet why this
happens, but setting the environment variable LD_BIND_NOW to 1 (which
856 857 858
forces the dynamic linker to bind all shared objects early on) seems
to work around the problem.

Gerd Moellmann's avatar
Gerd Moellmann committed
859 860
Please refer to the documentation of your dynamic linker for details.

Gerd Moellmann's avatar
Gerd Moellmann committed
* On Solaris 2.7, building Emacs with WorkShop Compilers 5.0 98/12/15
Dave Love's avatar
Dave Love committed
862 863 864 865 866
C 5.0 failed, apparently with non-default CFLAGS, most probably due to
compiler bugs.  Using Sun Solaris 2.7 Sun WorkShop 6 update 1 C
release was reported to work without problems.  It worked OK on
another system with Solaris 8 using apparently the same 5.0 compiler
and the default CFLAGS.
Gerd Moellmann's avatar
Gerd Moellmann committed

868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886
* Compiling syntax.c with the OPENSTEP 4.2 compiler gcc fails.

The compiler was reported to crash while compiling syntax.c with the
following message:

   cc: Internal compiler error: program cc1obj got fatal signal 11

To work around this, replace the macros UPDATE_SYNTAX_TABLE_FORWARD,
INC_BOTH, and INC_FROM with functions.  To this end, first define 3
functions, one each for every macro.  Here's an example:

    static int update_syntax_table_forward(int from)

Then replace all references to UPDATE_SYNTAX_TABLE_FORWARD in syntax.c
with a call to the function update_syntax_table_forward.

887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906
* Emacs fails to start, complaining about missing fonts.

A typical error message might be something like

  No fonts match `-*-fixed-medium-r-*--6-*-*-*-*-*-iso8859-1'

This happens because some X resource specifies a bad font family for
Emacs to use.  The possible places where this specification might be

  - in your ~/.Xdefaults file

  - client-side X resource file, such as  ~/Emacs or
    /usr/X11R6/lib/app-defaults/Emacs or

One of these files might have bad or malformed specification of a
fontset that Emacs should use.  To fix the problem, you need to find
the problematic line(s) and correct them.

907 908 909 910 911 912 913 914 915 916 917 918
* Emacs 20 and later fails to load Lisp files at startup.

The typical error message might be like this:

  "Cannot open load file: fontset"

This could happen if you compress the file lisp/subdirs.el.  That file
tells Emacs what are the directories where it should look for Lisp
files.  Emacs cannot work with subdirs.el compressed, since the
Auto-compress mode it needs for this will not be loaded until later,
when your .emacs file is processed.  (The package `fontset.el' is
required to set up fonts used to display text on window systems, and
Pavel Janík's avatar
Pavel Janík committed
it's loaded very early in the startup procedure.)
920 921 922 923 924 925 926

Similarly, any other .el file for which there's no corresponding .elc
file could fail to load if it is compressed.

The solution is to uncompress all .el files which don't have a .elc

927 928 929 930 931 932 933 934 935 936
Another possible reason for such failures is stale *.elc files
lurking somewhere on your load-path.  The following command will
print any duplicate Lisp files that are present in load-path:

    emacs -q -batch -f list-load-path-shadows

If this command prints any file names, some of these files are stale,
and should be deleted or their directories removed from your

Jason Rumney's avatar
Jason Rumney committed
937 938 939 940
* Emacs prints an error at startup after upgrading from an earlier version.

An example of such an error is:

  x-complement-fontset-spec: "Wrong type argument: stringp, nil"
Jason Rumney's avatar
Jason Rumney committed
942 943 944 945 946 947 948 949 950 951 952

This can be another symptom of stale *.elc files in your classpath.
The following command will print any duplicate Lisp files that are
present in load-path:

    emacs -q -batch -f list-load-path-shadows

If this command prints any file names, some of these files are stale,
and should be deleted or their directories removed from your

953 954 955 956
* Attempting to visit remote files via ange-ftp fails.

If the error message is "ange-ftp-file-modtime: Specified time is not
representable", then this could happen when `lukemftp' is used as the
957 958 959 960
ftp client.  This was reported to happen on Debian GNU/Linux, kernel
version 2.4.3, with `lukemftp' 1.5-5, but might happen on other
systems as well.  To avoid this problem, switch to using the standard
ftp client.  On a Debian system, type

  update-alternatives --config ftp
963 964 965

and then choose /usr/bin/netkit-ftp.

966 967 968 969 970 971 972 973 974 975 976
* Antivirus software interacts badly with the MS-Windows version of Emacs.

The usual manifestation of these problems is that subprocesses don't
work or even wedge the entire system.  In particular, "M-x shell RET"
was reported to fail to work.  But other commands also sometimes don't
work when an antivirus package is installed.

The solution is to switch the antivirus software to a less aggressive
mode (e.g., disable the ``auto-protect'' feature), or even uninstall
or disable it entirely.

* On MS-Windows 95/98/ME, subprocesses do not terminate properly.
978 979 980 981

This is a limitation of the Operating System, and can cause problems
when shutting down Windows. Ensure that all subprocesses are exited
cleanly before exiting Emacs. For more details, see the FAQ at

* MS-Windows 95/98/ME crashes when Emacs invokes non-existent programs.

When a program you are trying to run is not found on the PATH,
Windows might respond by crashing or locking up your system.  In
Eli Zaretskii's avatar
Eli Zaretskii committed
particular, this has been reported when trying to compile a Java
Eli Zaretskii's avatar
Eli Zaretskii committed
program in JDEE when javac.exe is installed, but not on the system
Eli Zaretskii's avatar
Eli Zaretskii committed

992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008
* Pressing the mouse button on MS-Windows does not give a mouse-2 event.

This is usually a problem with the mouse driver. Because most Windows
programs do not do anything useful with the middle mouse button, many
mouse drivers allow you to define the wheel press to do something
different. Some drivers do not even have the option to generate a
middle button press. In such cases, setting the wheel press to
"scroll" sometimes works if you press the button twice. Trying a
generic mouse driver might help.

* Scrolling the mouse wheel on MS-Windows always scrolls the top window.

This is another common problem with mouse drivers. Instead of
generating scroll events, some mouse drivers try to fake scroll bar
movement. But they are not intelligent enough to handle multiple
scroll bars within a frame. Trying a generic mouse driver might help.

Dave Love's avatar
Dave Love committed
1009 1010 1011 1012 1013
* Mail sent through Microsoft Exchange in some encodings appears to be
mangled and is not seen correctly in Rmail or Gnus.  We don't know
exactly what happens, but it isn't an Emacs problem in cases we've

1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044
* After upgrading to a newer version of Emacs, the Meta key stops working.

This was reported to happen on a GNU/Linux system distributed by
Mandrake.  The reason is that the previous version of Emacs was
modified by Mandrake to make the Alt key act as the Meta key, on a
keyboard where the Windows key is the one which produces the Meta
modifier.  A user who started using a newer version of Emacs, which
was not hacked by Mandrake, expected the Alt key to continue to act as
Meta, and was astonished when that didn't happen.

The solution is to find out what key on your keyboard produces the Meta
modifier, and use that key instead.  Try all of the keys to the left
and to the right of the space bar, together with the `x' key, and see
which combination produces "M-x" in the echo area.  You can also use
the `xmodmap' utility to show all the keys which produce a Meta

         xmodmap -pk | egrep -i "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:

         xkbprint 0:0 /tmp/

This produces a PostScript file `/tmp/' with a picture of your
keyboard; printing that file on a PostScript printer will show what
keys can serve as Meta.

The `xkeycaps' also shows a visual representation of the current
keyboard settings.  It also allows to modify them.

Dave Love's avatar
Dave Love committed
1045 1046 1047 1048 1049 1050
* On OSF/Dec Unix/Tru64/<whatever it is this year> under X locally or
remotely, M-SPC acts as a `compose' key with strange results.  See

Changing Alt_L to Meta_L fixes it:
% xmodmap -e 'keysym Alt_L = Meta_L Alt_L'
% xmodmap -e 'keysym Alt_R = Meta_R Alt_R'
Dave Love's avatar
Dave Love committed

Dave Love's avatar
Dave Love committed
1053 1054 1055 1056 1057 1058 1059
* Error "conflicting types for `initstate'" compiling with GCC on Irix 6.

Install GCC 2.95 or a newer version, and this problem should go away.
It is possible that this problem results from upgrading the operating
system without reinstalling GCC; so you could also try reinstalling
the same version of GCC, and telling us whether that fixes the problem.

1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070
* Emacs dumps core on Solaris in function IMCheckWindow.

This was reported to happen when Emacs runs with more than one frame,
and one of them is closed, either with "C-x 5 0" or from the window

This bug was reported to Sun as

    Gtk apps dump core in
    Bug Reports: 4463537

Eli Zaretskii's avatar
Eli Zaretskii committed
Installing Solaris 8 patch 108773-12 for Sparc and 108774-12 for x86
1072 1073 1074 1075 1076 1077 1078
reportedly fixes the bug, which appears to be inside the shared

Alternatively, you can configure Emacs with `--with-xim=no' to prevent
the core dump, but will loose X input method support, of course.  (You
can use Emacs's own input methods instead, if you install Leim.)

Dave Love's avatar
Dave Love committed
1079 1080 1081
* On Solaris 7, Emacs gets a segmentation fault when starting up using X.

This results from Sun patch 107058-01 (SunOS 5.7: Patch for
1082 1083 1084
assembler) if you use GCC version 2.7 or later.
To work around it, either install patch 106950-03 or later,
or uninstall patch 107058-01, or install the GNU Binutils.
Dave Love's avatar
Dave Love committed
1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125
Then recompile Emacs, and it should work.

* With X11R6.4, public-patch-3, Emacs crashes at startup.

Reportedly this patch in X fixes the problem.

    --- xc/lib/X11/imInt.c~	Wed Jun 30 13:31:56 1999
    +++ xc/lib/X11/imInt.c	Thu Jul  1 15:10:27 1999
    @@ -1,4 +1,4 @@
    -/* $TOG: imInt.c /main/5 1998/05/30 21:11:16 kaleb $ */
    +/* $TOG: imInt.c /main/5 1998/05/30 21:11:16 kaleb $  */

		Copyright 1992, 1993, 1994 by FUJITSU LIMITED
    @@ -166,8 +166,8 @@
	 XLCd	   lcd;
    -    char* begin;
    -    char* end;
    +    char* begin = NULL;
    +    char* end = NULL;
	 char* ret;
	 int	i = 0;
	 char* ximmodifier = XIMMODIFIER;
    @@ -182,7 +182,11 @@
	 ret = Xmalloc(end - begin + 2);
	 if (ret != NULL) {
    -    	(void)strncpy(ret, begin, end - begin + 1);
    +	if (begin != NULL) {
    +      	  (void)strncpy(ret, begin, end - begin + 1);
    +        } else {
    +	  ret[0] = '\0';
    +	}
	    ret[end - begin + 1] = '\0';
	 return ret;

* Emacs crashes on Irix 6.5 on the SGI R10K, when compiled with GCC.

Dave Love's avatar
Dave Love committed
1127 1128 1129 1130 1131 1132 1133
This seems to be fixed in GCC 2.95.

* Emacs crashes in utmpname on Irix 5.3.

This problem is fixed in Patch 3175 for Irix 5.3.
It is also fixed in Irix versions 6.2 and up.

1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144
* The S-C-t key combination doesn't get passed to Emacs on X.

This happens because some X configurations assign the Ctrl-Shift-t
combination the same meaning as the Multi_key.  The offending
definition is in the file `...lib/X11/locale/iso8859-1/Compose'; there
might be other similar combinations which are grabbed by X for similar

We think that this can be countermanded with the `xmodmap' utility, if
you want to be able to bind one of these key sequences within Emacs.

Dave Love's avatar
Dave Love committed
1145 1146 1147 1148 1149 1150
* On Solaris, CTRL-t is ignored by Emacs when you use
the fr.ISO-8859-15 locale (and maybe other related locales).

You can fix this by editing the file:


Dave Love's avatar
Dave Love committed
1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186
Near the bottom there is a line that reads:

	Ctrl<t> <quotedbl> <Y>                  : "\276"        threequarters

that should read:

	Ctrl<T> <quotedbl> <Y>                  : "\276"        threequarters

Note the lower case <t>.  Changing this line should make C-t work.

* Emacs on Digital Unix 4.0 fails to build, giving error message
     Invalid dimension for the charset-ID 160

This is due to a bug or an installation problem in GCC 2.8.0.
Installing a more recent version of GCC fixes the problem.

* Buffers from `with-output-to-temp-buffer' get set up in Help mode.

Changes in Emacs 20.4 to the hooks used by that function cause
problems for some packages, specifically BBDB.  See the function's
documentation for the hooks involved.  BBDB 2.00.06 fixes the problem.

* Under X, C-v and/or other keys don't work.

These may have been intercepted by your window manager.  In
particular, AfterStep 1.6 is reported to steal C-v in its default
configuration.  Various Meta keys are also likely to be taken by the
configuration of the `feel'.  See the WM's documentation for how to
change this.

* When using Exceed, fonts sometimes appear too tall.

When the display is set to an Exceed X-server and fonts are specified
(either explicitly with the -fn option or implicitly with X resources)
then the fonts may appear "too tall".  The actual character sizes are
1187 1188
correct but there is too much vertical spacing between rows,  which
gives the appearance of "double spacing".
Dave Love's avatar
Dave Love committed

To prevent this, turn off the Exceed's "automatic font substitution"
Dave Love's avatar
Dave Love committed
1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254
feature (in the font part of the configuration window).

* Failure in unexec while dumping emacs on Digital Unix 4.0

This problem manifests itself as an error message

    unexec: Bad address, writing data section to ...

The user suspects that this happened because his X libraries
were built for an older system version,

    ./configure --x-includes=/usr/include --x-libraries=/usr/shlib

made the problem go away.

* No visible display on mips-sgi-irix6.2 when compiling with GCC 2.8.1.

This problem went away after installing the latest IRIX patches
as of 8 Dec 1998.

The same problem has been reported on Irix 6.3.

* As of version 20.4, Emacs doesn't work properly if configured for
the Motif toolkit and linked against the free LessTif library.  The
next Emacs release is expected to work with LessTif.

* Emacs gives the error, Couldn't find per display information.

This can result if the X server runs out of memory because Emacs uses
a large number of fonts.  On systems where this happens, C-h h is
likely to cause it.

We do not know of a way to prevent the problem.

* Emacs makes HPUX 11.0 crash.

This is a bug in HPUX; HPUX patch PHKL_16260 is said to fix it.

* Emacs crashes during dumping on the HPPA machine (HPUX 10.20).

This seems to be due to a GCC bug; it is fixed in GCC 2.8.1.

* The Hyperbole package causes *Help* buffers not to be displayed in
Help mode due to setting `temp-buffer-show-hook' rather than using
`add-hook'.  Using `(add-hook 'temp-buffer-show-hook
'help-mode-maybe)' after loading Hyperbole should fix this.

* Versions of the PSGML package earlier than 1.0.3 (stable) or 1.1.2
(alpha) fail to parse DTD files correctly in Emacs 20.3 and later.
Here is a patch for psgml-parse.el from PSGML 1.0.1 and, probably,
earlier versions.

--- psgml-parse.el	1998/08/21 19:18:18	1.1
+++ psgml-parse.el	1998/08/21 19:20:00
@@ -2383,7 +2383,7 @@ (defun sgml-push-to-entity (entity &opti
       (setq sgml-buffer-parse-state nil))
      ((stringp entity)			; a file name
-      (save-excursion (insert-file-contents entity))
+      (insert-file-contents entity)
       (setq default-directory (file-name-directory entity)))
      ((consp (sgml-entity-text entity)) ; external id?
       (let* ((extid (sgml-entity-text entity))

1255 1256 1257 1258 1259
* Emacs 21 freezes when visiting a TeX file with AUC TeX installed.

Emacs 21 needs version 10 or later of AUC TeX; upgrading should solve
these problems.

1260 1261 1262 1263 1264
* No colors in AUC TeX with Emacs 21.

Upgrade to AUC TeX version 10 or later, and make sure it is
byte-compiled with Emacs 21.

* Running TeX from AUC TeX package with Emacs 20.3 gives a Lisp error
Dave Love's avatar
Dave Love committed
1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305
about a read-only tex output buffer.

This problem appeared for AUC TeX version 9.9j and some earlier
versions.  Here is a patch for the file tex-buf.el in the AUC TeX

diff -c auctex/tex-buf.el~ auctex/tex-buf.el
*** auctex/tex-buf.el~	Wed Jul 29 18:35:32 1998
--- auctex/tex-buf.el	Sat Sep  5 15:20:38 1998
*** 545,551 ****
  	(dir (TeX-master-directory)))
      (TeX-process-check file)		; Check that no process is running
      (setq TeX-command-buffer (current-buffer))
!     (with-output-to-temp-buffer buffer)
      (set-buffer buffer)
      (if dir (cd dir))
      (insert "Running `" name "' on `" file "' with ``" command "''\n")
- --- 545,552 ----
  	(dir (TeX-master-directory)))
      (TeX-process-check file)		; Check that no process is running
      (setq TeX-command-buffer (current-buffer))
!     (let (temp-buffer-show-function temp-buffer-show-hook)
!       (with-output-to-temp-buffer buffer))
      (set-buffer buffer)
      (if dir (cd dir))
      (insert "Running `" name "' on `" file "' with ``" command "''\n")

* On Irix 6.3, substituting environment variables in file names
in the minibuffer gives peculiar error messages such as

   Substituting nonexistent environment variable ""

This is not an Emacs bug; it is caused by something in SGI patch
003082 August 11, 1998.

* After a while, Emacs slips into unibyte mode.

The VM mail package, which is not part of Emacs, sometimes does
  (standard-display-european t)
That should be changed to
Dave Love's avatar
Dave Love committed
1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333
  (standard-display-european 1 t)

* Installing Emacs gets an error running `install-info'.

You need to install a recent version of Texinfo; that package
supplies the `install-info' command.

* Emacs does not recognize the AltGr key, on HPUX.

To fix this, set up a file ~/.dt/sessions/sessionetc with executable
rights, containing this text:

xmodmap 2> /dev/null - << EOF
keysym Alt_L = Meta_L
keysym Alt_R = Meta_R

xmodmap - << EOF
clear mod1
keysym Mode_switch = NoSymbol
add mod1 = Meta_L
keysym Meta_R = Mode_switch
add mod2 = Mode_switch

1334 1335
* Emacs hangs on KDE when a large portion of text is killed.

1336 1337 1338 1339 1340
This is caused by a bug in the KDE applet `klipper' which periodically
requests the X clipboard contents from applications.  Early versions
of klipper don't implement the ICCM protocol for large selections,
which leads to Emacs being flooded with selection requests.  After a
while, Emacs will print a message:
1341 1342 1343

  Timed out waiting for property-notify event

A workaround is to not use `klipper'.

Dave Love's avatar
Dave Love committed
1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379
* Emacs compiled with DJGPP for MS-DOS/MS-Windows cannot access files
in the directory with the special name `dev' under the root of any
drive, e.g. `c:/dev'.

This is an unfortunate side-effect of the support for Unix-style
device names such as /dev/null in the DJGPP runtime library.  A
work-around is to rename the problem directory to another name.

* M-SPC seems to be ignored as input.

See if your X server is set up to use this as a command
for character composition.

* Emacs startup on GNU/Linux systems (and possibly other systems) is slow.

This can happen if the system is misconfigured and Emacs can't get the
full qualified domain name, FQDN.  You should have your FQDN in the
/etc/hosts file, something like this:	localhost	nuc04

The way to set this up may vary on non-GNU systems.

* Garbled display on non-X terminals when Emacs runs on Digital Unix 4.0.

So far it appears that running `tset' triggers this problem (when TERM
is vt100, at least).  If you do not run `tset', then Emacs displays
properly.  If someone can tell us precisely which effect of running
`tset' actually causes the problem, we may be able to implement a fix
in Emacs.

* When you run Ispell from Emacs, it reports a "misalignment" error.

1380 1381 1382 1383
This can happen if you compiled the Ispell program to use ASCII
characters only and then try to use it from Emacs with non-ASCII
characters, like Latin-1.  The solution is to recompile Ispell with
support for 8-bit characters.
Dave Love's avatar
Dave Love committed

1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405
To see whether your Ispell program supports 8-bit characters, type
this at your shell's prompt:

     ispell -vv

and look in the output for the string "NO8BIT".  If Ispell says
"!NO8BIT (8BIT)", your speller supports 8-bit characters; otherwise it
does not.

To rebuild Ispell with 8-bit character support, edit the local.h file
in the Ispell distribution and make sure it does _not_ define NO8BIT.
Then rebuild the speller.

Another possible cause for "misalignment" error messages is that the
version of Ispell installed on your machine is old.  Upgrade.

Yet another possibility is that you are trying to spell-check a word
in a language that doesn't fit the dictionary you choose for use by
Ispell.  (Ispell can only spell-check one language at a time, because
it uses a single dictionary.)  Make sure that the text you are
spelling and the dictionary used by Ispell conform to each other.
Dave Love's avatar
Dave Love committed

Glenn Morris's avatar
Glenn Morris committed
1407 1408 1409 1410 1411
If your spell-checking program is Aspell, it has been reported that if
you have a personal configuration file (normally ~/.aspell.conf), it
can cause this error.  Remove that file, execute `ispell-kill-ispell'
in Emacs, and then try spell-checking again.

Dave Love's avatar
Dave Love committed
1412 1413 1414 1415 1416 1417 1418
* On Linux-based GNU systems using libc versions 5.4.19 through
5.4.22, Emacs crashes at startup with a segmentation fault.

This problem happens if libc defines the symbol __malloc_initialized.
One known solution is to upgrade to a newer libc version.  5.4.33 is
known to work.

* On MS-Windows, you cannot use the right-hand ALT key and the left-hand
Dave Love's avatar
Dave Love committed
1420 1421 1422 1423 1424 1425 1426 1427
CTRL key together to type a Control-Meta character.

This is a consequence of a misfeature beyond Emacs's control.

Under Windows, the AltGr key on international keyboards generates key
events with the modifiers Right-Alt and Left-Ctrl.  Since Emacs cannot
distinguish AltGr from an explicit Right-Alt and Left-Ctrl
combination, whenever it sees Right-Alt and Left-Ctrl it assumes that
1428 1429
AltGr has been pressed.  The variable `w32-recognize-altgr' can be set
to nil to tell Emacs that AltGr is really Ctrl and Alt.
Dave Love's avatar
Dave Love committed

Eli Zaretskii's avatar
Eli Zaretskii committed
1431 1432 1433 1434 1435
* Emacs crashes when using the Exceed 6.0 X server

If you are using Exceed 6.1, upgrade to a later version.  This was
reported to prevent the crashes.

* Under some X-servers running on MS-Windows, Emacs' display is incorrect
Dave Love's avatar
Dave Love committed
1437 1438 1439 1440 1441 1442

The symptoms are that Emacs does not completely erase blank areas of the
screen during scrolling or some other screen operations (e.g., selective
display or when killing a region).  M-x recenter will cause the screen
to be completely redisplayed and the "extra" characters will disappear.

1443 1444 1445
This is known to occur under Exceed 6, and possibly earlier versions
as well; it is reportedly solved in version and later.  The
problem lies in the X-server settings.
Dave Love's avatar
Dave Love committed
1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470

There are reports that you can solve the problem with Exceed by
running `Xconfig' from within NT, choosing "X selection", then
un-checking the boxes "auto-copy X selection" and "auto-paste to X

Of this does not work, please inform  Then
please call support for your X-server and see if you can get a fix.
If you do, please send it to so we can list it

* On Solaris 2, Emacs dumps core when built with Motif.

The Solaris Motif libraries are buggy, at least up through Solaris 2.5.1.
Install the current Motif runtime library patch appropriate for your host.
(Make sure the patch is current; some older patch versions still have the bug.)
You should install the other patches recommended by Sun for your host, too.
You can obtain Sun patches from;
look for files with names ending in `.PatchReport' to see which patches
are currently recommended for your host.

On Solaris 2.6, Emacs is said to work with Motif when Solaris patch
105284-12 is installed, but fail when 105284-15 is installed.
105284-18 might fix it again.

1471 1472 1473 1474 1475 1476
* On Solaris 2.6 and 7, the Compose key does not work.

This is a bug in Motif in Solaris.  Supposedly it has been fixed for
the next major release of Solaris.  However, if someone with Sun
support complains to Sun about the bug, they may release a patch.
If you do this, mention Sun bug #4188711.
Dave Love's avatar
Dave Love committed
1477 1478 1479 1480 1481 1482 1483

One workaround is to use a locale that allows non-ASCII characters.
For example, before invoking emacs, set the LC_ALL environment
variable to "en_US" (American English).  The directory /usr/lib/locale
lists the supported locales; any locale other than "C" or "POSIX"
should do.

1484 1485 1486 says (Feb 1998) that the Compose key does work
if you link with the MIT X11 libraries instead of the Solaris X11
Dave Love's avatar
Dave Love committed

1488 1489 1490 1491 1492 1493 1494
* Frames may cover dialogs they created when using CDE.

This can happen if you have "Allow Primary Windows On Top" enabled which
seems to be the default in the Common Desktop Environment.
To change, go in to "Desktop Controls" -> "Window Style Manager"
and uncheck "Allow Primary Windows On Top".

Dave Love's avatar
Dave Love committed
1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556
* Emacs does not know your host's fully-qualified domain name.

You need to configure your machine with a fully qualified domain name,
either in /etc/hosts, /etc/hostname, the NIS, or wherever your system
calls for specifying this.

If you cannot fix the configuration, you can set the Lisp variable
mail-host-address to the value you want.

* Error 12 (virtual memory exceeded) when dumping Emacs, on UnixWare 2.1

Paul Abrahams ( reports that with the installed
virtual memory settings for UnixWare 2.1.2, an Error 12 occurs during
the "make" that builds Emacs, when running temacs to dump emacs.  That
error indicates that the per-process virtual memory limit has been
exceeded.  The default limit is probably 32MB.  Raising the virtual
memory limit to 40MB should make it possible to finish building Emacs.

You can do this with the command `ulimit' (sh) or `limit' (csh).
But you have to be root to do it.

According to Martin Sohnius, you can also retune this in the kernel:

    # /etc/conf/bin/idtune SDATLIM 33554432         ## soft data size limit
    # /etc/conf/bin/idtune HDATLIM 33554432         ## hard "
    # /etc/conf/bin/idtune SVMMSIZE unlimited       ## soft process size limit
    # /etc/conf/bin/idtune HVMMSIZE unlimited       ## hard "
    # /etc/conf/bin/idbuild -B

(He recommends you not change the stack limit, though.)
These changes take effect when you reboot.

* Redisplay using X11 is much slower than previous Emacs versions.

We've noticed that certain X servers draw the text much slower when
scroll bars are on the left.  We don't know why this happens.  If this
happens to you, you can work around it by putting the scroll bars
on the right (as they were in Emacs 19).

Here's how to do this:

  (set-scroll-bar-mode 'right)

If you're not sure whether (or how much) this problem affects you,
try that and see how much difference it makes.  To set things back
to normal, do

  (set-scroll-bar-mode 'left)

* Under X11, some characters appear as hollow boxes.

Each X11 font covers just a fraction of the characters that Emacs
supports.  To display the whole range of Emacs characters requires
many different fonts, collected into a fontset.

If some of the fonts called for in your fontset do not exist on your X
server, then the characters that have no font appear as hollow boxes.
You can remedy the problem by installing additional fonts.

The intlfonts distribution includes a full spectrum of fonts that can
display all the characters Emacs supports.

Dave Love's avatar
Dave Love committed
1557 1558 1559 1560 1561 1562
Another cause of this for specific characters is fonts which have a
missing glyph and no default character.  This is known ot occur for
character number 160 (no-break space) in some fonts, such as Lucida
but Emacs sets the display table for the unibyte and Latin-1 version
of this character to display a space.

Dave Love's avatar
Dave Love committed
1563 1564 1565 1566 1567 1568 1569 1570