[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Emacs-diffs] Changes to emacs/etc/PROBLEMS
|
From: |
Eli Zaretskii |
|
Subject: |
[Emacs-diffs] Changes to emacs/etc/PROBLEMS |
|
Date: |
Sat, 21 Aug 2004 07:36:29 -0400 |
Index: emacs/etc/PROBLEMS
diff -c emacs/etc/PROBLEMS:1.167 emacs/etc/PROBLEMS:1.168
*** emacs/etc/PROBLEMS:1.167 Tue Aug 10 21:38:02 2004
--- emacs/etc/PROBLEMS Sat Aug 21 11:31:45 2004
***************
*** 1,657 ****
This file describes various problems that have been encountered
! in compiling, installing and running GNU Emacs.
! * Environment Variables from dotfiles are ignored with Mac OS X (Carbon).
! When starting Emacs from the Dock or the Finder on Mac OS X, the
! environment variables that are set up in dotfiles, such as .cshrc or
! .profile, are ignored. This is because the Finder and Dock are not
! started from a shell, but instead from the Window Manager itself.
! The workaround for this is to create a .MacOSX/environment.plist file to
! setup these environment variables. These environment variables will
! apply to all processes regardless of where they are started.
! For me information, see http://developer.apple.com/qa/qa2001/qa1067.html.
! * Segfault on GNU/Linux using certain recent versions of the Linux kernel.
! With certain recent Linux kernels (like the one of Redhat Fedora Core
! 1), the new "Exec-shield" functionality is enabled by default, which
! creates a different memory layout that breaks the emacs dumper.
! You can check the Exec-shield state like this:
! cat /proc/sys/kernel/exec-shield
! It returns 1 or 2 when Exec-shield is enabled, 0 otherwise. Please
! read your system documentation for more details on Exec-shield and
! associated commands.
! When Exec-shield is enabled, building Emacs will segfault during the
! execution of this command:
! temacs --batch --load loadup [dump|bootstrap]
! To work around this problem, it is necessary to temporarily disable
! Exec-shield while building Emacs, using the `setarch' command like
! this:
! setarch i386 ./configure <configure parameters>
! setarch i386 make <make parameters>
! * 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.
! * 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.
! * Emacs crashes with SIGSEGV in XtInitializeWidgetClass
! It crashes on X, but runs fine when called with option "-nw".
! This has been observed when Emacs is linked with GNU ld but without passing
! the -z nocombreloc flag. Emacs normally knows to pass the -z nocombreloc
! flag when needed, so if you come across a situation where the flag is
! necessary but missing, please report it via M-x report-emacs-bug.
! On platforms such as Solaris, you can also work around this problem by
! configuring your compiler to use the native linker instead of GNU ld.
!
! * Characters from the mule-unicode charsets aren't displayed under X.
! XFree86 4 contains many fonts in iso10646-1 encoding which have
! 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:
! mule-unicode-2500-33ff:-gnu-unifont-*-iso10646-1,\
! mule-unicode-e000-ffff:-gnu-unifont-*-iso10646-1,\
! mule-unicode-0100-24ff:-gnu-unifont-*-iso10646-1
! * 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
! information.
! 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
! elsewhere.
! * 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.
! The solution is to use LessTif instead. LessTif is a free replacement
! 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.
! * 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.
! * 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.
! * 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
! 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
! variables).
! The solution is to make sure the preprocessor is run with the
! `-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 ...
! (replace the ellipsis "..." with any additional arguments you pass to
! the script).
! Note that this problem does not pertain to the MS-Windows port of
! Emacs, since it doesn't use the preprocessor to generate Makefiles.
! * Building Emacs with a system compiler fails to link because of an
! undefined symbol such as __eprintf which does not appear in Emacs.
! 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
! Since the .o object files already exist, this will not recompile Emacs
! with GCC, but just restart by trying again to link temacs.
! * 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 fails with a CreateProcess failure.
! Some versions of mingw32 make on some versions of Windows do not seem
! to detect the shell correctly. Try "make SHELL=cmd.exe", or if that
! fails, try running make from Cygwin bash instead.
! * Building the MS-Windows port with Leim fails in the `leim' directory.
! The error message might be something like this:
! Converting d:/emacs-21.3/leim/CXTERM-DIC/4Corner.tit to quail-package...
! Invalid ENCODE: value in TIT dictionary
! NMAKE : fatal error U1077: '"../src/obj-spd/i386/emacs.exe"' : return code
! '0xffffffff'
! Stop.
! 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.
! * 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
! distribution:
! #if 0 /* This breaks things on PPC GNU/Linux except for Yellowdog,
! 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
! #endif
! #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.
! * JPEG images aren't displayed.
! This has been reported when Emacs is built with jpeg-6a library.
! 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.
! * 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 */
! --- 41,47 ----
! /*
! * If not debugging, assert does nothing.
! */
! ! #define assert(x) ((void)0)
! #else /* debugging enabled */
! * Improving performance with slow X connections
! 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
! 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
! package.
! 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:
! http://www.xfree86.org/4.3.0/lbxproxy.1.html
! * 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.
! 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
! `.emacs'.
! 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
! property.
! * 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.
! * 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.
! 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.
! * 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.
! * 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.
! * 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.
! * Colors are not available on a tty or in xterm.
! 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
! Emacs. (Most color terminals support 8 or 16 colors.) If your system
! uses terminfo, the name of the capability equivalent to "Co" is
! "colors".
! 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"
! capability).
! 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.
! 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
! `xterm-color' might activate the color support on an xterm-compatible
! emulator.
! Beginning with version 21.4, Emacs supports the --color command-line
! 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.
! 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
! global-font-lock-mode RET" or by customizing the variable
! `global-font-lock-mode'.
! * 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.
! Alternatively, if you want a blinking underscore as your Emacs cursor,
! change the "cvvis" capability to send the "\E[?25h\E[?0c" command.
! * 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.
! 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.
! On some systems, even with Motif 1.2 emulation, Emacs occasionally
! locks up, grabbing all mouse and keyboard events. We still don't know
! what causes these problems; they are not reproducible by Emacs
! developers.
! * 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
! is displayed. This also means help text for pop-up menus is not
! 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.
! 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.
! 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.
! Some minor flickering still persists during mouse-tracking, although
! not as severely as in 21.1.
! 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
! of these input methods cause the keyboard to send characters encoded
! in the appropriate coding system (e.g., ISO 8859-1 for Latin-1
! 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
! yet.)
! 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.
! * The `configure' script doesn't find the jpeg library.
! 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.
! * Building Emacs over NFS fails with ``Text file busy''.
! 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.
! 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.
! 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
! `/etc/auto.home'.
! 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.
! 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'.
! * Emacs binary is not in executable format, and cannot be run.
! This was reported to happen when Emacs is built in a directory mounted
! via NFS, for some combinations of NFS client and NFS server.
! Usually, the file `emacs' produced in these cases is full of
! 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.
! * Accented ISO-8859-1 characters are displayed as | or _.
Try other font set sizes (S-mouse-1). If the problem persists with
other sizes as well, your text is corrupted, probably through software
--- 1,945 ----
This file describes various problems that have been encountered
! in compiling, installing and running GNU Emacs. Try doing Ctl t
! and browsing through the outline headers.
! * Emacs startup failures
! ** 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
! are:
! - in your ~/.Xdefaults file
! - client-side X resource file, such as ~/Emacs or
! /usr/X11R6/lib/app-defaults/Emacs or
! /usr/X11R6/lib/X11/app-defaults/Emacs
! 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.
! ** Emacs aborts while starting up, only when run without X.
! This problem often results from compiling Emacs with GCC when GCC was
! installed incorrectly. The usual error in installing GCC is to
! specify --includedir=/usr/include. Installation of GCC makes
! corrected copies of the system header files. GCC is supposed to use
! the corrected copies in preference to the original system headers.
! Specifying --includedir=/usr/include causes the original system header
! files to be used. On some systems, the definition of ioctl in the
! original system header files is invalid for ANSI C and causes Emacs
! not to work.
! The fix is to reinstall GCC, and this time do not specify --includedir
! when you configure it. Then recompile Emacs. Specifying --includedir
! is appropriate only in very special cases and it should *never* be the
! same directory where system header files are kept.
! ** Emacs does not start, complaining that it cannot open termcap database
file.
! If your system uses Terminfo rather than termcap (most modern
! systems do), this could happen if the proper version of
! ncurses is not visible to the Emacs configure script (i.e. it
! cannot be found along the usual path the linker looks for
! libraries). It can happen because your version of ncurses is
! obsolete, or is available only in form of binaries.
! The solution is to install an up-to-date version of ncurses in
! the developer's form (header files, static libraries and
! symbolic links); in some GNU/Linux distributions (e.g. Debian)
! it constitutes a separate package.
! ** 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
! it's loaded very early in the startup procedure.)
! 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
! file.
! 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
! load-path.
! ** 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"
! This can be another symptom of stale *.elc files in 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
! load-path.
! ** 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 @@
! _XimMakeImName(lcd)
! 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;
! * Crash bugs
! ** Emacs crashes in x-popup-dialog.
! This can happen if the dialog widget cannot find the font it wants to
! use. You can work around the problem by specifying another font with
! an X resource--for example, `Emacs.dialog*.font: 9x15' (or any font that
! happens to exist on your X server).
! ** Emacs crashes when you use Bibtex mode.
! This happens if your system puts a small limit on stack size. You can
! prevent the problem by using a suitable shell command (often `ulimit')
! to raise the stack size limit before you run Emacs.
! Patches to raise the stack size limit automatically in `main'
! (src/emacs.c) on various systems would be greatly appreciated.
! ** Emacs crashes with SIGBUS or SIGSEGV on HPUX 9 after you delete a frame.
! We think this is due to a bug in the X libraries provided by HP. With
! the alternative X libraries in /usr/contrib/mitX11R5/lib, the problem
! does not happen.
! ** Emacs crashes with SIGBUS or SIGSEGV on Solaris after you delete a frame.
! We suspect that this is a similar bug in the X libraries provided by
! Sun. There is a report that one of these patches fixes the bug and
! makes the problem stop:
! 105216-01 105393-01 105518-01 105621-01 105665-01 105615-02 105216-02
! 105667-01 105401-08 105615-03 105621-02 105686-02 105736-01 105755-03
! 106033-01 105379-01 105786-01 105181-04 105379-03 105786-04 105845-01
! 105284-05 105669-02 105837-01 105837-02 105558-01 106125-02 105407-01
! Another person using a newer system (kernel patch level Generic_105181-06)
! suspects that the bug was fixed by one of these more recent patches:
! 106040-07 SunOS 5.6: X Input & Output Method patch
! 106222-01 OpenWindows 3.6: filemgr (ff.core) fixes
! 105284-12 Motif 1.2.7: sparc Runtime library patch
! ** Error message `Symbol's value as variable is void: x', followed by
! a segmentation fault and core dump.
! This has been tracked to a bug in tar! People report that tar erroneously
! added a line like this at the beginning of files of Lisp code:
! x FILENAME, N bytes, B tape blocks
! If your tar has this problem, install GNU tar--if you can manage to
! untar it :-).
! ** Crashes when displaying GIF images in Emacs built with version
! libungif-4.1.0 are resolved by using version libungif-4.1.0b1.
! 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.
! ** 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.
! ** 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.
! ** Emacs crashes with SIGSEGV in XtInitializeWidgetClass.
! It crashes on X, but runs fine when called with option "-nw".
! This has been observed when Emacs is linked with GNU ld but without passing
! the -z nocombreloc flag. Emacs normally knows to pass the -z nocombreloc
! flag when needed, so if you come across a situation where the flag is
! necessary but missing, please report it via M-x report-emacs-bug.
! On platforms such as Solaris, you can also work around this problem by
! configuring your compiler to use the native linker instead of GNU ld.
! * General runtime problems
! ** Lisp problems
! *** Changes made to .el files do not take effect.
! You may have forgotten to recompile them into .elc files.
! Then the old .elc files will be loaded, and your changes
! will not be seen. To fix this, do M-x byte-recompile-directory
! and specify the directory that contains the Lisp files.
! Emacs should print a warning when loading a .elc file which is older
! than the corresponding .el file.
! *** Watch out for .emacs files and EMACSLOADPATH environment vars.
! These control the actions of Emacs.
! ~/.emacs is your Emacs init file.
! EMACSLOADPATH overrides which directories the function
! "load" will search.
! If you observe strange problems, check for these and get rid
! of them, then try again.
! *** 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.
+ *** 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.
! *** 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.
! ** Keyboard problems
! *** "Compose Character" key does strange things when used as a Meta key.
! If you define one key to serve as both Meta and Compose Character, you
! will get strange results. In previous Emacs versions, this "worked"
! in that the key acted as Meta--that's because the older Emacs versions
! did not try to support Compose Character. Now Emacs tries to do
! character composition in the standard X way. This means that you
! must pick one meaning or the other for any given key.
! You can use both functions (Meta, and Compose Character) if you assign
! them to two different keys.
! *** C-z just refreshes the screen instead of suspending Emacs.
! You are probably using a shell that doesn't support job control, even
! though the system itself is capable of it. Either use a different shell,
! or set the variable `cannot-suspend' to a non-nil value.
! *** With M-x enable-flow-control, you need to type C-\ twice
! to do incremental search--a single C-\ gets no response.
! This has been traced to communicating with your machine via kermit,
! with C-\ as the kermit escape character. One solution is to use
! another escape character in kermit. One user did
! set escape-character 17
! in his .kermrc file, to make C-q the kermit escape character.
! ** Mailers and other helper programs
! *** movemail compiled with POP support can't connect to the POP server.
! Make sure that the `pop' entry in /etc/services, or in the services
! NIS map if your machine uses NIS, has the same port number as the
! entry on the POP server. A common error is for the POP server to be
! listening on port 110, the assigned port for the POP3 protocol, while
! the client is trying to connect on port 109, the assigned port for the
! old POP protocol.
! *** RMAIL gets error getting new mail.
! RMAIL gets new mail from /usr/spool/mail/$USER using a program
! called `movemail'. This program interlocks with /bin/mail using
! the protocol defined by /bin/mail.
! There are two different protocols in general use. One of them uses
! the `flock' system call. The other involves creating a lock file;
! `movemail' must be able to write in /usr/spool/mail in order to do
! this. You control which one is used by defining, or not defining,
! the macro MAIL_USE_FLOCK in config.h or the m- or s- file it includes.
! IF YOU DON'T USE THE FORM OF INTERLOCKING THAT IS NORMAL ON YOUR
! SYSTEM, YOU CAN LOSE MAIL!
! If your system uses the lock file protocol, and fascist restrictions
! prevent ordinary users from writing the lock files in /usr/spool/mail,
! you may need to make `movemail' setgid to a suitable group such as
! `mail'. You can use these commands (as root):
! chgrp mail movemail
! chmod 2755 movemail
! If your system uses the lock file protocol, and fascist restrictions
! prevent ordinary users from writing the lock files in /usr/spool/mail,
! you may need to make `movemail' setgid to a suitable group such as
! `mail'. To do this, use the following commands (as root) after doing the
! make install.
! chgrp mail movemail
! chmod 2755 movemail
! Installation normally copies movemail from the build directory to an
! installation directory which is usually under /usr/local/lib. The
! installed copy of movemail is usually in the directory
! /usr/local/lib/emacs/VERSION/TARGET. You must change the group and
! mode of the installed copy; changing the group and mode of the build
! directory copy is ineffective.
! *** rcs2log gives you the awk error message "too many fields".
! This is due to an arbitrary limit in certain versions of awk.
! The solution is to use gawk (GNU awk).
! ** Problems with hostname resolution
! *** Emacs fails to understand most Internet host names, even though
! the names work properly with other programs on the same system.
! *** Emacs won't work with X-windows if the value of DISPLAY is HOSTNAME:0.
! *** GNUs can't make contact with the specified host for nntp.
! This typically happens on Suns and other systems that use shared
! libraries. The cause is that the site has installed a version of the
! shared library which uses a name server--but has not installed a
! similar version of the unshared library which Emacs uses.
! The result is that most programs, using the shared library, work with
! the nameserver, but Emacs does not.
! The fix is to install an unshared library that corresponds to what you
! installed in the shared library, and then relink Emacs.
! On SunOS 4.1, simply define HAVE_RES_INIT.
!
! If you have already installed the name resolver in the file libresolv.a,
! then you need to compile Emacs to use that library. The easiest way to
! do this is to add to config.h a definition of LIBS_SYSTEM, LIBS_MACHINE
! or LIB_STANDARD which uses -lresolv. Watch out! If you redefine a macro
! that is already in use in your configuration to supply some other libraries,
! be careful not to lose the others.
! Thus, you could start by adding this to config.h:
! #define LIBS_SYSTEM -lresolv
! Then if this gives you an error for redefining a macro, and you see that
! the s- file defines LIBS_SYSTEM as -lfoo -lbar, you could change config.h
! again to say this:
! #define LIBS_SYSTEM -lresolv -lfoo -lbar
! *** 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.
!
! ** NFS and RFS
!
! *** Emacs says it has saved a file, but the file does not actually
! appear on disk.
!
! This can happen on certain systems when you are using NFS, if the
! remote disk is full. It is due to a bug in NFS (or certain NFS
! implementations), and there is apparently nothing Emacs can do to
! detect the problem. Emacs checks the failure codes of all the system
! calls involved in writing a file, including `close'; but in the case
! where the problem occurs, none of those system calls fails.
!
! *** Editing files through RFS gives spurious "file has changed" warnings.
! It is possible that a change in Emacs 18.37 gets around this problem,
! but in case not, here is a description of how to fix the RFS bug that
! causes it.
!
! There was a serious pair of bugs in the handling of the fsync() system
! call in the RFS server.
!
! The first is that the fsync() call is handled as another name for the
! close() system call (!!). It appears that fsync() is not used by very
! many programs; Emacs version 18 does an fsync() before closing files
! to make sure that the bits are on the disk.
!
! This is fixed by the enclosed patch to the RFS server.
!
! The second, more serious problem, is that fsync() is treated as a
! non-blocking system call (i.e., it's implemented as a message that
! gets sent to the remote system without waiting for a reply). Fsync is
! a useful tool for building atomic file transactions. Implementing it
! as a non-blocking RPC call (when the local call blocks until the sync
! is done) is a bad idea; unfortunately, changing it will break the RFS
! protocol. No fix was supplied for this problem.
!
! (as always, your line numbers may vary)
!
! % rcsdiff -c -r1.2 serversyscall.c
! RCS file: RCS/serversyscall.c,v
! retrieving revision 1.2
! diff -c -r1.2 serversyscall.c
! *** /tmp/,RCSt1003677 Wed Jan 28 15:15:02 1987
! --- serversyscall.c Wed Jan 28 15:14:48 1987
! ***************
! *** 163,169 ****
! /*
! * No return sent for close or fsync!
! */
! ! if (syscall == RSYS_close || syscall == RSYS_fsync)
! proc->p_returnval = deallocate_fd(proc, msg->m_args[0]);
! else
! {
! --- 166,172 ----
! /*
! * No return sent for close or fsync!
! */
! ! if (syscall == RSYS_close)
! proc->p_returnval = deallocate_fd(proc, msg->m_args[0]);
! else
! {
!
! ** PSGML
!
! *** Old versions of the PSGML package use the obsolete variables
! `before-change-function' and `after-change-function', which are no
! longer used by Emacs. Please use PSGML 1.2.3 or later.
!
! *** 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.
!
! *** 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))
! (cond
! ((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))
!
! ** AUC TeX
!
! *** 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.
!
! *** 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
! 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
! package.
!
! 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")
!
! ** Miscellaneous problems
!
! *** Self-documentation messages are garbled.
!
! This means that the file `etc/DOC-...' doesn't properly correspond
! with the Emacs executable. Redumping Emacs and then installing the
! corresponding pair of files should fix the problem.
!
! *** Programs running under terminal emulator do not recognize `emacs'
! terminal type.
!
! The cause of this is a shell startup file that sets the TERMCAP
! environment variable. The terminal emulator uses that variable to
! provide the information on the special terminal type that Emacs
! emulates.
!
! Rewrite your shell startup file so that it does not change TERMCAP
! in such a case. You could use the following conditional which sets
! it only if it is undefined.
!
! if ( ! ${?TERMCAP} ) setenv TERMCAP ~/my-termcap-file
!
! Or you could set TERMCAP only when you set TERM--which should not
! happen in a non-login shell.
!
! *** In Shell mode, you get a ^M at the end of every line.
!
! This happens to people who use tcsh, because it is trying to be too
! smart. It sees that the Shell uses terminal type `unknown' and turns
! 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 == "t") then
! unset edit
! stty -icrnl -onlcr -echo susp ^Z
! endif
! endif
!
! *** 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:
!
! 127.0.0.1 localhost
! 129.187.137.82 nuc04.t30.physik.tu-muenchen.de nuc04
!
! The way to set this up may vary on non-GNU systems.
!
! *** 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
! 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
!
! and then choose /usr/bin/netkit-ftp.
!
! *** JPEG images aren't displayed.
!
! This has been reported when Emacs is built with jpeg-6a library.
! 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.
!
! *** 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.
!
! *** Versions of the W3 package released before Emacs 21.1 don't run
! under Emacs 21. This fixed in W3 version 4.0pre.47.
!
! *** 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'.
!
! *** 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.
!
! *** 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.
!
! Similar problems could prevent Emacs from building, since the build
! process invokes Emacs several times.
!
! 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.
!
! 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 yet 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.
!
! *** You request inverse video, and the first Emacs frame is in inverse
! video, but later frames are not in inverse video.
!
! This can happen if you have an old version of the custom library in
! your search path for Lisp packages. Use M-x list-load-path-shadows to
! check whether this is true. If it is, delete the old custom library.
!
! *** When you run Ispell from Emacs, it reports a "misalignment" error.
!
! 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.
!
! 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.
!
! 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.
!
! * Runtime problems related to font handling
!
! ** 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.
! Another cause of this for specific characters is fonts which have a
! missing glyph and no default character. This is known to 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.
! ** Under X11, some characters appear improperly aligned in their lines.
! You may have bad X11 fonts; try installing the intlfonts distribution.
! ** Certain fonts make each line take one pixel more than it "should".
! This is because these fonts contain characters a little taller
! than the font's nominal height. Emacs needs to make sure that
! lines do not overlap.
! ** Loading fonts is very slow.
! You might be getting scalable fonts instead of precomputed bitmaps.
! Known scalable font directories are "Type1" and "Speedo". A font
! directory contains scalable fonts if it contains the file
! "fonts.scale".
! If this is so, re-order your X windows font path to put the scalable
! font directories last. See the documentation of `xset' for details.
! With some X servers, it may be necessary to take the scalable font
! directories out of your path entirely, at least for Emacs 19.26.
! Changes in the future may make this unnecessary.
! ** Font Lock displays portions of the buffer in incorrect faces.
! 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
! 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
! 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.
! 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.
! ** With certain fonts, when the cursor appears on a character, the
! character doesn't appear--you get a solid box instead.
! One user on a Linux-based GNU system reported that this problem went
! away with installation of a new X server. The failing server was
! XFree86 3.1.1. XFree86 3.1.2 works.
! ** 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.
! ** 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.
! 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
! `.emacs'.
! 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
! property.
! ** 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
! correct but there is too much vertical spacing between rows, which
! gives the appearance of "double spacing".
! To prevent this, turn off the Exceed's "automatic font substitution"
! feature (in the font part of the configuration window).
! * Internationalization problems
! ** Characters from the mule-unicode charsets aren't displayed under X.
! XFree86 4 contains many fonts in iso10646-1 encoding which have
! 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:
! mule-unicode-2500-33ff:-gnu-unifont-*-iso10646-1,\
! mule-unicode-e000-ffff:-gnu-unifont-*-iso10646-1,\
! mule-unicode-0100-24ff:-gnu-unifont-*-iso10646-1
! ** 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
! information.
! 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
! elsewhere.
! ** 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.
! ** Accented ISO-8859-1 characters are displayed as | or _.
Try other font set sizes (S-mouse-1). If the problem persists with
other sizes as well, your text is corrupted, probably through software
***************
*** 671,2576 ****
`fonts.alias' file, then run `mkfontdir' in that directory, and then run
`xset fp rehash'.
! * Large file support is disabled on HP-UX. See the comments in
! src/s/hpux10.h.
!
! * Crashes when displaying GIF images in Emacs built with version
! libungif-4.1.0 are resolved by using version libungif-4.1.0b1.
! 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.
!
! * Font Lock displays portions of the buffer in incorrect faces.
!
! 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
! 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
! 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.
!
! 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.
!
! * 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
! empty portions of the Emacs display, while characters have some other
! background.
!
! 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"
! option in Preferences->Look&Feel->Style (KDE 2). In KDE 3, this option
! is in the "Colors" section, rather than "Style".
!
! Alternatively, if you do want the KDE defaults to apply to other
! applications, but not to Emacs, you could modify the file `Emacs.ad'
! (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:
!
! Emacs.default.attributeForeground
! Emacs.default.attributeBackground
! Emacs*Foreground
! Emacs*Background
!
! * 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.)
! * 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.
! * 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
! 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:
! (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" "")
! * Versions of the W3 package released before Emacs 21.1 don't run
! under Emacs 21. This fixed in W3 version 4.0pre.47.
! * 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.
! This could happen if you use /bin/c89 as your compiler, instead of
! 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
! `before-change-function' and `after-change-function', which are no
! longer used by Emacs. Please use PSGML 1.2.3 or later.
! * 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.
! * 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'.
! * The `oc-unicode' package doesn't work with Emacs 21.
! This package tries to define more private charsets than there are free
! 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.
! * 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.
! * 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.
! * 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
! has):
! (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
! * 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.
! Similar problems could prevent Emacs from building, since the build
! process invokes Emacs several times.
! 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.
! 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 yet 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.
! * On Solaris 2.7, building Emacs with WorkShop Compilers 5.0 98/12/15
! 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.
! * Compiling syntax.c with the OPENSTEP 4.2 compiler gcc 2.7.2.1 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)
! {
! return(UPDATE_SYNTAX_TABLE_FORWARD(from));
! }/*update_syntax_table_forward*/
! Then replace all references to UPDATE_SYNTAX_TABLE_FORWARD in syntax.c
! with a call to the function update_syntax_table_forward.
! * 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
! are:
! - in your ~/.Xdefaults file
! - client-side X resource file, such as ~/Emacs or
! /usr/X11R6/lib/app-defaults/Emacs or
! /usr/X11R6/lib/X11/app-defaults/Emacs
! 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.
! * 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
! it's loaded very early in the startup procedure.)
! 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
! file.
! 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
! load-path.
! * 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"
! This can be another symptom of stale *.elc files in 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
! load-path.
! * 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
! 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
! and then choose /usr/bin/netkit-ftp.
! * 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.
! 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
! http://www.gnu.org/software/emacs/windows/.
! * 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
! particular, this has been reported when trying to compile a Java
! program in JDEE when javac.exe is installed, but not on the system
! PATH.
! * 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.
! * 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
! seen.
! * 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
! modifier:
! 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/k.ps
! This produces a PostScript file `/tmp/k.ps' 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.
! * 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
! keyboard(5).
! 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'
! * 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.
! * 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
! manager.
! This bug was reported to Sun as
! Gtk apps dump core in ximlocal.so.2:IMCheckIMWindow()
! Bug Reports: 4463537
! Installing Solaris 8 patch 108773-12 for Sparc and 108774-12 for x86
! reportedly fixes the bug, which appears to be inside the shared
! library xiiimp.so.
! 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.)
! * 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
! 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.
! 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 @@
! _XimMakeImName(lcd)
! 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.
! 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.
! * 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
! purposes.
! 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.
! * 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:
! /usr/openwin/lib/locale/iso8859-15/Compose
! 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
! correct but there is too much vertical spacing between rows, which
! gives the appearance of "double spacing".
! To prevent this, turn off the Exceed's "automatic font substitution"
! 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))
! (cond
! ((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))
! * 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.
! * 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
! 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
! package.
! 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
! (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
! EOF
! xmodmap - << EOF
! clear mod1
! keysym Mode_switch = NoSymbol
! add mod1 = Meta_L
! keysym Meta_R = Mode_switch
! add mod2 = Mode_switch
! EOF
! --------------------------------
! * Emacs hangs on KDE when a large portion of text is killed.
! 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:
! Timed out waiting for property-notify event
! A workaround is to not use `klipper'.
! * 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:
! 127.0.0.1 localhost
! 129.187.137.82 nuc04.t30.physik.tu-muenchen.de 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.
! 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.
! 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.
! 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.
! * 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
! 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
! AltGr has been pressed. The variable `w32-recognize-altgr' can be set
! to nil to tell Emacs that AltGr is really Ctrl and Alt.
! * 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
! 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.
! This is known to occur under Exceed 6, and possibly earlier versions
! as well; it is reportedly solved in version 6.2.0.16 and later. The
! problem lies in the X-server settings.
! 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
! selection".
! Of this does not work, please inform address@hidden Then
! please call support for your X-server and see if you can get a fix.
! If you do, please send it to address@hidden so we can list it
! here.
! * 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 ftp://sunsolve.sun.com/pub/patches/;
! 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.
! * 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.
! 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.
! address@hidden says (Feb 1998) that the Compose key does work
! if you link with the MIT X11 libraries instead of the Solaris X11
! libraries.
! * 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".
! * 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 (address@hidden) 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.
! 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.
! * Under X11, some characters appear improperly aligned in their lines.
! You may have bad X11 fonts; try installing the intlfonts distribution.
! * Certain fonts make each line take one pixel more than it "should".
! This is because these fonts contain characters a little taller
! than the font's nominal height. Emacs needs to make sure that
! lines do not overlap.
! * You request inverse video, and the first Emacs frame is in inverse
! video, but later frames are not in inverse video.
! This can happen if you have an old version of the custom library in
! your search path for Lisp packages. Use M-x list-load-path-shadows to
! check whether this is true. If it is, delete the old custom library.
! * In FreeBSD 2.1.5, useless symbolic links remain in /tmp or other
! directories that have the +t bit.
! This is because of a kernel bug in FreeBSD 2.1.5 (fixed in 2.2).
! Emacs uses symbolic links to implement file locks. In a directory
! with +t bit, the directory owner becomes the owner of the symbolic
! link, so that it cannot be removed by anyone else.
! If you don't like those useless links, you can let Emacs not to using
! file lock by adding #undef CLASH_DETECTION to config.h.
! * When using M-x dbx with the SparcWorks debugger, the `up' and `down'
! commands do not move the arrow in Emacs.
! You can fix this by adding the following line to `~/.dbxinit':
! dbxenv output_short_file_name off
! * Emacs says it has saved a file, but the file does not actually
! appear on disk.
! This can happen on certain systems when you are using NFS, if the
! remote disk is full. It is due to a bug in NFS (or certain NFS
! implementations), and there is apparently nothing Emacs can do to
! detect the problem. Emacs checks the failure codes of all the system
! calls involved in writing a file, including `close'; but in the case
! where the problem occurs, none of those system calls fails.
! * "Compose Character" key does strange things when used as a Meta key.
! If you define one key to serve as both Meta and Compose Character, you
! will get strange results. In previous Emacs versions, this "worked"
! in that the key acted as Meta--that's because the older Emacs versions
! did not try to support Compose Character. Now Emacs tries to do
! character composition in the standard X way. This means that you
! must pick one meaning or the other for any given key.
! You can use both functions (Meta, and Compose Character) if you assign
! them to two different keys.
! * Emacs gets a segmentation fault at startup, on AIX4.2.
! If you are using IBM's xlc compiler, compile emacs.c
! without optimization; that should avoid the problem.
! * movemail compiled with POP support can't connect to the POP server.
! Make sure that the `pop' entry in /etc/services, or in the services
! NIS map if your machine uses NIS, has the same port number as the
! entry on the POP server. A common error is for the POP server to be
! listening on port 110, the assigned port for the POP3 protocol, while
! the client is trying to connect on port 109, the assigned port for the
! old POP protocol.
! * Emacs crashes in x-popup-dialog.
! This can happen if the dialog widget cannot find the font it wants to
! use. You can work around the problem by specifying another font with
! an X resource--for example, `Emacs.dialog*.font: 9x15' (or any font that
! happens to exist on your X server).
! * Emacs crashes when you use Bibtex mode.
! This happens if your system puts a small limit on stack size. You can
! prevent the problem by using a suitable shell command (often `ulimit')
! to raise the stack size limit before you run Emacs.
! Patches to raise the stack size limit automatically in `main'
! (src/emacs.c) on various systems would be greatly appreciated.
! * Emacs crashes with SIGBUS or SIGSEGV on HPUX 9 after you delete a frame.
! We think this is due to a bug in the X libraries provided by HP. With
! the alternative X libraries in /usr/contrib/mitX11R5/lib, the problem
! does not happen.
! * Emacs crashes with SIGBUS or SIGSEGV on Solaris after you delete a frame.
! We suspect that this is a similar bug in the X libraries provided by
! Sun. There is a report that one of these patches fixes the bug and
! makes the problem stop:
! 105216-01 105393-01 105518-01 105621-01 105665-01 105615-02 105216-02
! 105667-01 105401-08 105615-03 105621-02 105686-02 105736-01 105755-03
! 106033-01 105379-01 105786-01 105181-04 105379-03 105786-04 105845-01
! 105284-05 105669-02 105837-01 105837-02 105558-01 106125-02 105407-01
! Another person using a newer system (kernel patch level Generic_105181-06)
! suspects that the bug was fixed by one of these more recent patches:
! 106040-07 SunOS 5.6: X Input & Output Method patch
! 106222-01 OpenWindows 3.6: filemgr (ff.core) fixes
! 105284-12 Motif 1.2.7: sparc Runtime library patch
! * Problems running Perl under Emacs on MS-Windows NT/95.
! `perl -de 0' just hangs when executed in an Emacs subshell.
! The fault lies with Perl (indirectly with Windows NT/95).
! The problem is that the Perl debugger explicitly opens a connection to
! "CON", which is the DOS/NT equivalent of "/dev/tty", for interacting
! with the user.
! On Unix, this is okay, because Emacs (or the shell?) creates a
! pseudo-tty so that /dev/tty is really the pipe Emacs is using to
! communicate with the subprocess.
! On NT, this fails because CON always refers to the handle for the
! relevant console (approximately equivalent to a tty), and cannot be
! redirected to refer to the pipe Emacs assigned to the subprocess as
! stdin.
! A workaround is to modify perldb.pl to use STDIN/STDOUT instead of CON.
! For Perl 4:
! *** PERL/LIB/PERLDB.PL.orig Wed May 26 08:24:18 1993
! --- PERL/LIB/PERLDB.PL Mon Jul 01 15:28:16 1996
! ***************
! *** 68,74 ****
! $rcfile=".perldb";
! }
! else {
! ! $console = "con";
! $rcfile="perldb.ini";
! }
! --- 68,74 ----
! $rcfile=".perldb";
! }
! else {
! ! $console = "";
! $rcfile="perldb.ini";
! }
! For Perl 5:
! *** perl/5.001/lib/perl5db.pl.orig Sun Jun 04 21:13:40 1995
! --- perl/5.001/lib/perl5db.pl Mon Jul 01 17:00:08 1996
! ***************
! *** 22,28 ****
! $rcfile=".perldb";
! }
! elsif (-e "con") {
! ! $console = "con";
! $rcfile="perldb.ini";
! }
! else {
! --- 22,28 ----
! $rcfile=".perldb";
! }
! elsif (-e "con") {
! ! $console = "";
! $rcfile="perldb.ini";
! }
! else {
! * Problems on MS-DOG if DJGPP v2.0 is used to compile Emacs:
! There are two DJGPP library bugs which cause problems:
! * Running `shell-command' (or `compile', or `grep') you get
! `Searching for program: permission denied (EACCES), c:/command.com';
! * After you shell to DOS, Ctrl-Break kills Emacs.
! To work around these bugs, you can use two files in the msdos
! subdirectory: `is_exec.c' and `sigaction.c'. Compile them and link
! them into the Emacs executable `temacs'; then they will replace the
! incorrect library functions.
! * When compiling with DJGPP on MS-Windows NT, "config msdos" fails.
! If the error message is "VDM has been already loaded", this is because
! Windows has a program called `redir.exe' that is incompatible with a
! program by the same name supplied with DJGPP, which is used by
! config.bat. To resolve this, move the DJGPP's `bin' subdirectory to
! the front of your PATH environment variable.
! * When compiling with DJGPP on MS-Windows 95, Make fails for some targets
! like make-docfile.
! This can happen if long file name support (the setting of environment
! variable LFN) when Emacs distribution was unpacked and during
! compilation are not the same. See the MSDOG section of INSTALL for
! the explanation of how to avoid this problem.
! * Emacs compiled for MSDOS cannot find some Lisp files, or other
! run-time support files, when long filename support is enabled.
! Usually, this problem will manifest itself when Emacs exits
! immediately after flashing the startup screen, because it cannot find
! the Lisp files it needs to load at startup. Redirect Emacs stdout
! and stderr to a file to see the error message printed by Emacs.
! Another manifestation of this problem is that Emacs is unable to load
! the support for editing program sources in languages such as C and
! Lisp.
! This can happen if the Emacs distribution was unzipped without LFN
! support, thus causing long filenames to be truncated to the first 6
! characters and a numeric tail that Windows 95 normally attaches to it.
! You should unzip the files again with a utility that supports long
! filenames (such as djtar from DJGPP or InfoZip's UnZip program
! compiled with DJGPP v2). The MSDOG section of the file INSTALL
! explains this issue in more detail.
! Another possible reason for such failures is that Emacs compiled for
! MSDOS is used on Windows NT, where long file names are not supported
! by this version of Emacs, but the distribution was unpacked by an
! unzip program that preserved the long file names instead of truncating
! them to DOS 8+3 limits. To be useful on NT, the MSDOS port of Emacs
! must be unzipped by a DOS utility, so that long file names are
! properly truncated.
! * Emacs compiled with DJGPP complains at startup:
! "Wrong type of argument: internal-facep, msdos-menu-active-face"
! This can happen if you define an environment variable `TERM'. Emacs
! on MSDOS uses an internal terminal emulator which is disabled if the
! value of `TERM' is anything but the string "internal". Emacs then
! works as if its terminal were a dumb glass teletype that doesn't
! support faces. To work around this, arrange for `TERM' to be
! undefined when Emacs runs. The best way to do that is to add an
! [emacs] section to the DJGPP.ENV file which defines an empty value for
! `TERM'; this way, only Emacs gets the empty value, while the rest of
! your system works as before.
! * On MS-Windows 95, Alt-f6 does not get through to Emacs.
! This character seems to be trapped by the kernel in Windows 95.
! You can enter M-f6 by typing ESC f6.
! * Typing Alt-Shift has strange effects on MS-Windows.
! This combination of keys is a command to change keyboard layout. If
! you proceed to type another non-modifier key before you let go of Alt
! and Shift, the Alt and Shift act as modifiers in the usual way. A
! more permanent work around is to change it to another key combination,
! or disable it in the keyboard control panel.
! * `tparam' reported as a multiply-defined symbol when linking with ncurses.
! This problem results from an incompatible change in ncurses, in
! version 1.9.9e approximately. This version is unable to provide a
! definition of tparm without also defining tparam. This is also
! incompatible with Terminfo; as a result, the Emacs Terminfo support
! does not work with this version of ncurses.
! The fix is to install a newer version of ncurses, such as version 4.2.
! * Emacs does not start, complaining that it cannot open termcap database file.
! If your system uses Terminfo rather than termcap (most modern
! systems do), this could happen if the proper version of
! ncurses is not visible to the Emacs configure script (i.e. it
! cannot be found along the usual path the linker looks for
! libraries). It can happen because your version of ncurses is
! obsolete, or is available only in form of binaries.
! The solution is to install an up-to-date version of ncurses in
! the developer's form (header files, static libraries and
! symbolic links); in some GNU/Linux distributions (e.g. Debian)
! it constitutes a separate package.
! * Strange results from format %d in a few cases, on a Sun.
! Sun compiler version SC3.0 has been found to miscompile part of
! editfns.c. The workaround is to compile with some other compiler such
! as GCC.
! * Output from subprocess (such as man or diff) is randomly truncated
! on GNU/Linux systems.
! This is due to a kernel bug which seems to be fixed in Linux version
! 1.3.75.
! * Error messages `internal facep []' happen on GNU/Linux systems.
! There is a report that replacing libc.so.5.0.9 with libc.so.5.2.16
! caused this to start happening. People are not sure why, but the
! problem seems unlikely to be in Emacs itself. Some suspect that it
! is actually Xlib which won't work with libc.so.5.2.16.
! Using the old library version is a workaround.
! * On Solaris, Emacs crashes if you use (display-time).
! This can happen if you configure Emacs without specifying the precise
! version of Solaris that you are using.
! * Emacs dumps core on startup, on Solaris.
! Bill Sebok says that the cause of this is Solaris 2.4 vendor patch
! 102303-05, which extends the Solaris linker to deal with the Solaris
! Common Desktop Environment's linking needs. You can fix the problem
! by removing this patch and installing patch 102049-02 instead.
! However, that linker version won't work with CDE.
! Solaris 2.5 comes with a linker that has this bug. It is reported that if
! you install all the latest patches (as of June 1996), the bug is fixed.
! We suspect the crucial patch is one of these, but we don't know
! for certain.
! 103093-03: [README] SunOS 5.5: kernel patch (2140557 bytes)
! 102832-01: [README] OpenWindows 3.5: Xview Jumbo Patch (4181613 bytes)
! 103242-04: [README] SunOS 5.5: linker patch (595363 bytes)
! (One user reports that the bug was fixed by those patches together
! with patches 102980-04, 103279-01, 103300-02, and 103468-01.)
! If you can determine which patch does fix the bug, please tell
! address@hidden
! Meanwhile, the GNU linker links Emacs properly on both Solaris 2.4 and
! Solaris 2.5.
! * Emacs dumps core if lisp-complete-symbol is called, on Solaris.
! If you compile Emacs with the -fast or -xO4 option with version 3.0.2
! of the Sun C compiler, Emacs dumps core when lisp-complete-symbol is
! called. The problem does not happen if you compile with GCC.
! * "Cannot find callback list" messages from dialog boxes on HPUX, in
! Emacs built with Motif.
! This problem resulted from a bug in GCC 2.4.5. Newer GCC versions
! such as 2.7.0 fix the problem.
! * On Irix 6.0, make tries (and fails) to build a program named unexelfsgi
! A compiler bug inserts spaces into the string "unexelfsgi . o"
! in src/Makefile. Edit src/Makefile, after configure is run,
! find that string, and take out the spaces.
! Compiler fixes in Irix 6.0.1 should eliminate this problem.
! * "out of virtual swap space" on Irix 5.3
! This message occurs when the system runs out of swap space due to too
! many large programs running. The solution is either to provide more
! swap space or to reduce the number of large programs being run. You
! can check the current status of the swap space by executing the
! command `swap -l'.
! You can increase swap space by changing the file /etc/fstab. Adding a
! line like this:
! /usr/swap/swap.more swap swap pri=3 0 0
! where /usr/swap/swap.more is a file previously created (for instance
! by using /etc/mkfile), will increase the swap space by the size of
! that file. Execute `swap -m' or reboot the machine to activate the
! new swap area. See the manpages for `swap' and `fstab' for further
! information.
! The objectserver daemon can use up lots of memory because it can be
! swamped with NIS information. It collects information about all users
! on the network that can log on to the host.
! If you want to disable the objectserver completely, you can execute
! the command `chkconfig objectserver off' and reboot. That may disable
! some of the window system functionality, such as responding CDROM
! icons.
! You can also remove NIS support from the objectserver. The SGI `admin'
! FAQ has a detailed description on how to do that; see question 35
! ("Why isn't the objectserver working?"). The admin FAQ can be found at
! ftp://viz.tamu.edu/pub/sgi/faq/.
! * With certain fonts, when the cursor appears on a character, the
! character doesn't appear--you get a solid box instead.
! One user on a Linux-based GNU system reported that this problem went
! away with installation of a new X server. The failing server was
! XFree86 3.1.1. XFree86 3.1.2 works.
! * On SunOS 4.1.3, Emacs unpredictably crashes in _yp_dobind_soft.
! This happens if you configure Emacs specifying just `sparc-sun-sunos4'
! on a system that is version 4.1.3. You must specify the precise
! version number (or let configure figure out the configuration, which
! it can do perfectly well for SunOS).
- * On SunOS 4, Emacs processes keep going after you kill the X server
- (or log out, if you logged in using X).
! Someone reported that recompiling with GCC 2.7.0 fixed this problem.
! * On AIX 4, some programs fail when run in a Shell buffer
! with an error message like No terminfo entry for "unknown".
! On AIX, many terminal type definitions are not installed by default.
! `unknown' is one of them. Install the "Special Generic Terminal
! Definitions" to make them defined.
! * On SunOS, you get linker errors
! ld: Undefined symbol
! _get_wmShellWidgetClass
! _get_applicationShellWidgetClass
! The fix to this is to install patch 100573 for OpenWindows 3.0
! or link libXmu statically.
! * On AIX 4.1.2, linker error messages such as
! ld: 0711-212 SEVERE ERROR: Symbol .__quous, found in the global symbol table
! of archive /usr/lib/libIM.a, was not defined in archive member shr.o.
! This is a problem in libIM.a. You can work around it by executing
! these shell commands in the src subdirectory of the directory where
! you build Emacs:
! cp /usr/lib/libIM.a .
! chmod 664 libIM.a
! ranlib libIM.a
! Then change -lIM to ./libIM.a in the command to link temacs (in
! Makefile).
! * Unpredictable segmentation faults on Solaris 2.3 and 2.4.
! A user reported that this happened in 19.29 when it was compiled with
! the Sun compiler, but not when he recompiled with GCC 2.7.0.
! We do not know whether something in Emacs is partly to blame for this.
! * Emacs exits with "X protocol error" when run with an X server for
! MS-Windows.
! A certain X server for Windows had a bug which caused this.
! Supposedly the newer 32-bit version of this server doesn't have the
! problem.
! * Emacs crashes at startup on MSDOS.
! Some users report that Emacs 19.29 requires dpmi memory management,
! and crashes on startup if the system does not have it. We don't yet
! know why this happens--perhaps these machines don't have enough real
! memory, or perhaps something is wrong in Emacs or the compiler.
! However, arranging to use dpmi support is a workaround.
! You can find out if you have a dpmi host by running go32 without
! arguments; it will tell you if it uses dpmi memory. For more
! information about dpmi memory, consult the djgpp FAQ. (djgpp
! is the GNU C compiler as packaged for MSDOS.)
! Compiling Emacs under MSDOS is extremely sensitive for proper memory
! configuration. If you experience problems during compilation, consider
! removing some or all memory resident programs (notably disk caches)
! and make sure that your memory managers are properly configured. See
! the djgpp faq for configuration hints.
! * A position you specified in .Xdefaults is ignored, using twm.
! twm normally ignores "program-specified" positions.
! You can tell it to obey them with this command in your `.twmrc' file:
! UsePPosition "on" #allow clients to request a position
! * Compiling lib-src says there is no rule to make test-distrib.c.
! This results from a bug in a VERY old version of GNU Sed. To solve
! the problem, install the current version of GNU Sed, then rerun
! Emacs's configure script.
! * Compiling wakeup, in lib-src, says it can't make wakeup.c.
! This results from a bug in GNU Sed version 2.03. To solve the
! problem, install the current version of GNU Sed, then rerun Emacs's
! configure script.
! * On Sunos 4.1.1, there are errors compiling sysdep.c.
! If you get errors such as
! "sysdep.c", line 2017: undefined structure or union
! "sysdep.c", line 2017: undefined structure or union
! "sysdep.c", line 2019: nodename undefined
! This can result from defining LD_LIBRARY_PATH. It is very tricky
! to use that environment variable with Emacs. The Emacs configure
! script links many test programs with the system libraries; you must
! make sure that the libraries available to configure are the same
! ones available when you build Emacs.
! * The right Alt key works wrong on German HP keyboards (and perhaps
! other non-English HP keyboards too).
! This is because HPUX defines the modifiers wrong in X. Here is a
! shell script to fix the problem; be sure that it is run after VUE
! configures the X server.
! xmodmap 2> /dev/null - << EOF
! keysym Alt_L = Meta_L
! keysym Alt_R = Meta_R
! EOF
! xmodmap - << EOF
! clear mod1
! keysym Mode_switch = NoSymbol
! add mod1 = Meta_L
! keysym Meta_R = Mode_switch
! add mod2 = Mode_switch
! EOF
! * The Emacs window disappears when you type M-q.
! Some versions of the Open Look window manager interpret M-q as a quit
! command for whatever window you are typing at. If you want to use
! Emacs with that window manager, you should try to configure the window
! manager to use some other command. You can disable the
! shortcut keys entirely by adding this line to ~/.OWdefaults:
! OpenWindows.WindowMenuAccelerators: False
! * Emacs does not notice when you release the mouse.
! There are reports that this happened with (some) Microsoft mice and
! that replacing the mouse made it stop.
! * Trouble using ptys on IRIX, 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.
! * On Irix 5.2, unexelfsgi.c can't find cmplrs/stsupport.h.
! The file cmplrs/stsupport.h was included in the wrong file set in the
! Irix 5.2 distribution. You can find it in the optional fileset
! compiler_dev, or copy it from some other Irix 5.2 system. A kludgy
! workaround is to change unexelfsgi.c to include sym.h instead of
! syms.h.
! * Slow startup on Linux-based GNU systems.
! People using systems based on the Linux kernel sometimes report that
! startup takes 10 to 15 seconds longer than `usual'.
! This is because Emacs looks up the host name when it starts.
! Normally, this takes negligible time; the extra delay is due to
! improper system configuration. This problem can occur for both
! networked and non-networked machines.
! Here is how to fix the configuration. It requires being root.
! ** Networked Case
! First, make sure the files `/etc/hosts' and `/etc/host.conf' both
! exist. The first line in the `/etc/hosts' file should look like this
! (replace HOSTNAME with your host name):
! 127.0.0.1 HOSTNAME
! Also make sure that the `/etc/host.conf' files contains the following
! lines:
! order hosts, bind
! multi on
! Any changes, permanent and temporary, to the host name should be
! indicated in the `/etc/hosts' file, since it acts a limited local
! database of addresses and names (e.g., some SLIP connections
! dynamically allocate ip addresses).
! ** Non-Networked Case
! The solution described in the networked case applies here as well.
! However, if you never intend to network your machine, you can use a
! simpler solution: create an empty `/etc/host.conf' file. The command
! `touch /etc/host.conf' suffices to create the file. The `/etc/hosts'
! file is not necessary with this approach.
! * On Solaris 2.4, Dired hangs and C-g does not work. Or Emacs hangs
! forever waiting for termination of a subprocess that is a zombie.
! address@hidden says the problem is in X11R6. Rebuild libX11.so
! after changing the file xc/config/cf/sunLib.tmpl. Change the lines
! #if ThreadedX
! #define SharedX11Reqs -lthread
! #endif
! to:
! #if OSMinorVersion < 4
! #if ThreadedX
! #define SharedX11Reqs -lthread
! #endif
! #endif
! Be sure also to edit x/config/cf/sun.cf so that OSMinorVersion is 4
! (as it should be for Solaris 2.4). The file has three definitions for
! OSMinorVersion: the first is for x86, the second for SPARC under
! Solaris, and the third for SunOS 4. Make sure to update the
! definition for your type of machine and system.
! Then do `make Everything' in the top directory of X11R6, to rebuild
! the makefiles and rebuild X. The X built this way work only on
! Solaris 2.4, not on 2.3.
! For multithreaded X to work it is necessary to install patch
! 101925-02 to fix problems in header files [2.4]. You need
! to reinstall gcc or re-run just-fixinc after installing that
! patch.
! However, Frank Rust <address@hidden> used a simpler solution:
! he changed
! #define ThreadedX YES
! to
! #define ThreadedX NO
! in sun.cf and did `make World' to rebuild X11R6. Removing all
! `-DXTHREAD*' flags and `-lthread' entries from lib/X11/Makefile and
! typing 'make install' in that directory also seemed to work.
! * With M-x enable-flow-control, you need to type C-\ twice
! to do incremental search--a single C-\ gets no response.
! This has been traced to communicating with your machine via kermit,
! with C-\ as the kermit escape character. One solution is to use
! another escape character in kermit. One user did
! set escape-character 17
! in his .kermrc file, to make C-q the kermit escape character.
! * The Motif version of Emacs paints the screen a solid color.
! This has been observed to result from the following X resource:
! Emacs*default.attributeFont:
-*-courier-medium-r-*-*-*-140-*-*-*-*-iso8859-*
! That the resource has this effect indicates a bug in something, but we
! do not yet know what. If it is an Emacs bug, we hope someone can
! explain what the bug is so we can fix it. In the mean time, removing
! the resource prevents the problem.
! * Emacs gets hung shortly after startup, on Sunos 4.1.3.
! We think this is due to a bug in Sunos. The word is that
! one of these Sunos patches fixes the bug:
! 100075-11 100224-06 100347-03 100482-05 100557-02 100623-03 100804-03
101080-01
! 100103-12 100249-09 100496-02 100564-07 100630-02 100891-10
101134-01
! 100170-09 100296-04 100377-09 100507-04 100567-04 100650-02 101070-01
101145-01
! 100173-10 100305-15 100383-06 100513-04 100570-05 100689-01 101071-03
101200-02
! 100178-09 100338-05 100421-03 100536-02 100584-05 100784-01 101072-01
101207-01
! We don't know which of these patches really matter. If you find out
! which ones, please inform address@hidden
! * Emacs aborts while starting up, only when run without X.
! This problem often results from compiling Emacs with GCC when GCC was
! installed incorrectly. The usual error in installing GCC is to
! specify --includedir=/usr/include. Installation of GCC makes
! corrected copies of the system header files. GCC is supposed to use
! the corrected copies in preference to the original system headers.
! Specifying --includedir=/usr/include causes the original system header
! files to be used. On some systems, the definition of ioctl in the
! original system header files is invalid for ANSI C and causes Emacs
! not to work.
! The fix is to reinstall GCC, and this time do not specify --includedir
! when you configure it. Then recompile Emacs. Specifying --includedir
! is appropriate only in very special cases and it should *never* be the
! same directory where system header files are kept.
! * On Solaris 2.x, GCC complains "64 bit integer types not supported"
- This suggests that GCC is not installed correctly. Most likely you
- are using GCC 2.7.2.3 (or earlier) on Solaris 2.6 (or later); this
- does not work without patching. To run GCC 2.7.2.3 on Solaris 2.6 or
- later, you must patch fixinc.svr4 and reinstall GCC from scratch as
- described in the Solaris FAQ
- <http://www.wins.uva.nl/pub/solaris/solaris2.html>. A better fix is
- to upgrade to GCC 2.8.1 or later.
! * The Compose key on a DEC keyboard does not work as Meta key.
! This shell command should fix it:
! xmodmap -e 'keycode 0xb1 = Meta_L'
! * Regular expressions matching bugs on SCO systems.
! On SCO, there are problems in regexp matching when Emacs is compiled
! with the system compiler. The compiler version is "Microsoft C
! version 6", SCO 4.2.0h Dev Sys Maintenance Supplement 01/06/93; Quick
! C Compiler Version 1.00.46 (Beta). The solution is to compile with
! GCC.
! * On Sunos 4, you get the error ld: Undefined symbol __lib_version.
! This is the result of using cc or gcc with the shared library meant
! for acc (the Sunpro compiler). Check your LD_LIBRARY_PATH and delete
! /usr/lang/SC2.0.1 or some similar directory.
! * You can't select from submenus (in the X toolkit version).
! On certain systems, mouse-tracking and selection in top-level menus
! works properly with the X toolkit, but neither of them works when you
! bring up a submenu (such as Bookmarks or Compare or Apply Patch, in
! the Files menu).
! This works on most systems. There is speculation that the failure is
! due to bugs in old versions of X toolkit libraries, but no one really
! knows. If someone debugs this and finds the precise cause, perhaps a
! workaround can be found.
! * Unusable default font on SCO 3.2v4.
! The Open Desktop environment comes with default X resource settings
! that tell Emacs to use a variable-width font. Emacs cannot use such
! fonts, so it does not work.
! This is caused by the file /usr/lib/X11/app-defaults/ScoTerm, which is
! the application-specific resource file for the `scoterm' terminal
! emulator program. It contains several extremely general X resources
! that affect other programs besides `scoterm'. In particular, these
! resources affect Emacs also:
! *Font: -*-helvetica-medium-r-*--12-*-p-*
! *Background: scoBackground
! *Foreground: scoForeground
! The best solution is to create an application-specific resource file for
! Emacs, /usr/lib/X11/sco/startup/Emacs, with the following contents:
! Emacs*Font: -*-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-1
! Emacs*Background: white
! Emacs*Foreground: black
! (These settings mimic the Emacs defaults, but you can change them to
! suit your needs.) This resource file is only read when the X server
! starts up, so you should restart it by logging out of the Open Desktop
! environment or by running `scologin stop; scologin start` from the shell
! as root. Alternatively, you can put these settings in the
! /usr/lib/X11/app-defaults/Emacs resource file and simply restart Emacs,
! but then they will not affect remote invocations of Emacs that use the
! Open Desktop display.
! These resource files are not normally shared across a network of SCO
! machines; you must create the file on each machine individually.
! * rcs2log gives you the awk error message "too many fields".
! This is due to an arbitrary limit in certain versions of awk.
! The solution is to use gawk (GNU awk).
! * Emacs is slow using X11R5 on HP/UX.
! This happens if you use the MIT versions of the X libraries--it
! doesn't run as fast as HP's version. People sometimes use the version
! because they see the HP version doesn't have the libraries libXaw.a,
! libXmu.a, libXext.a and others. HP/UX normally doesn't come with
! those libraries installed. To get good performance, you need to
! install them and rebuild Emacs.
! * Loading fonts is very slow.
! You might be getting scalable fonts instead of precomputed bitmaps.
! Known scalable font directories are "Type1" and "Speedo". A font
! directory contains scalable fonts if it contains the file
! "fonts.scale".
! If this is so, re-order your X windows font path to put the scalable
! font directories last. See the documentation of `xset' for details.
! With some X servers, it may be necessary to take the scalable font
! directories out of your path entirely, at least for Emacs 19.26.
! Changes in the future may make this unnecessary.
! * On AIX 3.2.4, releasing Ctrl/Act key has no effect, if Shift is down.
! Due to a feature of AIX, pressing or releasing the Ctrl/Act key is
! ignored when the Shift, Alt or AltGr keys are held down. This can
! lead to the keyboard being "control-locked"--ordinary letters are
! treated as control characters.
! You can get out of this "control-locked" state by pressing and
! releasing Ctrl/Act while not pressing or holding any other keys.
! * display-time causes kernel problems on ISC systems.
! Under Interactive Unix versions 3.0.1 and 4.0 (and probably other
! versions), display-time causes the loss of large numbers of STREVENT
! cells. Eventually the kernel's supply of these cells is exhausted.
! This makes emacs and the whole system run slow, and can make other
! processes die, in particular pcnfsd.
! Other emacs functions that communicate with remote processes may have
! the same problem. Display-time seems to be far the worst.
! The only known fix: Don't run display-time.
! * On Solaris, C-x doesn't get through to Emacs when you use the console.
! This is a Solaris feature (at least on Intel x86 cpus). Type C-r
! C-r C-t, to toggle whether C-x gets through to Emacs.
! * Error message `Symbol's value as variable is void: x', followed by
! segmentation fault and core dump.
! This has been tracked to a bug in tar! People report that tar erroneously
! added a line like this at the beginning of files of Lisp code:
! x FILENAME, N bytes, B tape blocks
! If your tar has this problem, install GNU tar--if you can manage to
! untar it :-).
! * Link failure when using acc on a Sun.
! To use acc, you need additional options just before the libraries, such as
! /usr/lang/SC2.0.1/values-Xt.o -L/usr/lang/SC2.0.1/cg87 -L/usr/lang/SC2.0.1
! and you need to add -lansi just before -lc.
! The precise file names depend on the compiler version, so we
! cannot easily arrange to supply them.
! * Link failure on IBM AIX 1.3 ptf 0013.
! There is a real duplicate definition of the function `_slibc_free' in
! the library /lib/libc_s.a (just do nm on it to verify). The
! workaround/fix is:
! cd /lib
! ar xv libc_s.a NLtmtime.o
! ar dv libc_s.a NLtmtime.o
! * Undefined symbols _dlopen, _dlsym and/or _dlclose on a Sun.
! If you see undefined symbols _dlopen, _dlsym, or _dlclose when linking
! with -lX11, compile and link against the file mit/util/misc/dlsym.c in
! the MIT X11R5 distribution. Alternatively, link temacs using shared
! libraries with s/sunos4shr.h. (This doesn't work if you use the X
! toolkit.)
! If you get the additional error that the linker could not find
! lib_version.o, try extracting it from X11/usr/lib/X11/libvim.a in
! X11R4, then use it in the link.
! * Error messages `Wrong number of arguments: #<subr where-is-internal>, 5'
! This typically results from having the powerkey library loaded.
! Powerkey was designed for Emacs 19.22. It is obsolete now because
! Emacs 19 now has this feature built in; and powerkey also calls
! where-is-internal in an obsolete way.
! So the fix is to arrange not to load powerkey.
! * In Shell mode, you get a ^M at the end of every line.
! This happens to people who use tcsh, because it is trying to be too
! smart. It sees that the Shell uses terminal type `unknown' and turns
! 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 == "t") then
! unset edit
! stty -icrnl -onlcr -echo susp ^Z
! endif
! endif
! * An error message such as `X protocol error: BadMatch (invalid
! parameter attributes) on protocol request 93'.
! This comes from having an invalid X resource, such as
! emacs*Cursor: black
! (which is invalid because it specifies a color name for something
! that isn't a color.)
! The fix is to correct your X resources.
! * Undefined symbols when linking on Sunos 4.1 using --with-x-toolkit.
! If you get the undefined symbols _atowc _wcslen, _iswprint, _iswspace,
! _iswcntrl, _wcscpy, and _wcsncpy, then you need to add -lXwchar after
! -lXaw in the command that links temacs.
! This problem seems to arise only when the international language
! extensions to X11R5 are installed.
! * Typing C-c C-c in Shell mode kills your X server.
! This happens with Linux kernel 1.0 thru 1.04, approximately. The workaround
is
! to define SIGNALS_VIA_CHARACTERS in config.h and recompile Emacs.
! Newer Linux kernel versions don't have this problem.
! * src/Makefile and lib-src/Makefile are truncated--most of the file missing.
! This can happen if configure uses GNU sed version 2.03. That version
! had a bug. GNU sed version 2.05 works properly.
! * Slow startup on X11R6 with X windows.
! If Emacs takes two minutes to start up on X11R6, see if your X
! resources specify any Adobe fonts. That causes the type-1 font
! renderer to start up, even if the font you asked for is not a type-1
! font.
! One way to avoid this problem is to eliminate the type-1 fonts from
! your font path, like this:
! xset -fp /usr/X11R6/lib/X11/fonts/Type1/
! * Pull-down menus appear in the wrong place, in the toolkit version of Emacs.
! An X resource of this form can cause the problem:
! Emacs*geometry: 80x55+0+0
! This resource is supposed to apply, and does apply, to the menus
! individually as well as to Emacs frames. If that is not what you
! want, rewrite the resource.
! To check thoroughly for such resource specifications, use `xrdb
! -query' to see what resources the X server records, and also look at
! the user's ~/.Xdefaults and ~/.Xdefaults-* files.
! * --with-x-toolkit version crashes when used with shared libraries.
! On some systems, including Sunos 4 and DGUX 5.4.2 and perhaps others,
! unexec doesn't work properly with the shared library for the X
! toolkit. You might be able to work around this by using a nonshared
! libXt.a library. The real fix is to upgrade the various versions of
! unexec and/or ralloc. We think this has been fixed on Sunos 4
! and Solaris in version 19.29.
! * `make install' fails on install-doc with `Error 141'.
! This happens on Ultrix 4.2 due to failure of a pipeline of tar
! commands. We don't know why they fail, but the bug seems not to be in
! Emacs. The workaround is to run the shell command in install-doc by
! hand.
! * --with-x-toolkit option configures wrong on BSD/386.
! This problem is due to bugs in the shell in version 1.0 of BSD/386.
! The workaround is to edit the configure file to use some other shell,
! such as bash.
! * Subprocesses remain, hanging but not zombies, on Sunos 5.3.
! A bug in Sunos 5.3 causes Emacs subprocesses to remain after Emacs
! exits. Sun patch # 101415-02 is part of the fix for this, but it only
! applies to ptys, and doesn't fix the problem with subprocesses
! communicating through pipes.
! * Mail is lost when sent to local aliases.
Many emacs mail user agents (VM and rmail, for instance) use the
sendmail.el library. This library can arrange for mail to be
--- 959,2852 ----
`fonts.alias' file, then run `mkfontdir' in that directory, and then run
`xset fp rehash'.
! ** The `oc-unicode' package doesn't work with Emacs 21.
! This package tries to define more private charsets than there are free
! 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.
! ** 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
! (standard-display-european 1 t)
! * X runtime problems
! ** X keyboard problems
! *** You "lose characters" after typing Compose Character key.
! This is because the Compose Character key is defined as the keysym
! Multi_key, and Emacs (seeing that) does the proper X11
! character-composition processing. If you don't want your Compose key
! to do that, you can redefine it with xmodmap.
! For example, here's one way to turn it into a Meta key:
! xmodmap -e "keysym Multi_key = Meta_L"
! If all users at your site of a particular keyboard prefer Meta to
! Compose, you can make the remapping happen automatically by adding the
! xmodmap command to the xdm setup script for that display.
! *** Using X Windows, control-shift-leftbutton makes Emacs hang.
! Use the shell command `xset bc' to make the old X Menu package work.
! *** 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.
! *** 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
! purposes.
! 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.
! *** 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.
! *** 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.
! *** Inability to send an Alt-modified key, when Emacs is communicating
! directly with an X server.
! If you have tried to bind an Alt-modified key as a command, and it
! does not work to type the command, the first thing you should check is
! whether the key is getting through to Emacs. To do this, type C-h c
! followed by the Alt-modified key. C-h c should say what kind of event
! it read. If it says it read an Alt-modified key, then make sure you
! have made the key binding correctly.
! If C-h c reports an event that doesn't have the Alt modifier, it may
! be because your X server has no key for the Alt modifier. The X
! server that comes from MIT does not set up the Alt modifier by
! default.
! If your keyboard has keys named Alt, you can enable them as follows:
! xmodmap -e 'add mod2 = Alt_L'
! xmodmap -e 'add mod2 = Alt_R'
! If the keyboard has just one key named Alt, then only one of those
! commands is needed. The modifier `mod2' is a reasonable choice if you
! are using an unmodified MIT version of X. Otherwise, choose any
! modifier bit not otherwise used.
! If your keyboard does not have keys named Alt, you can use some other
! keys. Use the keysym command in xmodmap to turn a function key (or
! some other 'spare' key) into Alt_L or into Alt_R, and then use the
! commands show above to make them modifier keys.
! Note that if you have Alt keys but no Meta keys, Emacs translates Alt
! into Meta. This is because of the great importance of Meta in Emacs.
! ** Window-manager and toolkit-related problems
! *** Gnome: 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.
! *** KDE: 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
! empty portions of the Emacs display, while characters have some other
! background.
! 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"
! option in Preferences->Look&Feel->Style (KDE 2). In KDE 3, this option
! is in the "Colors" section, rather than "Style".
! Alternatively, if you do want the KDE defaults to apply to other
! applications, but not to Emacs, you could modify the file `Emacs.ad'
! (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:
! Emacs.default.attributeForeground
! Emacs.default.attributeBackground
! Emacs*Foreground
! Emacs*Background
! *** KDE: Emacs hangs on KDE when a large portion of text is killed.
! 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:
! Timed out waiting for property-notify event
! A workaround is to not use `klipper'.
! *** CDE: 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".
! *** Xaw3d : 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.
! *** Xaw: 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.
! 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.
! *** Open Motif: 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.
! The solution is to use LessTif instead. LessTif is a free replacement
! 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.
! *** LessTif: 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.
! 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.
! On some systems, even with Motif 1.2 emulation, Emacs occasionally
! locks up, grabbing all mouse and keyboard events. We still don't know
! what causes these problems; they are not reproducible by Emacs
! developers.
! *** Motif: The Motif version of Emacs paints the screen a solid color.
! This has been observed to result from the following X resource:
! Emacs*default.attributeFont:
-*-courier-medium-r-*-*-*-140-*-*-*-*-iso8859-*
! That the resource has this effect indicates a bug in something, but we
! do not yet know what. If it is an Emacs bug, we hope someone can
! explain what the bug is so we can fix it. In the mean time, removing
! the resource prevents the problem.
! ** General X problems
! *** 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)
! *** 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.
! *** Improving performance with slow X connections.
! 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
! 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
! package.
! 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:
! http://www.xfree86.org/4.3.0/lbxproxy.1.html
! *** 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 does not notice when you release the mouse.
! There are reports that this happened with (some) Microsoft mice and
! that replacing the mouse made it stop.
! *** You can't select from submenus (in the X toolkit version).
! On certain systems, mouse-tracking and selection in top-level menus
! works properly with the X toolkit, but neither of them works when you
! bring up a submenu (such as Bookmarks or Compare or Apply Patch, in
! the Files menu).
! This works on most systems. There is speculation that the failure is
! due to bugs in old versions of X toolkit libraries, but no one really
! knows. If someone debugs this and finds the precise cause, perhaps a
! workaround can be found.
! *** An error message such as `X protocol error: BadMatch (invalid
! parameter attributes) on protocol request 93'.
! This comes from having an invalid X resource, such as
! emacs*Cursor: black
! (which is invalid because it specifies a color name for something
! that isn't a color.)
! The fix is to correct your X resources.
! *** Slow startup on X11R6 with X windows.
! If Emacs takes two minutes to start up on X11R6, see if your X
! resources specify any Adobe fonts. That causes the type-1 font
! renderer to start up, even if the font you asked for is not a type-1
! font.
! One way to avoid this problem is to eliminate the type-1 fonts from
! your font path, like this:
! xset -fp /usr/X11R6/lib/X11/fonts/Type1/
! *** Pull-down menus appear in the wrong place, in the toolkit version of
Emacs.
! An X resource of this form can cause the problem:
! Emacs*geometry: 80x55+0+0
! This resource is supposed to apply, and does apply, to the menus
! individually as well as to Emacs frames. If that is not what you
! want, rewrite the resource.
! To check thoroughly for such resource specifications, use `xrdb
! -query' to see what resources the X server records, and also look at
! the user's ~/.Xdefaults and ~/.Xdefaults-* files.
! *** --with-x-toolkit version crashes when used with shared libraries.
! On some systems, including Sunos 4 and DGUX 5.4.2 and perhaps others,
! unexec doesn't work properly with the shared library for the X
! toolkit. You might be able to work around this by using a nonshared
! libXt.a library. The real fix is to upgrade the various versions of
! unexec and/or ralloc. We think this has been fixed on Sunos 4
! and Solaris in version 19.29.
! *** Emacs running under X Windows does not handle mouse clicks.
! *** `emacs -geometry 80x20' finds a file named `80x20'.
! One cause of such problems is having (setq term-file-prefix nil) in
! your .emacs file. Another cause is a bad value of EMACSLOADPATH in
! the environment.
! *** Emacs fails to get default settings from X Windows server.
! The X library in X11R4 has a bug; it interchanges the 2nd and 3rd
! arguments to XGetDefaults. Define the macro XBACKWARDS in config.h to
! tell Emacs to compensate for this.
! I don't believe there is any way Emacs can determine for itself
! whether this problem is present on a given system.
! *** X Windows doesn't work if DISPLAY uses a hostname.
! People have reported kernel bugs in certain systems that cause Emacs
! not to work with X Windows if DISPLAY is set using a host name. But
! the problem does not occur if DISPLAY is set to `unix:0.0'. I think
! the bug has to do with SIGIO or FIONREAD.
! You may be able to compensate for the bug by doing (set-input-mode nil nil).
! However, that has the disadvantage of turning off interrupts, so that
! you are unable to quit out of a Lisp program by typing C-g.
! The easy way to do this is to put
! (setq x-sigio-bug t)
! in your site-init.el file.
! * Runtime problems on character termunals
+ ** Emacs spontaneously displays "I-search: " at the bottom of the screen.
! This means that Control-S/Control-Q (XON/XOFF) "flow control" is being
! used. C-s/C-q flow control is bad for Emacs editors because it takes
! away C-s and C-q as user commands. Since editors do not output long
! streams of text without user commands, there is no need for a
! user-issuable "stop output" command in an editor; therefore, a
! properly designed flow control mechanism would transmit all possible
! input characters without interference. Designing such a mechanism is
! easy, for a person with at least half a brain.
! There are three possible reasons why flow control could be taking place:
! 1) Terminal has not been told to disable flow control
! 2) Insufficient padding for the terminal in use
! 3) Some sort of terminal concentrator or line switch is responsible
! 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
! 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.
! Once the terminal has been told "no flow control", you may find it
! needs more padding. The amount of padding Emacs sends is controlled
! by the termcap entry for the terminal in use, and by the output baud
! rate as known by the kernel. The shell command `stty' will print
! your output baud rate; `stty' with suitable arguments will set it if
! it is wrong. Setting to a higher speed causes increased padding. If
! the results are wrong for the correct speed, there is probably a
! problem in the termcap entry. You must speak to a local Unix wizard
! to fix this. Perhaps you are just using the wrong terminal type.
! For terminals that lack a "no flow control" mode, sometimes just
! giving lots of padding will prevent actual generation of flow control
! codes. You might as well try it.
! If you are really unlucky, your terminal is connected to the computer
! through a concentrator which sends XON/XOFF flow control to the
! computer, or it insists on sending flow control itself no matter how
! much padding you give it. Unless you can figure out how to turn flow
! control off on this concentrator (again, refer to your local wizard),
! you are screwed! You should have the terminal or concentrator
! replaced with a properly designed one. In the mean time, some drastic
! measures can make Emacs semi-work.
! You can make Emacs ignore C-s and C-q and let the operating system
! handle them. To do this on a per-session basis, just type M-x
! enable-flow-control RET. You will see a message that C-\ and C-^ are
! now translated to C-s and C-q. (Use the same command M-x
! enable-flow-control to turn *off* this special mode. It toggles flow
! control handling.)
! If C-\ and C-^ are inconvenient for you (for example, if one of them
! is the escape character of your terminal concentrator), you can choose
! other characters by setting the variables flow-control-c-s-replacement
! and flow-control-c-q-replacement. But choose carefully, since all
! other control characters are already used by emacs.
! IMPORTANT: if you type C-s by accident while flow control is enabled,
! Emacs output will freeze, and you will have to remember to type C-q in
! order to continue.
! If you work in an environment where a majority of terminals of a
! certain type are flow control hobbled, you can use the function
! `enable-flow-control-on' to turn on this flow control avoidance scheme
! automatically. Here is an example:
! (enable-flow-control-on "vt200" "vt300" "vt101" "vt131")
! If this isn't quite correct (e.g. you have a mixture of flow-control hobbled
! and good vt200 terminals), you can still run enable-flow-control
! manually.
! I have no intention of ever redesigning the Emacs command set for the
! assumption that terminals use C-s/C-q flow control. XON/XOFF flow
! control technique is a bad design, and terminals that need it are bad
! merchandise and should not be purchased. Now that X is becoming
! widespread, XON/XOFF seems to be on the way out. If you can get some
! use out of GNU Emacs on inferior terminals, more power to you, but I
! will not make Emacs worse for properly designed systems for the sake
! of inferior systems.
! ** Control-S and Control-Q commands are ignored completely.
! For some reason, your system is using brain-damaged C-s/C-q flow
! control despite Emacs's attempts to turn it off. Perhaps your
! terminal is connected to the computer through a concentrator
! that wants to use flow control.
! You should first try to tell the concentrator not to use flow control.
! If you succeed in this, try making the terminal work without
! flow control, as described in the preceding section.
! If that line of approach is not successful, map some other characters
! into C-s and C-q using keyboard-translate-table. The example above
! shows how to do this with C-^ and C-\.
! ** Screen is updated wrong, but only on one kind of terminal.
! This could mean that the termcap entry you are using for that
! terminal is wrong, or it could mean that Emacs has a bug handing
! the combination of features specified for that terminal.
! The first step in tracking this down is to record what characters
! Emacs is sending to the terminal. Execute the Lisp expression
! (open-termscript "./emacs-script") to make Emacs write all
! terminal output into the file ~/emacs-script as well; then do
! what makes the screen update wrong, and look at the file
! and decode the characters using the manual for the terminal.
! There are several possibilities:
! 1) The characters sent are correct, according to the terminal manual.
! In this case, there is no obvious bug in Emacs, and most likely you
! need more padding, or possibly the terminal manual is wrong.
! 2) The characters sent are incorrect, due to an obscure aspect
! of the terminal behavior not described in an obvious way
! by termcap.
! This case is hard. It will be necessary to think of a way for
! Emacs to distinguish between terminals with this kind of behavior
! and other terminals that behave subtly differently but are
! classified the same by termcap; or else find an algorithm for
! Emacs to use that avoids the difference. Such changes must be
! tested on many kinds of terminals.
! 3) The termcap entry is wrong.
! See the file etc/TERMS for information on changes
! that are known to be needed in commonly used termcap entries
! for certain terminals.
! 4) The characters sent are incorrect, and clearly cannot be
! right for any terminal with the termcap entry you were using.
! This is unambiguously an Emacs bug, and can probably be fixed
! in termcap.c, tparam.c, term.c, scroll.c, cm.c or dispnew.c.
! ** Control-S and Control-Q commands are ignored completely on a net
connection.
! 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.
! 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.
! Some versions of tcsh will prevent even this from working. One way
! around this is to start another shell before starting rlogin, and
! issue the stty command to disable flow control from that shell.
! If none of these methods work, the best solution is to type
! M-x enable-flow-control at the beginning of your emacs session, or
! if you expect the problem to continue, add a line such as the
! following to your .emacs (on the host running rlogind):
! (enable-flow-control-on "vt200" "vt300" "vt101" "vt131")
! See the entry about spontaneous display of I-search (above) for more
! info.
! ** Output from Control-V is slow.
! On many bit-map terminals, scrolling operations are fairly slow.
! Often the termcap entry for the type of terminal in use fails
! to inform Emacs of this. The two lines at the bottom of the screen
! before a Control-V command are supposed to appear at the top after
! the Control-V command. If Emacs thinks scrolling the lines is fast,
! it will scroll them to the top of the screen.
! If scrolling is slow but Emacs thinks it is fast, the usual reason is
! that the termcap entry for the terminal you are using does not
! specify any padding time for the `al' and `dl' strings. Emacs
! concludes that these operations take only as much time as it takes to
! send the commands at whatever line speed you are using. You must
! fix the termcap entry to specify, for the `al' and `dl', as much
! time as the operations really take.
! Currently Emacs thinks in terms of serial lines which send characters
! at a fixed rate, so that any operation which takes time for the
! terminal to execute must also be padded. With bit-map terminals
! operated across networks, often the network provides some sort of
! flow control so that padding is never needed no matter how slow
! an operation is. You must still specify a padding time if you want
! Emacs to realize that the operation takes a long time. This will
! cause padding characters to be sent unnecessarily, but they do
! not really cost much. They will be transmitted while the scrolling
! is happening and then discarded quickly by the terminal.
! Most bit-map terminals provide commands for inserting or deleting
! multiple lines at once. Define the `AL' and `DL' strings in the
! termcap entry to say how to do these things, and you will have
! fast output without wasted padding characters. These strings should
! each contain a single %-spec saying how to send the number of lines
! to be scrolled. These %-specs are like those in the termcap
! `cm' string.
! You should also define the `IC' and `DC' strings if your terminal
! has a command to insert or delete multiple characters. These
! take the number of positions to insert or delete as an argument.
! A `cs' string to set the scrolling region will reduce the amount
! of motion you see on the screen when part of the screen is scrolled.
! ** You type Control-H (Backspace) expecting to delete characters.
! Put `stty dec' in your .login file and your problems will disappear
! after a day or two.
! The choice of Backspace for erasure was based on confusion, caused by
! the fact that backspacing causes erasure (later, when you type another
! character) on most display terminals. But it is a mistake. Deletion
! of text is not the same thing as backspacing followed by failure to
! overprint. I do not wish to propagate this confusion by conforming
! to it.
! For this reason, I believe `stty dec' is the right mode to use,
! and I have designed Emacs to go with that. If there were a thousand
! other control characters, I would define Control-h to delete as well;
! but there are not very many other control characters, and I think
! that providing the most mnemonic possible Help character is more
! important than adapting to people who don't use `stty dec'.
! If you are obstinate about confusing buggy overprinting with deletion,
! you can redefine Backspace in your .emacs file:
! (global-set-key "\b" 'delete-backward-char)
! You can probably access help-command via f1.
! ** Colors are not available on a tty or in xterm.
! 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
! Emacs. (Most color terminals support 8 or 16 colors.) If your system
! uses terminfo, the name of the capability equivalent to "Co" is
! "colors".
! 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"
! capability).
! 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.
! 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
! `xterm-color' might activate the color support on an xterm-compatible
! emulator.
! Beginning with version 21.4, Emacs supports the --color command-line
! 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.
! 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
! global-font-lock-mode RET" or by customizing the variable
! `global-font-lock-mode'.
! * Runtime problems specific to individual Unix variants
! ** GNU/Linux
! *** GNU/Linux: 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.
! *** GNU/Linux: 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
! modifier:
! 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/k.ps
! This produces a PostScript file `/tmp/k.ps' 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.
! *** GNU/Linux: low startup on Linux-based GNU systems.
! People using systems based on the Linux kernel sometimes report that
! startup takes 10 to 15 seconds longer than `usual'.
! This is because Emacs looks up the host name when it starts.
! Normally, this takes negligible time; the extra delay is due to
! improper system configuration. This problem can occur for both
! networked and non-networked machines.
! Here is how to fix the configuration. It requires being root.
! **** Networked Case.
! First, make sure the files `/etc/hosts' and `/etc/host.conf' both
! exist. The first line in the `/etc/hosts' file should look like this
! (replace HOSTNAME with your host name):
! 127.0.0.1 HOSTNAME
! Also make sure that the `/etc/host.conf' files contains the following
! lines:
! order hosts, bind
! multi on
! Any changes, permanent and temporary, to the host name should be
! indicated in the `/etc/hosts' file, since it acts a limited local
! database of addresses and names (e.g., some SLIP connections
! dynamically allocate ip addresses).
! **** Non-Networked Case.
! The solution described in the networked case applies here as well.
! However, if you never intend to network your machine, you can use a
! simpler solution: create an empty `/etc/host.conf' file. The command
! `touch /etc/host.conf' suffices to create the file. The `/etc/hosts'
! file is not necessary with this approach.
! *** GNU/Linux: 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.
! Alternatively, if you want a blinking underscore as your Emacs cursor,
! change the "cvvis" capability to send the "\E[?25h\E[?0c" command.
! *** GNU/Linux: Error messages `internal facep []' happen on GNU/Linux systems.
! There is a report that replacing libc.so.5.0.9 with libc.so.5.2.16
! caused this to start happening. People are not sure why, but the
! problem seems unlikely to be in Emacs itself. Some suspect that it
! is actually Xlib which won't work with libc.so.5.2.16.
! Using the old library version is a workaround.
! ** Mac OS X
! *** Mac OS X (Carbon): Environment Variables from dotfiles are ignored.
! When starting Emacs from the Dock or the Finder on Mac OS X, the
! environment variables that are set up in dotfiles, such as .cshrc or
! .profile, are ignored. This is because the Finder and Dock are not
! started from a shell, but instead from the Window Manager itself.
! The workaround for this is to create a .MacOSX/environment.plist file to
! setup these environment variables. These environment variables will
! apply to all processes regardless of where they are started.
! For me information, see http://developer.apple.com/qa/qa2001/qa1067.html.
! *** Mac OS X (Carbon): Process output truncated when using ptys.
! 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.
! ** FreeBSD
! *** FreeBSD 2.1.5: useless symbolic links remain in /tmp or other
! directories that have the +t bit.
! This is because of a kernel bug in FreeBSD 2.1.5 (fixed in 2.2).
! Emacs uses symbolic links to implement file locks. In a directory
! with +t bit, the directory owner becomes the owner of the symbolic
! link, so that it cannot be removed by anyone else.
! If you don't like those useless links, you can let Emacs not to using
! file lock by adding #undef CLASH_DETECTION to config.h.
! *** FreeBSD: Getting a Meta key on the 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
! ** HP-UX
! *** HP/UX : Shell mode gives the message, "`tty`: Ambiguous".
! address@hidden says:
! The problem is that in your .cshrc you have something that tries to
! execute `tty`. If you are not running the shell on a real tty then
! tty will print "not a tty". Csh expects one word in some places,
! but tty is giving it back 3.
! The solution is to add a pair of quotes around `tty` to make it a single
! word:
! if (`tty` == "/dev/console")
! should be changed to:
! if ("`tty`" == "/dev/console")
! Even better, move things that set up terminal sections out of .cshrc
! and into .login.
! *** HP/UX: `Pid xxx killed due to text modification or page I/O error'.
! On HP/UX, you can get that error when the Emacs executable is on an NFS
! file system. HP/UX responds this way if it tries to swap in a page and
! does not get a response from the server within a timeout whose default
! value is just ten seconds.
! If this happens to you, extend the timeout period.
! *** HP/UX: Emacs is slow using X11R5.
! This happens if you use the MIT versions of the X libraries--it
! doesn't run as fast as HP's version. People sometimes use the version
! because they see the HP version doesn't have the libraries libXaw.a,
! libXmu.a, libXext.a and others. HP/UX normally doesn't come with
! those libraries installed. To get good performance, you need to
! install them and rebuild Emacs.
! *** HP/UX: The right Alt key works wrong on German HP keyboards (and perhaps
! other non-English HP keyboards too).
! This is because HP-UX defines the modifiers wrong in X. Here is a
! shell script to fix the problem; be sure that it is run after VUE
! configures the X server.
! xmodmap 2> /dev/null - << EOF
! keysym Alt_L = Meta_L
! keysym Alt_R = Meta_R
! EOF
! xmodmap - << EOF
! clear mod1
! keysym Mode_switch = NoSymbol
! add mod1 = Meta_L
! keysym Meta_R = Mode_switch
! add mod2 = Mode_switch
! EOF
! *** HP/UX: "Cannot find callback list" messages from dialog boxes in
! Emacs built with Motif.
! This problem resulted from a bug in GCC 2.4.5. Newer GCC versions
! such as 2.7.0 fix the problem.
! *** HP/UX: Emacs does not recognize the AltGr key.
! 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
! EOF
! xmodmap - << EOF
! clear mod1
! keysym Mode_switch = NoSymbol
! add mod1 = Meta_L
! keysym Meta_R = Mode_switch
! add mod2 = Mode_switch
! EOF
! --------------------------------
! *** HP/UX: Large file support is disabled.
! See the comments in src/s/hpux10.h.
! *** HP/UX 11.0: Emacs makes HP/UX 11.0 crash.
! This is a bug in HPUX; HPUX patch PHKL_16260 is said to fix it.
! ** AIX
! *** AIX: Trouble using ptys.
! People often install the pty devices on AIX incorrectly.
! Use `smit pty' to reinstall them properly.
! *** AIXterm: Your Delete key sends a Backspace to the terminal.
! The solution is to include in your .Xdefaults the lines:
! *aixterm.Translations: #override <Key>BackSpace: string(0x7f)
! aixterm*ttyModes: erase ^?
! This makes your Backspace key send DEL (ASCII 127).
! *** AIX: You get this message when running Emacs:
! Could not load program emacs
! Symbol smtcheckinit in csh is undefined
! Error was: Exec format error
! or this one:
! Could not load program .emacs
! Symbol _system_con in csh is undefined
! Symbol _fp_trapsta in csh is undefined
! Error was: Exec format error
! These can happen when you try to run on AIX 3.2.5 a program that was
! compiled with 3.2.4. The fix is to recompile.
! *** AIX 3.2.4: Releasing Ctrl/Act key has no effect, if Shift is down.
! Due to a feature of AIX, pressing or releasing the Ctrl/Act key is
! ignored when the Shift, Alt or AltGr keys are held down. This can
! lead to the keyboard being "control-locked"--ordinary letters are
! treated as control characters.
! You can get out of this "control-locked" state by pressing and
! releasing Ctrl/Act while not pressing or holding any other keys.
! *** AIX 4.2: Emacs gets a segmentation fault at startup.
! If you are using IBM's xlc compiler, compile emacs.c
! without optimization; that should avoid the problem.
! *** 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'.
! *** AIX 4.3.x or 4.4: Compiling fails.
! This could happen if you use /bin/c89 as your compiler, instead of
! 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'.
! *** AIX 4: Some programs fail when run in a Shell buffer
! with an error message like No terminfo entry for "unknown".
! On AIX, many terminal type definitions are not installed by default.
! `unknown' is one of them. Install the "Special Generic Terminal
! Definitions" to make them defined.
! ** Solaris
! We list bugs in current versions here. Solaris 2.x and 4.x are covered in the
! section on legacy systems.
! *** On Solaris, C-x doesn't get through to Emacs when you use the console.
! This is a Solaris feature (at least on Intel x86 cpus). Type C-r
! C-r C-t, to toggle whether C-x gets through to Emacs.
! *** Problem with remote X server on Suns.
! On a Sun, running Emacs on one machine with the X server on another
! may not work if you have used the unshared system libraries. This
! is because the unshared libraries fail to use YP for host name lookup.
! As a result, the host name you specify may not be recognized.
! *** 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.
! *** 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:
! /usr/openwin/lib/locale/iso8859-15/Compose
! 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.
! *** When using M-x dbx with the SparcWorks debugger, the `up' and `down'
! commands do not move the arrow in Emacs.
! You can fix this by adding the following line to `~/.dbxinit':
! dbxenv output_short_file_name off
! ** Irix
! *** Irix 5.2: unexelfsgi.c can't find cmplrs/stsupport.h.
! The file cmplrs/stsupport.h was included in the wrong file set in the
! Irix 5.2 distribution. You can find it in the optional fileset
! compiler_dev, or copy it from some other Irix 5.2 system. A kludgy
! workaround is to change unexelfsgi.c to include sym.h instead of
! syms.h.
! *** Irix 5.3: "out of virtual swap space".
! This message occurs when the system runs out of swap space due to too
! many large programs running. The solution is either to provide more
! swap space or to reduce the number of large programs being run. You
! can check the current status of the swap space by executing the
! command `swap -l'.
! You can increase swap space by changing the file /etc/fstab. Adding a
! line like this:
! /usr/swap/swap.more swap swap pri=3 0 0
! where /usr/swap/swap.more is a file previously created (for instance
! by using /etc/mkfile), will increase the swap space by the size of
! that file. Execute `swap -m' or reboot the machine to activate the
! new swap area. See the manpages for `swap' and `fstab' for further
! information.
! The objectserver daemon can use up lots of memory because it can be
! swamped with NIS information. It collects information about all users
! on the network that can log on to the host.
! If you want to disable the objectserver completely, you can execute
! the command `chkconfig objectserver off' and reboot. That may disable
! some of the window system functionality, such as responding CDROM
! icons.
! You can also remove NIS support from the objectserver. The SGI `admin'
! FAQ has a detailed description on how to do that; see question 35
! ("Why isn't the objectserver working?"). The admin FAQ can be found at
! ftp://viz.tamu.edu/pub/sgi/faq/.
! *** Irix 5.3: Emacs crashes in utmpname.
! This problem is fixed in Patch 3175 for Irix 5.3.
! It is also fixed in Irix versions 6.2 and up.
! *** Irix 6.0: Make tries (and fails) to build a program named unexelfsgi.
! A compiler bug inserts spaces into the string "unexelfsgi . o"
! in src/Makefile. Edit src/Makefile, after configure is run,
! find that string, and take out the spaces.
! Compiler fixes in Irix 6.0.1 should eliminate this problem.
! *** Irix 6.5: Emacs crashes on the SGI R10K, when compiled with GCC.
! This seems to be fixed in GCC 2.95.
! *** Trouble using ptys on IRIX, 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.
! ** SCO Unix and UnixWare
! *** SCO 3.2v4: Unusable default font.
! The Open Desktop environment comes with default X resource settings
! that tell Emacs to use a variable-width font. Emacs cannot use such
! fonts, so it does not work.
! This is caused by the file /usr/lib/X11/app-defaults/ScoTerm, which is
! the application-specific resource file for the `scoterm' terminal
! emulator program. It contains several extremely general X resources
! that affect other programs besides `scoterm'. In particular, these
! resources affect Emacs also:
! *Font: -*-helvetica-medium-r-*--12-*-p-*
! *Background: scoBackground
! *Foreground: scoForeground
! The best solution is to create an application-specific resource file for
! Emacs, /usr/lib/X11/sco/startup/Emacs, with the following contents:
! Emacs*Font: -*-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-1
! Emacs*Background: white
! Emacs*Foreground: black
! (These settings mimic the Emacs defaults, but you can change them to
! suit your needs.) This resource file is only read when the X server
! starts up, so you should restart it by logging out of the Open Desktop
! environment or by running `scologin stop; scologin start` from the shell
! as root. Alternatively, you can put these settings in the
! /usr/lib/X11/app-defaults/Emacs resource file and simply restart Emacs,
! but then they will not affect remote invocations of Emacs that use the
! Open Desktop display.
! These resource files are not normally shared across a network of SCO
! machines; you must create the file on each machine individually.
! *** Regular expressions matching bugs on SCO systems.
! On SCO, there are problems in regexp matching when Emacs is compiled
! with the system compiler. The compiler version is "Microsoft C
! version 6", SCO 4.2.0h Dev Sys Maintenance Supplement 01/06/93; Quick
! C Compiler Version 1.00.46 (Beta). The solution is to compile with
! GCC.
! *** UnixWare 2.1: Error 12 (virtual memory exceeded) when dumping Emacs.
! Paul Abrahams (address@hidden) 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.
! * Runtime problems specific to MS-Windows
! ** Emacs exits with "X protocol error" when run with an X server for
MS-Windows.
! A certain X server for Windows had a bug which caused this.
! Supposedly the newer 32-bit version of this server doesn't have the
! problem.
! ** 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
! is displayed. This also means help text for pop-up menus is not
! 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.
! 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.
! 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.
! Some minor flickering still persists during mouse-tracking, although
! not as severely as in 21.1.
! 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
! of these input methods cause the keyboard to send characters encoded
! in the appropriate coding system (e.g., ISO 8859-1 for Latin-1
! 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
! yet.)
! 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.
! ** Problems running Perl under Emacs on MS-Windows NT/95.
! `perl -de 0' just hangs when executed in an Emacs subshell.
! The fault lies with Perl (indirectly with Windows NT/95).
! The problem is that the Perl debugger explicitly opens a connection to
! "CON", which is the DOS/NT equivalent of "/dev/tty", for interacting
! with the user.
! On Unix, this is okay, because Emacs (or the shell?) creates a
! pseudo-tty so that /dev/tty is really the pipe Emacs is using to
! communicate with the subprocess.
! On NT, this fails because CON always refers to the handle for the
! relevant console (approximately equivalent to a tty), and cannot be
! redirected to refer to the pipe Emacs assigned to the subprocess as
! stdin.
! A workaround is to modify perldb.pl to use STDIN/STDOUT instead of CON.
! For Perl 4:
! *** PERL/LIB/PERLDB.PL.orig Wed May 26 08:24:18 1993
! --- PERL/LIB/PERLDB.PL Mon Jul 01 15:28:16 1996
! ***************
! *** 68,74 ****
! $rcfile=".perldb";
! }
! else {
! ! $console = "con";
! $rcfile="perldb.ini";
! }
! --- 68,74 ----
! $rcfile=".perldb";
! }
! else {
! ! $console = "";
! $rcfile="perldb.ini";
! }
! For Perl 5:
! *** perl/5.001/lib/perl5db.pl.orig Sun Jun 04 21:13:40 1995
! --- perl/5.001/lib/perl5db.pl Mon Jul 01 17:00:08 1996
! ***************
! *** 22,28 ****
! $rcfile=".perldb";
! }
! elsif (-e "con") {
! ! $console = "con";
! $rcfile="perldb.ini";
! }
! else {
! --- 22,28 ----
! $rcfile=".perldb";
! }
! elsif (-e "con") {
! ! $console = "";
! $rcfile="perldb.ini";
! }
! else {
! ** On MS-Windows 95, Alt-f6 does not get through to Emacs.
! This character seems to be trapped by the kernel in Windows 95.
! You can enter M-f6 by typing ESC f6.
! ** Typing Alt-Shift has strange effects on MS-Windows.
! This combination of keys is a command to change keyboard layout. If
! you proceed to type another non-modifier key before you let go of Alt
! and Shift, the Alt and Shift act as modifiers in the usual way. A
! more permanent work around is to change it to another key combination,
! or disable it in the keyboard control panel.
! ** 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.)
! ** 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
! 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:
! (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" "")
! ** 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
! has):
! (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
! ** 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.
! 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
! http://www.gnu.org/software/emacs/windows/.
! ** 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
! particular, this has been reported when trying to compile a Java
! program in JDEE when javac.exe is installed, but not on the system
! PATH.
! ** 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.
! ** 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
! seen.
! ** On MS-Windows, you cannot use the right-hand ALT key and the left-hand
! 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
! AltGr has been pressed. The variable `w32-recognize-altgr' can be set
! to nil to tell Emacs that AltGr is really Ctrl and Alt.
! ** Under some X-servers running on MS-Windows, Emacs' display is incorrect.
! 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.
! This is known to occur under Exceed 6, and possibly earlier versions
! as well; it is reportedly solved in version 6.2.0.16 and later. The
! problem lies in the X-server settings.
! 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
! selection".
! Of this does not work, please inform address@hidden Then
! please call support for your X-server and see if you can get a fix.
! If you do, please send it to address@hidden so we can list it
! here.
! * Build-time problems
! ** Configuration
! *** The `configure' script doesn't find the jpeg library.
! 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.
! *** AIX: You get this compiler error message:
! Processing include file ./XMenuInt.h
! 1501-106: (S) Include file X11/Xlib.h not found.
! This means your system was installed with only the X11 runtime i.d
! libraries. You have to find your sipo (bootable tape) and install
! X11Dev... with smit.
! ** Compilation
! *** Building Emacs over NFS fails with ``Text file busy''.
! 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.
! 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.
! 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
! `/etc/auto.home'.
! 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.
! 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'.
! *** 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
! 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
! variables).
! The solution is to make sure the preprocessor is run with the
! `-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 ...
! (replace the ellipsis "..." with any additional arguments you pass to
! the script).
! Note that this problem does not pertain to the MS-Windows port of
! Emacs, since it doesn't use the preprocessor to generate Makefiles.
! *** src/Makefile and lib-src/Makefile are truncated--most of the file missing.
! *** Compiling wakeup, in lib-src, says it can't make wakeup.c.
! This can happen if configure uses GNU sed version 2.03. That version
! had a bug. GNU sed version 2.05 works properly.To solve the
! problem, install the current version of GNU Sed, then rerun Emacs's
! configure script.
! *** Compiling lib-src says there is no rule to make test-distrib.c.
! This results from a bug in a VERY old version of GNU Sed. To solve
! the problem, install the current version of GNU Sed, then rerun
! Emacs's configure script.
! *** 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 fails with a CreateProcess failure.
! Some versions of mingw32 make on some versions of Windows do not seem
! to detect the shell correctly. Try "make SHELL=cmd.exe", or if that
! fails, try running make from Cygwin bash instead.
! *** Building the MS-Windows port with Leim fails in the `leim' directory.
! The error message might be something like this:
! Converting d:/emacs-21.3/leim/CXTERM-DIC/4Corner.tit to quail-package...
! Invalid ENCODE: value in TIT dictionary
! NMAKE : fatal error U1077: '"../src/obj-spd/i386/emacs.exe"' : return code
! '0xffffffff'
! Stop.
! 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.
! *** 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 */
! --- 41,47 ----
! /*
! * If not debugging, assert does nothing.
! */
! ! #define assert(x) ((void)0)
! #else /* debugging enabled */
! ** Linking
! *** Building Emacs with a system compiler fails to link because of an
! undefined symbol such as __eprintf which does not appear in Emacs.
! 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
! Since the .o object files already exist, this will not recompile Emacs
! with GCC, but just restart by trying again to link temacs.
! *** AIX 1.3 ptf 0013: Link failure.
! There is a real duplicate definition of the function `_slibc_free' in
! the library /lib/libc_s.a (just do nm on it to verify). The
! workaround/fix is:
! cd /lib
! ar xv libc_s.a NLtmtime.o
! ar dv libc_s.a NLtmtime.o
! *** AIX 4.1.2: Linker error messages such as
! ld: 0711-212 SEVERE ERROR: Symbol .__quous, found in the global symbol table
! of archive /usr/lib/libIM.a, was not defined in archive member shr.o.
! This is a problem in libIM.a. You can work around it by executing
! these shell commands in the src subdirectory of the directory where
! you build Emacs:
! cp /usr/lib/libIM.a .
! chmod 664 libIM.a
! ranlib libIM.a
! Then change -lIM to ./libIM.a in the command to link temacs (in
! Makefile).
! *** Sun with acc: Link failure when using acc on a Sun.
! To use acc, you need additional options just before the libraries, such as
! /usr/lang/SC2.0.1/values-Xt.o -L/usr/lang/SC2.0.1/cg87 -L/usr/lang/SC2.0.1
! and you need to add -lansi just before -lc.
! The precise file names depend on the compiler version, so we
! cannot easily arrange to supply them.
! *** Linking says that the functions insque and remque are undefined.
! Change oldXMenu/Makefile by adding insque.o to the variable OBJS.
! *** `tparam' reported as a multiply-defined symbol when linking with ncurses.
! This problem results from an incompatible change in ncurses, in
! version 1.9.9e approximately. This version is unable to provide a
! definition of tparm without also defining tparam. This is also
! incompatible with Terminfo; as a result, the Emacs Terminfo support
! does not work with this version of ncurses.
! The fix is to install a newer version of ncurses, such as version 4.2.
! ** Dumping
! *** Linux: Segfault during `make bootstrap' under certain recent versions of
the Linux kernel.
! With certain recent Linux kernels (like the one of Redhat Fedora Core
! 1), the new "Exec-shield" functionality is enabled by default, which
! creates a different memory layout that breaks the emacs dumper.
! You can check the Exec-shield state like this:
! cat /proc/sys/kernel/exec-shield
! It returns 1 or 2 when Exec-shield is enabled, 0 otherwise. Please
! read your system documentation for more details on Exec-shield and
! associated commands.
! When Exec-shield is enabled, building Emacs will segfault during the
! execution of this command:
! temacs --batch --load loadup [dump|bootstrap]
! To work around this problem, it is necessary to temporarily disable
! Exec-shield while building Emacs, using the `setarch' command like
! this:
! setarch i386 ./configure <configure parameters>
! setarch i386 make <make parameters>
! *** Fatal signal in the command temacs -l loadup inc dump.
! This command is the final stage of building Emacs. It is run by the
! Makefile in the src subdirectory, or by build.com on VMS.
! It has been known to get fatal errors due to insufficient swapping
! space available on the machine.
! On 68000s, it has also happened because of bugs in the
! subroutine `alloca'. Verify that `alloca' works right, even
! for large blocks (many pages).
! *** test-distrib says that the distribution has been clobbered.
! *** or, temacs prints "Command key out of range 0-127".
! *** or, temacs runs and dumps emacs, but emacs totally fails to work.
! *** or, temacs gets errors dumping emacs.
! This can be because the .elc files have been garbled. Do not be
! fooled by the fact that most of a .elc file is text: these are
! binary files and can contain all 256 byte values.
! In particular `shar' cannot be used for transmitting GNU Emacs.
! It typically truncates "lines". What appear to be "lines" in
! a binary file can of course be of any length. Even once `shar'
! itself is made to work correctly, `sh' discards null characters
! when unpacking the shell archive.
! I have also seen character \177 changed into \377. I do not know
! what transfer means caused this problem. Various network
! file transfer programs are suspected of clobbering the high bit.
! If you have a copy of Emacs that has been damaged in its
! nonprinting characters, you can fix them:
! 1) Record the names of all the .elc files.
! 2) Delete all the .elc files.
! 3) Recompile alloc.c with a value of PURESIZE twice as large.
! (See puresize.h.) You might as well save the old alloc.o.
! 4) Remake emacs. It should work now.
! 5) Running emacs, do Meta-x byte-compile-file repeatedly
! to recreate all the .elc files that used to exist.
! You may need to increase the value of the variable
! max-lisp-eval-depth to succeed in running the compiler interpreted
! on certain .el files. 400 was sufficient as of last report.
! 6) Reinstall the old alloc.o (undoing changes to alloc.c if any)
! and remake temacs.
! 7) Remake emacs. It should work now, with valid .elc files.
! *** temacs prints "Pure Lisp storage exhausted".
! This means that the Lisp code loaded from the .elc and .el
! files during temacs -l loadup inc dump took up more
! space than was allocated.
! This could be caused by
! 1) adding code to the preloaded Lisp files
! 2) adding more preloaded files in loadup.el
! 3) having a site-init.el or site-load.el which loads files.
! Note that ANY site-init.el or site-load.el is nonstandard;
! if you have received Emacs from some other site
! and it contains a site-init.el or site-load.el file, consider
! deleting that file.
! 4) getting the wrong .el or .elc files
! (not from the directory you expected).
! 5) deleting some .elc files that are supposed to exist.
! This would cause the source files (.el files) to be
! loaded instead. They take up more room, so you lose.
! 6) a bug in the Emacs distribution which underestimates
! the space required.
! If the need for more space is legitimate, change the definition
! of PURESIZE in puresize.h.
! But in some of the cases listed above, this problem is a consequence
! of something else that is wrong. Be sure to check and fix the real
! problem.
! *** Linux: 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
! distribution:
! #if 0 /* This breaks things on PPC GNU/Linux except for Yellowdog,
! 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
! #endif
! #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.
! *** HPUX 10.20: Emacs crashes during dumping on the HPPA machine.
! This seems to be due to a GCC bug; it is fixed in GCC 2.8.1.
! ** Installation
! *** Installing Emacs gets an error running `install-info'.
! You need to install a recent version of Texinfo; that package
! supplies the `install-info' command.
! ** First execution
! *** Emacs binary is not in executable format, and cannot be run.
! This was reported to happen when Emacs is built in a directory mounted
! via NFS, for some combinations of NFS client and NFS server.
! Usually, the file `emacs' produced in these cases is full of
! 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.
! *** The dumped Emacs crashes when run, trying to write pure data.
! Two causes have been seen for such problems.
! 1) On a system where getpagesize is not a system call, it is defined
! as a macro. If the definition (in both unexec.c and malloc.c) is wrong,
! it can cause problems like this. You might be able to find the correct
! value in the man page for a.out (5).
! 2) Some systems allocate variables declared static among the
! initialized variables. Emacs makes all initialized variables in most
! of its files pure after dumping, but the variables declared static and
! not initialized are not supposed to be pure. On these systems you
! may need to add "#define static" to the m- or the s- file.
! * Emacs 19 problems
! ** Error messages `Wrong number of arguments: #<subr where-is-internal>, 5'.
! This typically results from having the powerkey library loaded.
! Powerkey was designed for Emacs 19.22. It is obsolete now because
! Emacs 19 now has this feature built in; and powerkey also calls
! where-is-internal in an obsolete way.
! So the fix is to arrange not to load powerkey.
! * Runtime problems on legacy systems
! This section covers bugs reported on very old hardware or software.
! If you are using hardware and an operating system shipped after 2000,
! it is unlikely you will see any of these.
! ** Ancient operating systems
! *** ISC Unix
! **** ISC: display-time causes kernel problems on ISC systems.
! Under Interactive Unix versions 3.0.1 and 4.0 (and probably other
! versions), display-time causes the loss of large numbers of STREVENT
! cells. Eventually the kernel's supply of these cells is exhausted.
! This makes emacs and the whole system run slow, and can make other
! processes die, in particular pcnfsd.
! Other emacs functions that communicate with remote processes may have
! the same problem. Display-time seems to be far the worst.
! The only known fix: Don't run display-time.
! *** SunOS
! **** Sun 4.0.x: M-x shell persistently reports "Process shell exited
abnormally with code 1".
! This happened on Suns as a result of what is said to be a bug in Sunos
! version 4.0.x. The only fix was to reboot the machine.
! **** SunOS4.1.1 and SunOS4.1.3: Mail is lost when sent to local aliases.
Many emacs mail user agents (VM and rmail, for instance) use the
sendmail.el library. This library can arrange for mail to be
***************
*** 2597,3365 ****
IDA sendmail on vixen.cso.uiuc.edu in /pub:
sendmail-5.67b+IDA-1.5.tar.gz
! * On AIX, you get this message when running Emacs:
!
! Could not load program emacs
! Symbol smtcheckinit in csh is undefined
! Error was: Exec format error
!
! or this one:
!
! Could not load program .emacs
! Symbol _system_con in csh is undefined
! Symbol _fp_trapsta in csh is undefined
! Error was: Exec format error
!
! These can happen when you try to run on AIX 3.2.5 a program that was
! compiled with 3.2.4. The fix is to recompile.
!
! * On AIX, you get this compiler error message:
!
! Processing include file ./XMenuInt.h
! 1501-106: (S) Include file X11/Xlib.h not found.
!
! This means your system was installed with only the X11 runtime i.d
! libraries. You have to find your sipo (bootable tape) and install
! X11Dev... with smit.
!
! * You "lose characters" after typing Compose Character key.
!
! This is because the Compose Character key is defined as the keysym
! Multi_key, and Emacs (seeing that) does the proper X11
! character-composition processing. If you don't want your Compose key
! to do that, you can redefine it with xmodmap.
!
! For example, here's one way to turn it into a Meta key:
!
! xmodmap -e "keysym Multi_key = Meta_L"
!
! If all users at your site of a particular keyboard prefer Meta to
! Compose, you can make the remapping happen automatically by adding the
! xmodmap command to the xdm setup script for that display.
!
! * C-z just refreshes the screen instead of suspending Emacs.
!
! You are probably using a shell that doesn't support job control, even
! though the system itself is capable of it. Either use a different shell,
! or set the variable `cannot-suspend' to a non-nil value.
!
! * Watch out for .emacs files and EMACSLOADPATH environment vars
!
! These control the actions of Emacs.
! ~/.emacs is your Emacs init file.
! EMACSLOADPATH overrides which directories the function
! "load" will search.
!
! If you observe strange problems, check for these and get rid
! of them, then try again.
!
! * After running emacs once, subsequent invocations crash.
!
! Some versions of SVR4 have a serious bug in the implementation of the
! mmap () system call in the kernel; this causes emacs to run correctly
! the first time, and then crash when run a second time.
!
! Contact your vendor and ask for the mmap bug fix; in the mean time,
! you may be able to work around the problem by adding a line to your
! operating system description file (whose name is reported by the
! configure script) that reads:
! #define SYSTEM_MALLOC
! This makes Emacs use memory less efficiently, but seems to work around
! the kernel bug.
!
! * Inability to send an Alt-modified key, when Emacs is communicating
! directly with an X server.
!
! If you have tried to bind an Alt-modified key as a command, and it
! does not work to type the command, the first thing you should check is
! whether the key is getting through to Emacs. To do this, type C-h c
! followed by the Alt-modified key. C-h c should say what kind of event
! it read. If it says it read an Alt-modified key, then make sure you
! have made the key binding correctly.
!
! If C-h c reports an event that doesn't have the Alt modifier, it may
! be because your X server has no key for the Alt modifier. The X
! server that comes from MIT does not set up the Alt modifier by
! default.
!
! If your keyboard has keys named Alt, you can enable them as follows:
!
! xmodmap -e 'add mod2 = Alt_L'
! xmodmap -e 'add mod2 = Alt_R'
!
! If the keyboard has just one key named Alt, then only one of those
! commands is needed. The modifier `mod2' is a reasonable choice if you
! are using an unmodified MIT version of X. Otherwise, choose any
! modifier bit not otherwise used.
!
! If your keyboard does not have keys named Alt, you can use some other
! keys. Use the keysym command in xmodmap to turn a function key (or
! some other 'spare' key) into Alt_L or into Alt_R, and then use the
! commands show above to make them modifier keys.
!
! Note that if you have Alt keys but no Meta keys, Emacs translates Alt
! into Meta. This is because of the great importance of Meta in Emacs.
!
! * `Pid xxx killed due to text modification or page I/O error'
!
! On HP/UX, you can get that error when the Emacs executable is on an NFS
! file system. HP/UX responds this way if it tries to swap in a page and
! does not get a response from the server within a timeout whose default
! value is just ten seconds.
!
! If this happens to you, extend the timeout period.
!
! * `expand-file-name' fails to work on any but the machine you dumped Emacs on.
!
! On Ultrix, if you use any of the functions which look up information
! in the passwd database before dumping Emacs (say, by using
! expand-file-name in site-init.el), then those functions will not work
! in the dumped Emacs on any host but the one Emacs was dumped on.
!
! The solution? Don't use expand-file-name in site-init.el, or in
! anything it loads. Yuck - some solution.
!
! I'm not sure why this happens; if you can find out exactly what is
! going on, and perhaps find a fix or a workaround, please let us know.
! Perhaps the YP functions cache some information, the cache is included
! in the dumped Emacs, and is then inaccurate on any other host.
! * On some variants of SVR4, Emacs does not work at all with X.
! Try defining BROKEN_FIONREAD in your config.h file. If this solves
! the problem, please send a bug report to tell us this is needed; be
! sure to say exactly what type of machine and system you are using.
! * Linking says that the functions insque and remque are undefined.
! Change oldXMenu/Makefile by adding insque.o to the variable OBJS.
! * Emacs fails to understand most Internet host names, even though
! the names work properly with other programs on the same system.
! * Emacs won't work with X-windows if the value of DISPLAY is HOSTNAME:0.
! * GNUs can't make contact with the specified host for nntp.
! This typically happens on Suns and other systems that use shared
! libraries. The cause is that the site has installed a version of the
! shared library which uses a name server--but has not installed a
! similar version of the unshared library which Emacs uses.
! The result is that most programs, using the shared library, work with
! the nameserver, but Emacs does not.
! The fix is to install an unshared library that corresponds to what you
! installed in the shared library, and then relink Emacs.
! On SunOS 4.1, simply define HAVE_RES_INIT.
! If you have already installed the name resolver in the file libresolv.a,
! then you need to compile Emacs to use that library. The easiest way to
! do this is to add to config.h a definition of LIBS_SYSTEM, LIBS_MACHINE
! or LIB_STANDARD which uses -lresolv. Watch out! If you redefine a macro
! that is already in use in your configuration to supply some other libraries,
! be careful not to lose the others.
! Thus, you could start by adding this to config.h:
! #define LIBS_SYSTEM -lresolv
! Then if this gives you an error for redefining a macro, and you see that
! the s- file defines LIBS_SYSTEM as -lfoo -lbar, you could change config.h
! again to say this:
! #define LIBS_SYSTEM -lresolv -lfoo -lbar
! * On a Sun running SunOS 4.1.1, you get this error message from GNU ld:
! /lib/libc.a(_Q_sub.o): Undefined symbol __Q_get_rp_rd referenced from
text segment
! The problem is in the Sun shared C library, not in GNU ld.
! The solution is to install Patch-ID# 100267-03 from Sun.
! * Self documentation messages are garbled.
! This means that the file `etc/DOC-...' doesn't properly correspond
! with the Emacs executable. Redumping Emacs and then installing the
! corresponding pair of files should fix the problem.
! * Trouble using ptys on AIX.
! People often install the pty devices on AIX incorrectly.
! Use `smit pty' to reinstall them properly.
! * Shell mode on HP/UX gives the message, "`tty`: Ambiguous".
! address@hidden says:
! The problem is that in your .cshrc you have something that tries to
! execute `tty`. If you are not running the shell on a real tty then
! tty will print "not a tty". Csh expects one word in some places,
! but tty is giving it back 3.
! The solution is to add a pair of quotes around `tty` to make it a single
! word:
! if (`tty` == "/dev/console")
! should be changed to:
! if ("`tty`" == "/dev/console")
! Even better, move things that set up terminal sections out of .cshrc
! and into .login.
! * Using X Windows, control-shift-leftbutton makes Emacs hang.
! Use the shell command `xset bc' to make the old X Menu package work.
! * Emacs running under X Windows does not handle mouse clicks.
! * `emacs -geometry 80x20' finds a file named `80x20'.
! One cause of such problems is having (setq term-file-prefix nil) in
! your .emacs file. Another cause is a bad value of EMACSLOADPATH in
! the environment.
! * Emacs gets error message from linker on Sun.
! If the error message says that a symbol such as `f68881_used' or
! `ffpa_used' or `start_float' is undefined, this probably indicates
! that you have compiled some libraries, such as the X libraries,
! with a floating point option other than the default.
! It's not terribly hard to make this work with small changes in
! crt0.c together with linking with Fcrt1.o, Wcrt1.o or Mcrt1.o.
! However, the easiest approach is to build Xlib with the default
! floating point option: -fsoft.
! * Emacs fails to get default settings from X Windows server.
! The X library in X11R4 has a bug; it interchanges the 2nd and 3rd
! arguments to XGetDefaults. Define the macro XBACKWARDS in config.h to
! tell Emacs to compensate for this.
! I don't believe there is any way Emacs can determine for itself
! whether this problem is present on a given system.
! * Keyboard input gets confused after a beep when using a DECserver
! as a concentrator.
! This problem seems to be a matter of configuring the DECserver to use
! 7 bit characters rather than 8 bit characters.
! * M-x shell persistently reports "Process shell exited abnormally with code
1".
! This happened on Suns as a result of what is said to be a bug in Sunos
! version 4.0.x. The only fix was to reboot the machine.
! * Programs running under terminal emulator do not recognize `emacs'
! terminal type.
! The cause of this is a shell startup file that sets the TERMCAP
! environment variable. The terminal emulator uses that variable to
! provide the information on the special terminal type that Emacs
! emulates.
! Rewrite your shell startup file so that it does not change TERMCAP
! in such a case. You could use the following conditional which sets
! it only if it is undefined.
! if ( ! ${?TERMCAP} ) setenv TERMCAP ~/my-termcap-file
! Or you could set TERMCAP only when you set TERM--which should not
! happen in a non-login shell.
! * X Windows doesn't work if DISPLAY uses a hostname.
! People have reported kernel bugs in certain systems that cause Emacs
! not to work with X Windows if DISPLAY is set using a host name. But
! the problem does not occur if DISPLAY is set to `unix:0.0'. I think
! the bug has to do with SIGIO or FIONREAD.
! You may be able to compensate for the bug by doing (set-input-mode nil nil).
! However, that has the disadvantage of turning off interrupts, so that
! you are unable to quit out of a Lisp program by typing C-g.
! The easy way to do this is to put
! (setq x-sigio-bug t)
! in your site-init.el file.
! * Problem with remote X server on Suns.
! On a Sun, running Emacs on one machine with the X server on another
! may not work if you have used the unshared system libraries. This
! is because the unshared libraries fail to use YP for host name lookup.
! As a result, the host name you specify may not be recognized.
! * Shell mode ignores interrupts on Apollo Domain
! You may find that M-x shell prints the following message:
! Warning: no access to tty; thus no job control in this shell...
! This can happen if there are not enough ptys on your system.
! Here is how to make more of them.
! % cd /dev
! % ls pty*
! # shows how many pty's you have. I had 8, named pty0 to pty7)
! % /etc/crpty 8
! # creates eight new pty's
! * Fatal signal in the command temacs -l loadup inc dump
! This command is the final stage of building Emacs. It is run by the
! Makefile in the src subdirectory, or by build.com on VMS.
! It has been known to get fatal errors due to insufficient swapping
! space available on the machine.
! On 68000's, it has also happened because of bugs in the
! subroutine `alloca'. Verify that `alloca' works right, even
! for large blocks (many pages).
! * test-distrib says that the distribution has been clobbered
! * or, temacs prints "Command key out of range 0-127"
! * or, temacs runs and dumps emacs, but emacs totally fails to work.
! * or, temacs gets errors dumping emacs
! This can be because the .elc files have been garbled. Do not be
! fooled by the fact that most of a .elc file is text: these are
! binary files and can contain all 256 byte values.
! In particular `shar' cannot be used for transmitting GNU Emacs.
! It typically truncates "lines". What appear to be "lines" in
! a binary file can of course be of any length. Even once `shar'
! itself is made to work correctly, `sh' discards null characters
! when unpacking the shell archive.
! I have also seen character \177 changed into \377. I do not know
! what transfer means caused this problem. Various network
! file transfer programs are suspected of clobbering the high bit.
! If you have a copy of Emacs that has been damaged in its
! nonprinting characters, you can fix them:
! 1) Record the names of all the .elc files.
! 2) Delete all the .elc files.
! 3) Recompile alloc.c with a value of PURESIZE twice as large.
! (See puresize.h.) You might as well save the old alloc.o.
! 4) Remake emacs. It should work now.
! 5) Running emacs, do Meta-x byte-compile-file repeatedly
! to recreate all the .elc files that used to exist.
! You may need to increase the value of the variable
! max-lisp-eval-depth to succeed in running the compiler interpreted
! on certain .el files. 400 was sufficient as of last report.
! 6) Reinstall the old alloc.o (undoing changes to alloc.c if any)
! and remake temacs.
! 7) Remake emacs. It should work now, with valid .elc files.
! * temacs prints "Pure Lisp storage exhausted"
! This means that the Lisp code loaded from the .elc and .el
! files during temacs -l loadup inc dump took up more
! space than was allocated.
! This could be caused by
! 1) adding code to the preloaded Lisp files
! 2) adding more preloaded files in loadup.el
! 3) having a site-init.el or site-load.el which loads files.
! Note that ANY site-init.el or site-load.el is nonstandard;
! if you have received Emacs from some other site
! and it contains a site-init.el or site-load.el file, consider
! deleting that file.
! 4) getting the wrong .el or .elc files
! (not from the directory you expected).
! 5) deleting some .elc files that are supposed to exist.
! This would cause the source files (.el files) to be
! loaded instead. They take up more room, so you lose.
! 6) a bug in the Emacs distribution which underestimates
! the space required.
! If the need for more space is legitimate, change the definition
! of PURESIZE in puresize.h.
! But in some of the cases listed above, this problem is a consequence
! of something else that is wrong. Be sure to check and fix the real
! problem.
! * Changes made to .el files do not take effect.
! You may have forgotten to recompile them into .elc files.
! Then the old .elc files will be loaded, and your changes
! will not be seen. To fix this, do M-x byte-recompile-directory
! and specify the directory that contains the Lisp files.
! Emacs should print a warning when loading a .elc file which is older
! than the corresponding .el file.
! * The dumped Emacs crashes when run, trying to write pure data.
! Two causes have been seen for such problems.
! 1) On a system where getpagesize is not a system call, it is defined
! as a macro. If the definition (in both unexec.c and malloc.c) is wrong,
! it can cause problems like this. You might be able to find the correct
! value in the man page for a.out (5).
! 2) Some systems allocate variables declared static among the
! initialized variables. Emacs makes all initialized variables in most
! of its files pure after dumping, but the variables declared static and
! not initialized are not supposed to be pure. On these systems you
! may need to add "#define static" to the m- or the s- file.
! * Compilation errors on VMS.
! You will get warnings when compiling on VMS because there are
! variable names longer than 32 (or whatever it is) characters.
! This is not an error. Ignore it.
! VAX C does not support #if defined(foo). Uses of this construct
! were removed, but some may have crept back in. They must be rewritten.
! There is a bug in the C compiler which fails to sign extend characters
! in conditional expressions. The bug is:
! char c = -1, d = 1;
! int i;
! i = d ? c : d;
! The result is i == 255; the fix is to typecast the char in the
! conditional expression as an (int). Known occurrences of such
! constructs in Emacs have been fixed.
! * rmail gets error getting new mail
! rmail gets new mail from /usr/spool/mail/$USER using a program
! called `movemail'. This program interlocks with /bin/mail using
! the protocol defined by /bin/mail.
! There are two different protocols in general use. One of them uses
! the `flock' system call. The other involves creating a lock file;
! `movemail' must be able to write in /usr/spool/mail in order to do
! this. You control which one is used by defining, or not defining,
! the macro MAIL_USE_FLOCK in config.h or the m- or s- file it includes.
! IF YOU DON'T USE THE FORM OF INTERLOCKING THAT IS NORMAL ON YOUR
! SYSTEM, YOU CAN LOSE MAIL!
! If your system uses the lock file protocol, and fascist restrictions
! prevent ordinary users from writing the lock files in /usr/spool/mail,
! you may need to make `movemail' setgid to a suitable group such as
! `mail'. You can use these commands (as root):
! chgrp mail movemail
! chmod 2755 movemail
! If your system uses the lock file protocol, and fascist restrictions
! prevent ordinary users from writing the lock files in /usr/spool/mail,
! you may need to make `movemail' setgid to a suitable group such as
! `mail'. To do this, use the following commands (as root) after doing the
! make install.
! chgrp mail movemail
! chmod 2755 movemail
! Installation normally copies movemail from the build directory to an
! installation directory which is usually under /usr/local/lib. The
! installed copy of movemail is usually in the directory
! /usr/local/lib/emacs/VERSION/TARGET. You must change the group and
! mode of the installed copy; changing the group and mode of the build
! directory copy is ineffective.
! * Emacs spontaneously displays "I-search: " at the bottom of the screen.
! This means that Control-S/Control-Q (XON/XOFF) "flow control" is being
! used. C-s/C-q flow control is bad for Emacs editors because it takes
! away C-s and C-q as user commands. Since editors do not output long
! streams of text without user commands, there is no need for a
! user-issuable "stop output" command in an editor; therefore, a
! properly designed flow control mechanism would transmit all possible
! input characters without interference. Designing such a mechanism is
! easy, for a person with at least half a brain.
! There are three possible reasons why flow control could be taking place:
! 1) Terminal has not been told to disable flow control
! 2) Insufficient padding for the terminal in use
! 3) Some sort of terminal concentrator or line switch is responsible
! 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
! 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.
! Once the terminal has been told "no flow control", you may find it
! needs more padding. The amount of padding Emacs sends is controlled
! by the termcap entry for the terminal in use, and by the output baud
! rate as known by the kernel. The shell command `stty' will print
! your output baud rate; `stty' with suitable arguments will set it if
! it is wrong. Setting to a higher speed causes increased padding. If
! the results are wrong for the correct speed, there is probably a
! problem in the termcap entry. You must speak to a local Unix wizard
! to fix this. Perhaps you are just using the wrong terminal type.
! For terminals that lack a "no flow control" mode, sometimes just
! giving lots of padding will prevent actual generation of flow control
! codes. You might as well try it.
! If you are really unlucky, your terminal is connected to the computer
! through a concentrator which sends XON/XOFF flow control to the
! computer, or it insists on sending flow control itself no matter how
! much padding you give it. Unless you can figure out how to turn flow
! control off on this concentrator (again, refer to your local wizard),
! you are screwed! You should have the terminal or concentrator
! replaced with a properly designed one. In the mean time, some drastic
! measures can make Emacs semi-work.
! You can make Emacs ignore C-s and C-q and let the operating system
! handle them. To do this on a per-session basis, just type M-x
! enable-flow-control RET. You will see a message that C-\ and C-^ are
! now translated to C-s and C-q. (Use the same command M-x
! enable-flow-control to turn *off* this special mode. It toggles flow
! control handling.)
! If C-\ and C-^ are inconvenient for you (for example, if one of them
! is the escape character of your terminal concentrator), you can choose
! other characters by setting the variables flow-control-c-s-replacement
! and flow-control-c-q-replacement. But choose carefully, since all
! other control characters are already used by emacs.
! IMPORTANT: if you type C-s by accident while flow control is enabled,
! Emacs output will freeze, and you will have to remember to type C-q in
! order to continue.
! If you work in an environment where a majority of terminals of a
! certain type are flow control hobbled, you can use the function
! `enable-flow-control-on' to turn on this flow control avoidance scheme
! automatically. Here is an example:
! (enable-flow-control-on "vt200" "vt300" "vt101" "vt131")
! If this isn't quite correct (e.g. you have a mixture of flow-control hobbled
! and good vt200 terminals), you can still run enable-flow-control
! manually.
! I have no intention of ever redesigning the Emacs command set for the
! assumption that terminals use C-s/C-q flow control. XON/XOFF flow
! control technique is a bad design, and terminals that need it are bad
! merchandise and should not be purchased. Now that X is becoming
! widespread, XON/XOFF seems to be on the way out. If you can get some
! use out of GNU Emacs on inferior terminals, more power to you, but I
! will not make Emacs worse for properly designed systems for the sake
! of inferior systems.
! * Control-S and Control-Q commands are ignored completely.
! For some reason, your system is using brain-damaged C-s/C-q flow
! control despite Emacs's attempts to turn it off. Perhaps your
! terminal is connected to the computer through a concentrator
! that wants to use flow control.
! You should first try to tell the concentrator not to use flow control.
! If you succeed in this, try making the terminal work without
! flow control, as described in the preceding section.
! If that line of approach is not successful, map some other characters
! into C-s and C-q using keyboard-translate-table. The example above
! shows how to do this with C-^ and C-\.
! * Control-S and Control-Q commands are ignored completely on a net connection.
! 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.
! 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.
! Some versions of tcsh will prevent even this from working. One way
! around this is to start another shell before starting rlogin, and
! issue the stty command to disable flow control from that shell.
! If none of these methods work, the best solution is to type
! M-x enable-flow-control at the beginning of your emacs session, or
! if you expect the problem to continue, add a line such as the
! following to your .emacs (on the host running rlogind):
! (enable-flow-control-on "vt200" "vt300" "vt101" "vt131")
! See the entry about spontaneous display of I-search (above) for more
! info.
! * Screen is updated wrong, but only on one kind of terminal.
! This could mean that the termcap entry you are using for that
! terminal is wrong, or it could mean that Emacs has a bug handing
! the combination of features specified for that terminal.
! The first step in tracking this down is to record what characters
! Emacs is sending to the terminal. Execute the Lisp expression
! (open-termscript "./emacs-script") to make Emacs write all
! terminal output into the file ~/emacs-script as well; then do
! what makes the screen update wrong, and look at the file
! and decode the characters using the manual for the terminal.
! There are several possibilities:
! 1) The characters sent are correct, according to the terminal manual.
! In this case, there is no obvious bug in Emacs, and most likely you
! need more padding, or possibly the terminal manual is wrong.
! 2) The characters sent are incorrect, due to an obscure aspect
! of the terminal behavior not described in an obvious way
! by termcap.
! This case is hard. It will be necessary to think of a way for
! Emacs to distinguish between terminals with this kind of behavior
! and other terminals that behave subtly differently but are
! classified the same by termcap; or else find an algorithm for
! Emacs to use that avoids the difference. Such changes must be
! tested on many kinds of terminals.
! 3) The termcap entry is wrong.
! See the file etc/TERMS for information on changes
! that are known to be needed in commonly used termcap entries
! for certain terminals.
! 4) The characters sent are incorrect, and clearly cannot be
! right for any terminal with the termcap entry you were using.
! This is unambiguously an Emacs bug, and can probably be fixed
! in termcap.c, tparam.c, term.c, scroll.c, cm.c or dispnew.c.
! * Output from Control-V is slow.
! On many bit-map terminals, scrolling operations are fairly slow.
! Often the termcap entry for the type of terminal in use fails
! to inform Emacs of this. The two lines at the bottom of the screen
! before a Control-V command are supposed to appear at the top after
! the Control-V command. If Emacs thinks scrolling the lines is fast,
! it will scroll them to the top of the screen.
! If scrolling is slow but Emacs thinks it is fast, the usual reason is
! that the termcap entry for the terminal you are using does not
! specify any padding time for the `al' and `dl' strings. Emacs
! concludes that these operations take only as much time as it takes to
! send the commands at whatever line speed you are using. You must
! fix the termcap entry to specify, for the `al' and `dl', as much
! time as the operations really take.
! Currently Emacs thinks in terms of serial lines which send characters
! at a fixed rate, so that any operation which takes time for the
! terminal to execute must also be padded. With bit-map terminals
! operated across networks, often the network provides some sort of
! flow control so that padding is never needed no matter how slow
! an operation is. You must still specify a padding time if you want
! Emacs to realize that the operation takes a long time. This will
! cause padding characters to be sent unnecessarily, but they do
! not really cost much. They will be transmitted while the scrolling
! is happening and then discarded quickly by the terminal.
! Most bit-map terminals provide commands for inserting or deleting
! multiple lines at once. Define the `AL' and `DL' strings in the
! termcap entry to say how to do these things, and you will have
! fast output without wasted padding characters. These strings should
! each contain a single %-spec saying how to send the number of lines
! to be scrolled. These %-specs are like those in the termcap
! `cm' string.
! You should also define the `IC' and `DC' strings if your terminal
! has a command to insert or delete multiple characters. These
! take the number of positions to insert or delete as an argument.
! A `cs' string to set the scrolling region will reduce the amount
! of motion you see on the screen when part of the screen is scrolled.
! * Your Delete key sends a Backspace to the terminal, using an AIXterm.
! The solution is to include in your .Xdefaults the lines:
! *aixterm.Translations: #override <Key>BackSpace: string(0x7f)
! aixterm*ttyModes: erase ^?
! This makes your Backspace key send DEL (ASCII 127).
! * You type Control-H (Backspace) expecting to delete characters.
! Put `stty dec' in your .login file and your problems will disappear
! after a day or two.
! The choice of Backspace for erasure was based on confusion, caused by
! the fact that backspacing causes erasure (later, when you type another
! character) on most display terminals. But it is a mistake. Deletion
! of text is not the same thing as backspacing followed by failure to
! overprint. I do not wish to propagate this confusion by conforming
! to it.
! For this reason, I believe `stty dec' is the right mode to use,
! and I have designed Emacs to go with that. If there were a thousand
! other control characters, I would define Control-h to delete as well;
! but there are not very many other control characters, and I think
! that providing the most mnemonic possible Help character is more
! important than adapting to people who don't use `stty dec'.
! If you are obstinate about confusing buggy overprinting with deletion,
! you can redefine Backspace in your .emacs file:
! (global-set-key "\b" 'delete-backward-char)
! You can probably access help-command via f1.
! * Editing files through RFS gives spurious "file has changed" warnings.
! It is possible that a change in Emacs 18.37 gets around this problem,
! but in case not, here is a description of how to fix the RFS bug that
! causes it.
! There was a serious pair of bugs in the handling of the fsync() system
! call in the RFS server.
! The first is that the fsync() call is handled as another name for the
! close() system call (!!). It appears that fsync() is not used by very
! many programs; Emacs version 18 does an fsync() before closing files
! to make sure that the bits are on the disk.
! This is fixed by the enclosed patch to the RFS server.
! The second, more serious problem, is that fsync() is treated as a
! non-blocking system call (i.e., it's implemented as a message that
! gets sent to the remote system without waiting for a reply). Fsync is
! a useful tool for building atomic file transactions. Implementing it
! as a non-blocking RPC call (when the local call blocks until the sync
! is done) is a bad idea; unfortunately, changing it will break the RFS
! protocol. No fix was supplied for this problem.
! (as always, your line numbers may vary)
! % rcsdiff -c -r1.2 serversyscall.c
! RCS file: RCS/serversyscall.c,v
! retrieving revision 1.2
! diff -c -r1.2 serversyscall.c
! *** /tmp/,RCSt1003677 Wed Jan 28 15:15:02 1987
! --- serversyscall.c Wed Jan 28 15:14:48 1987
! ***************
! *** 163,169 ****
! /*
! * No return sent for close or fsync!
! */
! ! if (syscall == RSYS_close || syscall == RSYS_fsync)
! proc->p_returnval = deallocate_fd(proc, msg->m_args[0]);
! else
! {
! --- 166,172 ----
! /*
! * No return sent for close or fsync!
! */
! ! if (syscall == RSYS_close)
! proc->p_returnval = deallocate_fd(proc, msg->m_args[0]);
! else
! {
! * Vax C compiler bugs affecting Emacs.
You may get one of these problems compiling Emacs:
--- 2873,3425 ----
IDA sendmail on vixen.cso.uiuc.edu in /pub:
sendmail-5.67b+IDA-1.5.tar.gz
! **** Sunos 5.3: Subprocesses remain, hanging but not zombies.
! A bug in Sunos 5.3 causes Emacs subprocesses to remain after Emacs
! exits. Sun patch # 101415-02 is part of the fix for this, but it only
! applies to ptys, and doesn't fix the problem with subprocesses
! communicating through pipes.
! **** Sunos 4: You get the error ld: Undefined symbol __lib_version.
! This is the result of using cc or gcc with the shared library meant
! for acc (the Sunpro compiler). Check your LD_LIBRARY_PATH and delete
! /usr/lang/SC2.0.1 or some similar directory.
! **** SunOS 4.1.3: Emacs unpredictably crashes in _yp_dobind_soft.
! This happens if you configure Emacs specifying just `sparc-sun-sunos4'
! on a system that is version 4.1.3. You must specify the precise
! version number (or let configure figure out the configuration, which
! it can do perfectly well for SunOS).
! **** Sunos 4.1.3: Emacs gets hung shortly after startup.
! We think this is due to a bug in Sunos. The word is that
! one of these Sunos patches fixes the bug:
! 100075-11 100224-06 100347-03 100482-05 100557-02 100623-03 100804-03
101080-01
! 100103-12 100249-09 100496-02 100564-07 100630-02 100891-10
101134-01
! 100170-09 100296-04 100377-09 100507-04 100567-04 100650-02 101070-01
101145-01
! 100173-10 100305-15 100383-06 100513-04 100570-05 100689-01 101071-03
101200-02
! 100178-09 100338-05 100421-03 100536-02 100584-05 100784-01 101072-01
101207-01
! We don't know which of these patches really matter. If you find out
! which ones, please inform address@hidden
! **** SunOS 4: Emacs processes keep going after you kill the X server
! (or log out, if you logged in using X).
! Someone reported that recompiling with GCC 2.7.0 fixed this problem.
! **** SunOS: You get linker errors
! ld: Undefined symbol
! _get_wmShellWidgetClass
! _get_applicationShellWidgetClass
! The fix to this is to install patch 100573 for OpenWindows 3.0
! or link libXmu statically.
! *** Apollo Domain
! **** Shell mode ignores interrupts on Apollo Domain.
! You may find that M-x shell prints the following message:
! Warning: no access to tty; thus no job control in this shell...
! This can happen if there are not enough ptys on your system.
! Here is how to make more of them.
! % cd /dev
! % ls pty*
! # shows how many pty's you have. I had 8, named pty0 to pty7)
! % /etc/crpty 8
! # creates eight new pty's
! *** Irix
! *** Irix 6.2: 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.
! *** 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.
! *** OPENSTEP
! **** OPENSTEP 4.2: Compiling syntax.c with gcc 2.7.2.1 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)
! {
! return(UPDATE_SYNTAX_TABLE_FORWARD(from));
! }/*update_syntax_table_forward*/
! Then replace all references to UPDATE_SYNTAX_TABLE_FORWARD in syntax.c
! with a call to the function update_syntax_table_forward.
! *** Solaris 2.x
! **** Strange results from format %d in a few cases, on a Sun.
! Sun compiler version SC3.0 has been found to miscompile part of
! editfns.c. The workaround is to compile with some other compiler such
! as GCC.
! **** On Solaris, Emacs dumps core if lisp-complete-symbol is called.
! If you compile Emacs with the -fast or -xO4 option with version 3.0.2
! of the Sun C compiler, Emacs dumps core when lisp-complete-symbol is
! called. The problem does not happen if you compile with GCC.
! **** On Solaris, Emacs crashes if you use (display-time).
! This can happen if you configure Emacs without specifying the precise
! version of Solaris that you are using.
! **** Solaris 2.3 and 2.4: Unpredictable segmentation faults.
! A user reported that this happened in 19.29 when it was compiled with
! the Sun compiler, but not when he recompiled with GCC 2.7.0.
! We do not know whether something in Emacs is partly to blame for this.
! **** Solaris 2.4: Emacs dumps core on startup.
! Bill Sebok says that the cause of this is Solaris 2.4 vendor patch
! 102303-05, which extends the Solaris linker to deal with the Solaris
! Common Desktop Environment's linking needs. You can fix the problem
! by removing this patch and installing patch 102049-02 instead.
! However, that linker version won't work with CDE.
! Solaris 2.5 comes with a linker that has this bug. It is reported that if
! you install all the latest patches (as of June 1996), the bug is fixed.
! We suspect the crucial patch is one of these, but we don't know
! for certain.
! 103093-03: [README] SunOS 5.5: kernel patch (2140557 bytes)
! 102832-01: [README] OpenWindows 3.5: Xview Jumbo Patch (4181613 bytes)
! 103242-04: [README] SunOS 5.5: linker patch (595363 bytes)
! (One user reports that the bug was fixed by those patches together
! with patches 102980-04, 103279-01, 103300-02, and 103468-01.)
! If you can determine which patch does fix the bug, please tell
! address@hidden
! Meanwhile, the GNU linker links Emacs properly on both Solaris 2.4 and
! Solaris 2.5.
! **** Solaris 2.4: Dired hangs and C-g does not work. Or Emacs hangs
! forever waiting for termination of a subprocess that is a zombie.
! address@hidden says the problem is in X11R6. Rebuild libX11.so
! after changing the file xc/config/cf/sunLib.tmpl. Change the lines
! #if ThreadedX
! #define SharedX11Reqs -lthread
! #endif
! to:
! #if OSMinorVersion < 4
! #if ThreadedX
! #define SharedX11Reqs -lthread
! #endif
! #endif
!
! Be sure also to edit x/config/cf/sun.cf so that OSMinorVersion is 4
! (as it should be for Solaris 2.4). The file has three definitions for
! OSMinorVersion: the first is for x86, the second for SPARC under
! Solaris, and the third for SunOS 4. Make sure to update the
! definition for your type of machine and system.
! Then do `make Everything' in the top directory of X11R6, to rebuild
! the makefiles and rebuild X. The X built this way work only on
! Solaris 2.4, not on 2.3.
! For multithreaded X to work it is necessary to install patch
! 101925-02 to fix problems in header files [2.4]. You need
! to reinstall gcc or re-run just-fixinc after installing that
! patch.
! However, Frank Rust <address@hidden> used a simpler solution:
! he changed
! #define ThreadedX YES
! to
! #define ThreadedX NO
! in sun.cf and did `make World' to rebuild X11R6. Removing all
! `-DXTHREAD*' flags and `-lthread' entries from lib/X11/Makefile and
! typing 'make install' in that directory also seemed to work.
! **** Solaris 2.x: GCC complains "64 bit integer types not supported".
! This suggests that GCC is not installed correctly. Most likely you
! are using GCC 2.7.2.3 (or earlier) on Solaris 2.6 (or later); this
! does not work without patching. To run GCC 2.7.2.3 on Solaris 2.6 or
! later, you must patch fixinc.svr4 and reinstall GCC from scratch as
! described in the Solaris FAQ
! <http://www.wins.uva.nl/pub/solaris/solaris2.html>. A better fix is
! to upgrade to GCC 2.8.1 or later.
! **** Solaris 2.7: Building Emacs with WorkShop Compilers 5.0 98/12/15
! 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.
! **** Solaris 2.x: 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 ftp://sunsolve.sun.com/pub/patches/;
! 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.
! *** 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.
! 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.
! address@hidden says (Feb 1998) that the Compose key does work
! if you link with the MIT X11 libraries instead of the Solaris X11
! libraries.
! *** Ultrix and Digital Unix
! **** Ultrix 4.2: `make install' fails on install-doc with `Error 141'.
! This happens on Ultrix 4.2 due to failure of a pipeline of tar
! commands. We don't know why they fail, but the bug seems not to be in
! Emacs. The workaround is to run the shell command in install-doc by
! hand.
! **** Digital Unix 4.0: Garbled display on non-X terminals when Emacs runs.
! 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.
! **** Ultrix: `expand-file-name' fails to work on any but the machine you
dumped Emacs on.
! On Ultrix, if you use any of the functions which look up information
! in the passwd database before dumping Emacs (say, by using
! expand-file-name in site-init.el), then those functions will not work
! in the dumped Emacs on any host but the one Emacs was dumped on.
! The solution? Don't use expand-file-name in site-init.el, or in
! anything it loads. Yuck - some solution.
! I'm not sure why this happens; if you can find out exactly what is
! going on, and perhaps find a fix or a workaround, please let us know.
! Perhaps the YP functions cache some information, the cache is included
! in the dumped Emacs, and is then inaccurate on any other host.
! *** SVr4
! **** SVr4: On some variants of SVR4, Emacs does not work at all with X.
! Try defining BROKEN_FIONREAD in your config.h file. If this solves
! the problem, please send a bug report to tell us this is needed; be
! sure to say exactly what type of machine and system you are using.
! **** SVr4: After running emacs once, subsequent invocations crash.
! Some versions of SVR4 have a serious bug in the implementation of the
! mmap () system call in the kernel; this causes emacs to run correctly
! the first time, and then crash when run a second time.
! Contact your vendor and ask for the mmap bug fix; in the mean time,
! you may be able to work around the problem by adding a line to your
! operating system description file (whose name is reported by the
! configure script) that reads:
! #define SYSTEM_MALLOC
! This makes Emacs use memory less efficiently, but seems to work around
! the kernel bug.
! *** Linux 1.x
! **** Linux 1.0-1.04: Typing C-c C-c in Shell mode kills your X server.
! This happens with Linux kernel 1.0 thru 1.04, approximately. The workaround
is
! to define SIGNALS_VIA_CHARACTERS in config.h and recompile Emacs.
! Newer Linux kernel versions don't have this problem.
! **** Linux 1.3: Output from subprocess (such as man or diff) is randomly
! truncated on GNU/Linux systems.
! This is due to a kernel bug which seems to be fixed in Linux version
! 1.3.75.
! ** MS-DOS
! *** When compiling with DJGPP on MS-Windows NT, "config msdos" fails.
! If the error message is "VDM has been already loaded", this is because
! Windows has a program called `redir.exe' that is incompatible with a
! program by the same name supplied with DJGPP, which is used by
! config.bat. To resolve this, move the DJGPP's `bin' subdirectory to
! the front of your PATH environment variable.
! *** When compiling with DJGPP on MS-Windows 95, Make fails for some targets
! like make-docfile.
! This can happen if long file name support (the setting of environment
! variable LFN) when Emacs distribution was unpacked and during
! compilation are not the same. See the MSDOG section of INSTALL for
! the explanation of how to avoid this problem.
! *** Emacs compiled with DJGPP complains at startup:
! "Wrong type of argument: internal-facep, msdos-menu-active-face"
! This can happen if you define an environment variable `TERM'. Emacs
! on MSDOS uses an internal terminal emulator which is disabled if the
! value of `TERM' is anything but the string "internal". Emacs then
! works as if its terminal were a dumb glass teletype that doesn't
! support faces. To work around this, arrange for `TERM' to be
! undefined when Emacs runs. The best way to do that is to add an
! [emacs] section to the DJGPP.ENV file which defines an empty value for
! `TERM'; this way, only Emacs gets the empty value, while the rest of
! your system works as before.
! *** MS-DOS: Emacs crashes at startup.
! Some users report that Emacs 19.29 requires dpmi memory management,
! and crashes on startup if the system does not have it. We don't yet
! know why this happens--perhaps these machines don't have enough real
! memory, or perhaps something is wrong in Emacs or the compiler.
! However, arranging to use dpmi support is a workaround.
! You can find out if you have a dpmi host by running go32 without
! arguments; it will tell you if it uses dpmi memory. For more
! information about dpmi memory, consult the djgpp FAQ. (djgpp
! is the GNU C compiler as packaged for MSDOS.)
! Compiling Emacs under MSDOS is extremely sensitive for proper memory
! configuration. If you experience problems during compilation, consider
! removing some or all memory resident programs (notably disk caches)
! and make sure that your memory managers are properly configured. See
! the djgpp faq for configuration hints.
! *** 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.
! *** MS-DOS+DJGPP: Problems on MS-DOG if DJGPP v2.0 is used to compile Emacs.
! There are two DJGPP library bugs which cause problems:
! * Running `shell-command' (or `compile', or `grep') you get
! `Searching for program: permission denied (EACCES), c:/command.com';
! * After you shell to DOS, Ctrl-Break kills Emacs.
! To work around these bugs, you can use two files in the msdos
! subdirectory: `is_exec.c' and `sigaction.c'. Compile them and link
! them into the Emacs executable `temacs'; then they will replace the
! incorrect library functions.
! *** MS-DOS: Emacs compiled for MSDOS cannot find some Lisp files, or other
! run-time support files, when long filename support is enabled.
! Usually, this problem will manifest itself when Emacs exits
! immediately after flashing the startup screen, because it cannot find
! the Lisp files it needs to load at startup. Redirect Emacs stdout
! and stderr to a file to see the error message printed by Emacs.
! Another manifestation of this problem is that Emacs is unable to load
! the support for editing program sources in languages such as C and
! Lisp.
! This can happen if the Emacs distribution was unzipped without LFN
! support, thus causing long filenames to be truncated to the first 6
! characters and a numeric tail that Windows 95 normally attaches to it.
! You should unzip the files again with a utility that supports long
! filenames (such as djtar from DJGPP or InfoZip's UnZip program
! compiled with DJGPP v2). The MSDOG section of the file INSTALL
! explains this issue in more detail.
! Another possible reason for such failures is that Emacs compiled for
! MSDOS is used on Windows NT, where long file names are not supported
! by this version of Emacs, but the distribution was unpacked by an
! unzip program that preserved the long file names instead of truncating
! them to DOS 8+3 limits. To be useful on NT, the MSDOS port of Emacs
! must be unzipped by a DOS utility, so that long file names are
! properly truncated.
! ** Archaic window managers and toolkits
! *** OpenLook: Under OpenLook, the Emacs window disappears when you type M-q.
! Some versions of the Open Look window manager interpret M-q as a quit
! command for whatever window you are typing at. If you want to use
! Emacs with that window manager, you should try to configure the window
! manager to use some other command. You can disable the
! shortcut keys entirely by adding this line to ~/.OWdefaults:
! OpenWindows.WindowMenuAccelerators: False
! **** twm: A position you specified in .Xdefaults is ignored, using twm.
! twm normally ignores "program-specified" positions.
! You can tell it to obey them with this command in your `.twmrc' file:
! UsePPosition "on" #allow clients to request a position
! ** Bugs related to old DEC hardware
! *** The Compose key on a DEC keyboard does not work as Meta key.
! This shell command should fix it:
! xmodmap -e 'keycode 0xb1 = Meta_L'
! *** Keyboard input gets confused after a beep when using a DECserver
! as a concentrator.
! This problem seems to be a matter of configuring the DECserver to use
! 7 bit characters rather than 8 bit characters.
! * Build problems on legacy systems
! ** BSD/386 1.0: --with-x-toolkit option configures wrong.
! This problem is due to bugs in the shell in version 1.0 of BSD/386.
! The workaround is to edit the configure file to use some other shell,
! such as bash.
! ** Digital Unix 4.0: Emacs 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.
! ** Digital Unix 4.0: Failure in unexec while dumping emacs.
! 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.
! ** Sunos 4.1.1: there are errors compiling sysdep.c.
! If you get errors such as
! "sysdep.c", line 2017: undefined structure or union
! "sysdep.c", line 2017: undefined structure or union
! "sysdep.c", line 2019: nodename undefined
! This can result from defining LD_LIBRARY_PATH. It is very tricky
! to use that environment variable with Emacs. The Emacs configure
! script links many test programs with the system libraries; you must
! make sure that the libraries available to configure are the same
! ones available when you build Emacs.
! ** SunOS 4.1.1: You get this error message from GNU ld:
! /lib/libc.a(_Q_sub.o): Undefined symbol __Q_get_rp_rd referenced from
text segment
! The problem is in the Sun shared C library, not in GNU ld.
! The solution is to install Patch-ID# 100267-03 from Sun.
! ** Sunos 4.1: Undefined symbols when linking using --with-x-toolkit.
! If you get the undefined symbols _atowc _wcslen, _iswprint, _iswspace,
! _iswcntrl, _wcscpy, and _wcsncpy, then you need to add -lXwchar after
! -lXaw in the command that links temacs.
! This problem seems to arise only when the international language
! extensions to X11R5 are installed.
! ** SunOS: Emacs gets error message from linker on Sun.
! If the error message says that a symbol such as `f68881_used' or
! `ffpa_used' or `start_float' is undefined, this probably indicates
! that you have compiled some libraries, such as the X libraries,
! with a floating point option other than the default.
! It's not terribly hard to make this work with small changes in
! crt0.c together with linking with Fcrt1.o, Wcrt1.o or Mcrt1.o.
! However, the easiest approach is to build Xlib with the default
! floating point option: -fsoft.
! ** SunOS: Undefined symbols _dlopen, _dlsym and/or _dlclose.
! If you see undefined symbols _dlopen, _dlsym, or _dlclose when linking
! with -lX11, compile and link against the file mit/util/misc/dlsym.c in
! the MIT X11R5 distribution. Alternatively, link temacs using shared
! libraries with s/sunos4shr.h. (This doesn't work if you use the X
! toolkit.)
! If you get the additional error that the linker could not find
! lib_version.o, try extracting it from X11/usr/lib/X11/libvim.a in
! X11R4, then use it in the link.
! ** VMS: Compilation errors on VMS.
! You will get warnings when compiling on VMS because there are
! variable names longer than 32 (or whatever it is) characters.
! This is not an error. Ignore it.
! VAX C does not support #if defined(foo). Uses of this construct
! were removed, but some may have crept back in. They must be rewritten.
! There is a bug in the C compiler which fails to sign extend characters
! in conditional expressions. The bug is:
! char c = -1, d = 1;
! int i;
! i = d ? c : d;
! The result is i == 255; the fix is to typecast the char in the
! conditional expression as an (int). Known occurrences of such
! constructs in Emacs have been fixed.
! ** Vax C compiler bugs affecting Emacs.
You may get one of these problems compiling Emacs:
***************
*** 3392,3413 ****
The `contents' field of a Lisp vector is an array of Lisp_Objects,
so you may see the problem happening with indexed references to that.
! * 68000 C compiler problems
Various 68000 compilers have different problems.
These are some that have been observed.
! ** Using value of assignment expression on union type loses.
This means that x = y = z; or foo (x = z); does not work
if x is of type Lisp_Object.
! ** "cannot reclaim" error.
This means that an expression is too complicated. You get the correct
line number in the error message. The code must be rewritten with
simpler expressions.
! ** XCONS, XSTRING, etc macros produce incorrect code.
If temacs fails to run at all, this may be the cause.
Compile this test program and look at the assembler code:
--- 3452,3473 ----
The `contents' field of a Lisp vector is an array of Lisp_Objects,
so you may see the problem happening with indexed references to that.
! ** 68000 C compiler problems
Various 68000 compilers have different problems.
These are some that have been observed.
! *** Using value of assignment expression on union type loses.
This means that x = y = z; or foo (x = z); does not work
if x is of type Lisp_Object.
! *** "cannot reclaim" error.
This means that an expression is too complicated. You get the correct
line number in the error message. The code must be rewritten with
simpler expressions.
! *** XCONS, XSTRING, etc macros produce incorrect code.
If temacs fails to run at all, this may be the cause.
Compile this test program and look at the assembler code:
***************
*** 3427,3433 ****
This problem will not happen if the m-...h file for your type
of machine defines NO_UNION_TYPE. That is the recommended setting now.
! * C compilers lose on returning unions
I hear that some C compilers cannot handle returning a union type.
Most of the functions in GNU Emacs return type Lisp_Object, which is
--- 3487,3493 ----
This problem will not happen if the m-...h file for your type
of machine defines NO_UNION_TYPE. That is the recommended setting now.
! *** C compilers lose on returning unions.
I hear that some C compilers cannot handle returning a union type.
Most of the functions in GNU Emacs return type Lisp_Object, which is
***************
*** 3437,3443 ****
of machine defines NO_UNION_TYPE.
! Copyright 1987,88,89,93,94,95,96,97,98,1999,2001,2002
Free Software Foundation, Inc.
Copying and redistribution of this file with or without modification
--- 3497,3503 ----
of machine defines NO_UNION_TYPE.
! Copyright 1987,88,89,93,94,95,96,97,98,1999,2001,2002,2004
Free Software Foundation, Inc.
Copying and redistribution of this file with or without modification