X-Git-Url: https://code.delx.au/gnu-emacs/blobdiff_plain/ec383c7d3be32a76fec796e5b185dde002c5feed..03da5d089a8ed035cec443a27259e7d21487a22e:/etc/PROBLEMS diff --git a/etc/PROBLEMS b/etc/PROBLEMS index 46b908d159..c5ce84ff1b 100644 --- a/etc/PROBLEMS +++ b/etc/PROBLEMS @@ -1,1433 +1,1160 @@ This file describes various problems that have been encountered -in compiling, installing and running GNU Emacs. +in compiling, installing and running GNU Emacs. Try doing Ctl-C Ctl-t +and browsing through the outline headers. -* Building Emacs with GCC 2.9x fails in the `src' directory. +* Emacs startup failures -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: +** Emacs fails to start, complaining about missing fonts. - CPP='gcc -E -traditional' ./configure ... +A typical error message might be something like -(replace the ellipsis "..." with any additional arguments you pass to -the script). + No fonts match `-*-fixed-medium-r-*--6-*-*-*-*-*-iso8859-1' -Note that this problem does not pertain to the MS-Windows port of -Emacs, since it doesn't use the preprocessor to generate Makefiles. +This happens because some X resource specifies a bad font family for +Emacs to use. The possible places where this specification might be +are: -* Building the MS-Windows port with Cygwin GCC can fail. + - in your ~/.Xdefaults file -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: + - client-side X resource file, such as ~/Emacs or + /usr/X11R6/lib/app-defaults/Emacs or + /usr/X11R6/lib/X11/app-defaults/Emacs - configure --with-gcc --cflags -mwin32 --cflags -D__MSVCRT__ +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. -* Building the MS-Windows port with Leim fails in the `leim' directory. +** Emacs aborts while starting up, only when run without X. -The error message might be something like this: +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. - Converting d:/emacs-21.1/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. +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. -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. +** Emacs does not start, complaining that it cannot open termcap database file. -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. +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. -* Emacs crashes when dumping itself on Mac PPC running Yellow Dog GNU/Linux. +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. -The crashes happen inside the function Fmake_symbol; here's a typical -C backtrace printed by GDB: +** Emacs 20 and later fails to load Lisp files at startup. - 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, +The typical error message might be like this: -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: + "Cannot open load file: fontset" - #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 */ +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.) -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. +Similarly, any other .el file for which there's no corresponding .elc +file could fail to load if it is compressed. -* JPEG images aren't displayed. +The solution is to uncompress all .el files which don't have a .elc +file. -This has been reported when Emacs is built with jpeg-6a library. -Upgrading to jpeg-6b solves the problem. +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: -* Building `ctags' for MS-Windows with the MinGW port of GCC fails. + emacs -q -batch -f list-load-path-shadows -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: +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. -*** 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 */ - +** Emacs prints an error at startup after upgrading from an earlier version. +An example of such an error is: -* Improving performance with slow X connections + x-complement-fontset-spec: "Wrong type argument: stringp, nil" -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 -configuring Emacs with option `--without-xim'. Configuring Emacs -without XIM does not affect the use of Emacs' own input methods, which -are part of the Leim package. +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: -If the connection is very slow, you might also want to consider -switching off scroll bars, menu bar, and tool bar. + emacs -q -batch -f list-load-path-shadows -* Getting a Meta key on the FreeBSD console +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. -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 +** With X11R6.4, public-patch-3, Emacs crashes at startup. - $ kbdcontrol -d >emacs.kbd +Reportedly this patch in X fixes the problem. -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 + --- 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 $ */ + /****************************************************************** - 105 meta meta meta meta meta meta meta meta O + 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; -to make the Windows key the Meta key. Load the new keymap with +* Crash bugs - $ kbdcontrol -l emacs.kbd +** Emacs crashes in x-popup-dialog. -* Emacs' xterm-mouse-mode doesn't work on the Gnome terminal. +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). -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 crashes when you use Bibtex mode. -* Emacs pauses for several seconds when changing the default font +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. -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. +Patches to raise the stack size limit automatically in `main' +(src/emacs.c) on various systems would be greatly appreciated. -A workaround for this is to add something like +** Error message `Symbol's value as variable is void: x', followed by +a segmentation fault and core dump. -emacs.waitForWM: false +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: -to your X resources. Alternatively, add `(wait-for-wm . nil)' to a -frame's parameter list, like this: + x FILENAME, N bytes, B tape blocks - (modify-frame-parameters nil '((wait-for-wm . nil))) +If your tar has this problem, install GNU tar--if you can manage to +untar it :-). -(this should go into your `.emacs' file). +** 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. -* Underlines appear at the wrong position. +** Emacs aborts inside the function `tparam1'. -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'. +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. -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. +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. -* 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. +** Emacs crashes when using the Exceed 6.0 X server. -* 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. +If you are using Exceed 6.1, upgrade to a later version. This was +reported to prevent the crashes. -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. +** Emacs crashes with SIGSEGV in XtInitializeWidgetClass. -* Clicking C-mouse-2 in the scroll bar doesn't split the window. +It crashes on X, but runs fine when called with option "-nw". -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. +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. -* Colors are not available on a tty or in xterm. +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. -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". +* General runtime problems -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). +** Lisp problems -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. +*** Changes made to .el files do not take effect. -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. +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. -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 should print a warning when loading a .elc file which is older +than the corresponding .el file. -* Emacs on a tty switches the cursor to large blinking block. +*** Watch out for .emacs files and EMACSLOADPATH environment vars. -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. +These control the actions of Emacs. +~/.emacs is your Emacs init file. +EMACSLOADPATH overrides which directories the function +"load" will search. -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. +If you observe strange problems, check for these and get rid +of them, then try again. -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. +*** Using epop3.el package causes Emacs to signal an error. -Alternatively, if you want a blinking underscore as your Emacs cursor, -change the "cvvis" capability to send the "\E[?25h\E[?0c" command. +The error message might be something like this: -* Problems in Emacs built with LessTif. + "Lisp nesting exceeds max-lisp-eval-depth" -The problems seem to depend on the version of LessTif and the Motif -emulation for which it is set up. +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. -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. +*** Buffers from `with-output-to-temp-buffer' get set up in Help mode. -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. +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. -* Known problems with the MS-Windows port of Emacs 21.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. -Emacs 21.1 built for MS-Windows doesn't support images and the tool bar. -Support for these will be added in future versions. +** Keyboard problems -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 menu items 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. +*** "Compose Character" key does strange things when used as a Meta key. -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. +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. -Some minor flickering still persists during mouse-tracking, although -not as severely as in 21.1. +You can use both functions (Meta, and Compose Character) if you assign +them to two different keys. -Emacs can sometimes abort when non-ASCII text, possibly with null -characters, is copied and pasted into a buffer. +*** C-z just refreshes the screen instead of suspending Emacs. -An inactive cursor remains in an active window after the Windows -Manager driven switch of the focus, until a key is pressed. +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. -Windows 2000 input methods are not recognized by Emacs (as of v21.1). -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.) +*** With M-x enable-flow-control, you need to type C-\ twice +to do incremental search--a single C-\ gets no response. -Multilingual text put into the Windows 2000 clipboard by Windows -applications cannot be safely pasted into Emacs (as of v21.1). This -is because Windows 2000 uses Unicode to represent multilingual text, -but Emacs does not yet support Unicode well enough to decode it. This -means that Emacs can only interchange non-ASCII text with other -Windows 2000 programs if the characters are in the system codepage. -Reportedly, a partial solution is to install the Mule-UCS package and -set selection-coding-system to utf-16-le-dos. +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 -* The `configure' script doesn't find the jpeg library. + set escape-character 17 -This can happen because the linker by default only looks for shared -libraries, but jpeg distribution by default doesn't build and doesn't -install a shared version of the library, `libjpeg.so'. One system -where this is known to happen is Compaq OSF/1 (`Tru64'), but it -probably isn't limited to that system. +in his .kermrc file, to make C-q the kermit escape character. -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. +** Mailers and other helper programs -(If you need the static version of the jpeg library as well, configure -libjpeg with both `--enable-static' and `--enable-shared' options.) +*** movemail compiled with POP support can't connect to the POP server. -* Building Emacs over NFS fails with ``Text file busy''. +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. -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. +*** RMAIL gets error getting new mail. -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. +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. -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'. +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! -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. +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): -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: + chgrp mail movemail + chmod 2755 movemail - marvin:/usr/local/src /usr/local/src ...options.omitted... +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. -The solution is to remove this line from `etc/fstab'. + chgrp mail movemail + chmod 2755 movemail -* Emacs binary is not in executable format, and cannot be run. +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. -This was reported to happen when Emacs is built in a directory mounted -via NFS. Usually, the file `emacs' produced in these cases is full of -binary null characters, and the `file' utility says: +*** rcs2log gives you the awk error message "too many fields". - emacs: ASCII text, with no line terminators +This is due to an arbitrary limit in certain versions of awk. +The solution is to use gawk (GNU awk). -We don't know what exactly causes this failure. A work-around is to -build Emacs in a directory on a local disk. +** Problems with hostname resolution -* Accented ISO-8859-1 characters are displayed as | or _. +*** 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. -Try other font set sizes (S-mouse-1). If the problem persists with -other sizes as well, your text is corrupted, probably through software -that is not 8-bit clean. If the problem goes away with another font -size, it's probably because some fonts pretend to be ISO-8859-1 fonts -when they are really ASCII fonts. In particular the schumacher-clean -fonts have this bug in some versions of X. +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. -To see what glyphs are included in a font, use `xfd', like this: +The result is that most programs, using the shared library, work with +the nameserver, but Emacs does not. - xfd -fn -schumacher-clean-medium-r-normal--12-120-75-75-c-60-iso8859-1 +The fix is to install an unshared library that corresponds to what you +installed in the shared library, and then relink Emacs. -If this shows only ASCII glyphs, the font is indeed the source of the -problem. +On SunOS 4.1, simply define HAVE_RES_INIT. -The solution is to remove the corresponding lines from the appropriate -`fonts.alias' file, then run `mkfontdir' in that directory, and then run -`xset fp rehash'. +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. -* Large file support is disabled on HP-UX. See the comments in -src/s/hpux10.h. +Thus, you could start by adding this to config.h: -* Crashes when displaying uncompressed GIFs with version -libungif-4.1.0 are resolved by using version libungif-4.1.0b1. +#define LIBS_SYSTEM -lresolv -* Font Lock displays portions of the bufefr in incorrect faces. +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: -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. +#define LIBS_SYSTEM -lresolv -lfoo -lbar -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.) +*** Emacs does not know your host's fully-qualified domain name. -Another alternative is to avoid a paren in column zero. For example, -in a Lisp string you could precede the paren with a backslash. +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. -* When running on KDE, colors or fonts are not as specified for Emacs, -or messed up. +If you cannot fix the configuration, you can set the Lisp variable +mail-host-address to the value you want. -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. +** NFS and RFS -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. +*** Emacs says it has saved a file, but the file does not actually +appear on disk. -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: +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. - Emacs.default.attributeForeground - Emacs.default.attributeBackground - Emacs*Foreground - Emacs*Background +*** 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. -* Interrupting Cygwin port of Bash from Emacs doesn't work. + There was a serious pair of bugs in the handling of the fsync() system + call in the RFS server. -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.) + 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. -* Accessing remote files with ange-ftp hangs the MS-Windows version of Emacs. + This is fixed by the enclosed patch to the RFS server. -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 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. -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' 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: + (as always, your line numbers may vary) - (setq ange-ftp-ftp-program-name "c:/windows/ftp.exe") + % 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 + { -If you want to stick with the Cygwin FTP client, you can work around -this problem by putting this in your `.emacs' file: +** PSGML - (setq ange-ftp-ftp-program-args '("-i" "-n" "-g" "-v" "--prompt" "") +*** 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. -* The latest released version of the W3 package doesn't run properly -with Emacs 21 and needs work. However, these problems are already -fixed in W3's CVS. The patch below is reported to make w3-4.0pre.46 -work. - -Some users report they are unable to byte-compile W3 with Emacs 21. -If the patches below don't help to resolve your problems, install the -CVS version of W3, which should be compatible with Emacs 21. - -diff -aur --new-file w3-4.0pre.46-orig/lisp/w3-display.el w3-4.0pre.46-new/lisp/w3-display.el ---- w3-4.0pre.46-orig/lisp/w3-display.el Sun Nov 14 22:00:12 1999 -+++ w3-4.0pre.46-new/lisp/w3-display.el Thu Dec 14 14:59:15 2000 -@@ -181,7 +181,8 @@ - (dispatch-event (next-command-event))) - (error nil)))) - (t -- (if (and (not (sit-for 0)) (input-pending-p)) -+ ;; modified for GNU Emacs 21 by bob@rattlesnake.com on 2000 Dec 14 -+ (if (and (not (sit-for 0)) nil) - (condition-case () - (progn - (setq w3-pause-keystroke -diff -aur --new-file w3-4.0pre.46-orig/lisp/w3-e21.el w3-4.0pre.46-new/lisp/w3-e21.el ---- w3-4.0pre.46-orig/lisp/w3-e21.el Thu Jan 1 00:00:00 1970 -+++ w3-4.0pre.46-new/lisp/w3-e21.el Thu Dec 14 14:54:58 2000 -@@ -0,0 +1,5 @@ -+;;; w3-e21.el --- ** required for GNU Emacs 21 ** -+;; Added by bob@rattlesnake.com on 2000 Dec 14 -+ -+(require 'w3-e19) -+(provide 'w3-e21) - -* 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'. +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. -* Compiling on AIX 4.3.x or 4.4 fails. +*** 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. -This could happen if you use /bin/c89 as youir 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'. +--- 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)) -* The PSGML package uses the obsolete variables -`before-change-function' and `after-change-function', which are no -longer used by Emacs. These changes to PSGML 1.2.2 fix that. - ---- psgml-edit.el 2001/03/03 00:23:31 1.1 -+++ psgml-edit.el 2001/03/03 00:24:22 -@@ -264,4 +264,4 @@ - ; inhibit-read-only -- (before-change-function nil) -- (after-change-function nil)) -+ (before-change-functions nil) -+ (after-change-functions nil)) - (setq selective-display t) -@@ -1544,3 +1544,3 @@ - (buffer-read-only nil) -- (before-change-function nil) -+ (before-change-functions nil) - (markup-index ; match-data index in tag regexp -@@ -1596,3 +1596,3 @@ - (defun sgml-expand-shortref-to-text (name) -- (let (before-change-function -+ (let (before-change-functions - (entity (sgml-lookup-entity name (sgml-dtd-entities sgml-dtd-info)))) -@@ -1613,3 +1613,3 @@ - (re-found nil) -- before-change-function) -+ before-change-functions) - (goto-char sgml-markup-start) -@@ -1646,3 +1646,3 @@ - (goto-char (sgml-element-end element)) -- (let ((before-change-function nil)) -+ (let ((before-change-functions nil)) - (sgml-normalize-content element only-one))) -Index: psgml-other.el ---- psgml-other.el 2001/03/03 00:23:42 1.1 -+++ psgml-other.el 2001/03/03 00:30:05 -@@ -32,2 +32,3 @@ - (require 'easymenu) -+(eval-when-compile (require 'cl)) - -@@ -61,4 +62,9 @@ - (let ((submenu -- (subseq entries 0 (min (length entries) -- sgml-max-menu-size)))) -+;;; (subseq entries 0 (min (length entries) -+;;; sgml-max-menu-size)) -+ (let ((new (copy-sequence entries))) -+ (setcdr (nthcdr (1- (min (length entries) -+ sgml-max-menu-size)) -+ new) nil) -+ new))) - (setq entries (nthcdr sgml-max-menu-size entries)) -@@ -113,9 +119,10 @@ - (let ((inhibit-read-only t) -- (after-change-function nil) ; obsolete variable -- (before-change-function nil) ; obsolete variable - (after-change-functions nil) -- (before-change-functions nil)) -+ (before-change-functions nil) -+ (modified (buffer-modified-p)) -+ (buffer-undo-list t) -+ deactivate-mark) - (put-text-property start end 'face face) -- (when (< start end) -- (put-text-property (1- end) end 'rear-nonsticky '(face))))) -+ (when (and (not modified) (buffer-modified-p)) -+ (set-buffer-modified-p nil)))) - (t -Index: psgml-parse.el ---- psgml-parse.el 2001/03/03 00:23:57 1.1 -+++ psgml-parse.el 2001/03/03 00:29:56 -@@ -40,2 +40,4 @@ - -+(eval-when-compile (require 'cl)) -+ - -@@ -2493,8 +2495,8 @@ - (setq sgml-scratch-buffer nil)) -- (when after-change-function ;*** -- (message "OOPS: after-change-function not NIL in scratch buffer %s: %s" -+ (when after-change-functions ;*** -+ (message "OOPS: after-change-functions not NIL in scratch buffer %s: %S" - (current-buffer) -- after-change-function) -- (setq before-change-function nil -- after-change-function nil)) -+ after-change-functions) -+ (setq before-change-functions nil -+ after-change-functions nil)) - (setq sgml-last-entity-buffer (current-buffer)) -@@ -2878,6 +2880,5 @@ - "Set initial state of parsing" -- (make-local-variable 'before-change-function) -- (setq before-change-function 'sgml-note-change-at) -- (make-local-variable 'after-change-function) -- (setq after-change-function 'sgml-set-face-after-change) -+ (set (make-local-variable 'before-change-functions) '(sgml-note-change-at)) -+ (set (make-local-variable 'after-change-functions) -+ '(sgml-set-face-after-change)) - (sgml-set-active-dtd-indicator (sgml-dtd-doctype dtd)) -@@ -3925,7 +3926,7 @@ - (sgml-need-dtd) -- (unless before-change-function -- (message "WARN: before-change-function has been lost, restoring (%s)" -+ (unless before-change-functions -+ (message "WARN: before-change-functions has been lost, restoring (%s)" - (current-buffer)) -- (setq before-change-function 'sgml-note-change-at) -- (setq after-change-function 'sgml-set-face-after-change)) -+ (setq before-change-functions '(sgml-note-change-at)) -+ (setq after-change-functions '(sgml-set-face-after-change))) - (sgml-with-parser-syntax-ro - -* TeX'ing the Calc manual fails. - -The following patches allow to build the Calc manual using texinfo.tex -from Emacs 19.34 distribution: - -*** calc-maint.e~0 Mon Dec 16 07:11:26 1996 ---- calc-maint.el Sun Dec 10 14:32:38 2000 -*************** -*** 308,314 **** - (insert "@tex\n" - "\\global\\advance\\appendixno2\n" - "\\gdef\\xref#1.{See ``#1.''}\n") -! (setq midpos (point)) - (insert "@end tex\n") - (insert-buffer-substring srcbuf sumpos endpos) - (insert "@bye\n") ---- 308,314 ---- - (insert "@tex\n" - "\\global\\advance\\appendixno2\n" - "\\gdef\\xref#1.{See ``#1.''}\n") -! (setq midpos (point-marker)) - (insert "@end tex\n") - (insert-buffer-substring srcbuf sumpos endpos) - (insert "@bye\n") -*** Makefile.~0 Mon Dec 16 07:11:24 1996 ---- Makefile Sun Dec 10 14:44:00 2000 -*************** -*** 98,106 **** - # Format the Calc manual as one printable volume using TeX. - tex: - $(REMOVE) calc.aux -! $(TEX) calc.texinfo - $(TEXINDEX) calc.[cfkptv]? -! $(TEX) calc.texinfo - $(PURGE) calc.cp calc.fn calc.pg calc.tp calc.vr - $(PURGE) calc.cps calc.fns calc.kys calc.pgs calc.tps calc.vrs - $(PURGE) calc.toc ---- 98,106 ---- - # Format the Calc manual as one printable volume using TeX. - tex: - $(REMOVE) calc.aux -! -$(TEX) calc.texinfo - $(TEXINDEX) calc.[cfkptv]? -! -$(TEX) calc.texinfo - $(PURGE) calc.cp calc.fn calc.pg calc.tp calc.vr - $(PURGE) calc.cps calc.fns calc.kys calc.pgs calc.tps calc.vrs - $(PURGE) calc.toc - -* Unicode characters are not unified with other Mule charsets. - -As of v21.1, Emacs charsets are still not unified. This means that -characters which belong to charsets such as Latin-2, Greek, Hebrew, -etc. and the same characters in the `mule-unicode-*' charsets are -different characters, as far as Emacs is concerned. For example, text -which includes Unicode characters from the Latin-2 locale cannot be -encoded by Emacs with ISO 8859-2 coding system; and if you yank Greek -text from a buffer whose buffer-file-coding-system is greek-iso-8bit -into a mule-unicode-0100-24ff buffer, Emacs won't be able to save that -buffer neither as ISO 8859-7 nor as UTF-8. - -To work around this, install some add-on package such as Mule-UCS. - -* Problems when using Emacs with UTF-8 locales - -Some systems, including recent versions of GNU/Linux, have terminals -or X11 subsystems that can be configured to provide Unicode/UTF-8 -input and display. Normally, such a system sets environment variables -such as LANG, LC_CTYPE, or LC_ALL to a string which ends with a -`.UTF-8'. For example, a system like this in a French locale might -use `fr_FR.UTF-8' as the value of LANG. - -Since Unicode support in Emacs, as of v21.1, is not yet complete (see -the previous entry in this file), UTF-8 support is not enabled by -default, even in UTF-8 locales. Thus, some Emacs features, such as -non-ASCII keyboard input, might appear to be broken in these locales. -To solve these problems, you need to turn on some options in your -`.emacs' file. Specifically, the following customizations should make -Emacs work correctly with UTF-8 input and text: - - (setq locale-coding-system 'utf-8) - (set-terminal-coding-system 'utf-8) - (set-keyboard-coding-system 'utf-8) - (set-selection-coding-system 'utf-8) - (prefer-coding-system 'utf-8) - -* The `oc-unicode' package doesn't work with Emacs 21. +** AUCTeX -This package tries to define more private charsets than there are free -slots now. If the built-in Unicode/UTF-8 support is insufficient, -e.g. if you need more CJK coverage, use the current Mule-UCS package. -Any files encoded as emacs-mule using oc-unicode won't be read -correctly by Emacs 21. +You should not be using a version older than 11.52 if you can avoid +it. -* Using epop3.el package causes Emacs to signal an error. +*** Emacs 21 freezes when visiting a TeX file with AUCTeX installed. -The error message might be something like this: +Emacs 21 needs version 10 or later of AUCTeX; upgrading should solve +these problems. - "Lisp nesting exceeds max-lisp-eval-depth" +*** No colors in AUCTeX with Emacs 21. -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. +Upgrade to AUC TeX version 10 or later, and make sure it is +byte-compiled with Emacs 21. -* ps-print commands fail to find prologue files ps-prin*.ps. +** PCL-CVS -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. +*** Lines are not updated or new lines are added in the buffer upon commit. -The solution is to upgrade X-Symbol to a later version. +When committing files located higher in the hierarchy than the examined +directory, some versions of the CVS program return an ambiguous message +from which PCL-CVS cannot extract the full location of the committed +files. As a result, the corresponding lines in the PCL-CVS buffer are +not updated with the new revision of these files, and new lines are +added to the top-level directory. -* 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. +This can happen with CVS versions 1.12.8 and 1.12.9. Upgrade to CVS +1.12.10 or newer to fix this problem. -Similar problems could prevent Emacs from building, since the build -process invokes Emacs several times. +** Miscellaneous problems -On many systems, it is possible to set LD_LIBRARY_PATH in your -environment to specify additional directories where shared libraries -can be found. +*** Self-documentation messages are garbled. -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. +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. -Please refer to the documentation of your dynamic linker for details. +*** Programs running under terminal emulator do not recognize `emacs' +terminal type. -* 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. +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. -* Compiling syntax.c with the OPENSTEP 4.2 compiler gcc 2.7.2.1 fails. +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. -The compiler was reported to crash while compiling syntax.c with the -following message: + if ( ! ${?TERMCAP} ) setenv TERMCAP ~/my-termcap-file - cc: Internal compiler error: program cc1obj got fatal signal 11 +Or you could set TERMCAP only when you set TERM--which should not +happen in a non-login shell. -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: +*** In Shell mode, you get a ^M at the end of every line. - static int update_syntax_table_forward(int from) - { - return(UPDATE_SYNTAX_TABLE_FORWARD(from)); - }/*update_syntax_table_forward*/ +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: -Then replace all references to UPDATE_SYNTAX_TABLE_FORWARD in syntax.c -with a call to the function update_syntax_table_forward. + if ($?EMACS) then + if ($EMACS == "t") then + unset edit + stty -icrnl -onlcr -echo susp ^Z + endif + endif -* Emacs fails to start, complaining about missing fonts. +*** Emacs startup on GNU/Linux systems (and possibly other systems) is slow. -A typical error message might be something like +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: - No fonts match `-*-fixed-medium-r-*--6-*-*-*-*-*-iso8859-1' +127.0.0.1 localhost +129.187.137.82 nuc04.t30.physik.tu-muenchen.de nuc04 -This happens because some X resource specifies a bad font family for -Emacs to use. The possible places where this specification might be -are: +The way to set this up may vary on non-GNU systems. - - in your ~/.Xdefaults file +*** Attempting to visit remote files via ange-ftp fails. - - client-side X resource file, such as ~/Emacs or - /usr/X11R6/lib/app-defaults/Emacs or - /usr/X11R6/lib/X11/app-defaults/Emacs +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 -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. + update-alternatives --config ftp -* Emacs 20 and later fails to load Lisp files at startup. +and then choose /usr/bin/netkit-ftp. -The typical error message might be like this: +*** JPEG images aren't displayed. - "Cannot open load file: fontset" +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. -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 -its loaded very early in the startup procedure.) +*** Dired is very slow. -Similarly, any other .el file for which there's no corresponding .elc -file could fail to load if it is compressed. +This could happen if invocation of the `df' program takes a long +time. Possible reasons for this include: -The solution is to uncompress all .el files which don't have a .elc -file. + - ClearCase mounted filesystems (VOBs) that sometimes make `df' + response time extremely slow (dozens of seconds); -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: + - slow automounters on some old versions of Unix; - emacs -q -batch -f list-load-path-shadows + - slow operation of some versions of `df'. -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. +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. -* Emacs prints an error at startup after upgrading from an earlier version. +*** Versions of the W3 package released before Emacs 21.1 don't run +under Emacs 21. This fixed in W3 version 4.0pre.47. -An example of such an error is: +*** The LDAP support rely on ldapsearch program from OpenLDAP version 2. - x-complement-fontset-spec: "Wrong type argument: stringp, nil" +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'. -This can be another symptom of stale *.elc files in your classpath. -The following command will print any duplicate Lisp files that are -present in load-path: +*** ps-print commands fail to find prologue files ps-prin*.ps. - emacs -q -batch -f list-load-path-shadows +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. -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. +The solution is to upgrade X-Symbol to a later version. -* Attempting to visit remote files via ange-ftp fails. +*** 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. -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 +Similar problems could prevent Emacs from building, since the build +process invokes Emacs several times. - update-alternatives --config ftp +On many systems, it is possible to set LD_LIBRARY_PATH in your +environment to specify additional directories where shared libraries +can be found. -and then choose /usr/bin/netkit-ftp. +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. -* Antivirus software interacts badly with the MS-Windows version of Emacs. +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. -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. +Please refer to the documentation of your dynamic linker for details. -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. +*** You request inverse video, and the first Emacs frame is in inverse +video, but later frames are not in inverse video. -* On Windows 95/98/ME, subprocesses do not terminate properly. +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. -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/. +*** When you run Ispell from Emacs, it reports a "misalignment" error. -* 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. +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. -* After upgrading to a newer version of Emacs, the Meta key stops working. +To see whether your Ispell program supports 8-bit characters, type +this at your shell's prompt: -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 + ispell -vv -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. +and look in the output for the string "NO8BIT". If Ispell says +"!NO8BIT (8BIT)", your speller supports 8-bit characters; otherwise it +does not. -The `xkeycaps' also shows a visual representation of the current -keyboard settings. It also allows to modify them. +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. -* On OSF/Dec Unix/Tru64/ under X locally or -remotely, M-SPC acts as a `compose' key with strange results. See -keyboard(5). +Another possible cause for "misalignment" error messages is that the +version of Ispell installed on your machine is old. Upgrade. -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' +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. -* Error "conflicting types for `initstate'" compiling with GCC on Irix 6. +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. -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. +* Runtime problems related to font handling -* Emacs dumps core on Solaris in function IMCheckWindow. +** Under X11, some characters appear as hollow boxes. -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. +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. -This bug was reported to Sun as +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. - Gtk apps dump core in ximlocal.so.2:IMCheckIMWindow() - Bug Reports: 4463537 +The intlfonts distribution includes a full spectrum of fonts that can +display all the characters Emacs supports. -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. +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. -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.) +** Under X11, some characters appear improperly aligned in their lines. -* On Solaris 7, Emacs gets a segmentation fault when starting up using X. +You may have bad X11 fonts; try installing the intlfonts distribution. -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. +** Certain fonts make each line take one pixel more than it "should". -* With X11R6.4, public-patch-3, Emacs crashes at startup. +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. -Reportedly this patch in X fixes the problem. +** Loading fonts is very slow. - --- 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 $ */ - /****************************************************************** +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". - 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; +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. -* Emacs crashes on Irix 6.5 on the SGI R10K, when compiled with GCC. - -This seems to be fixed in GCC 2.95. +** Font Lock displays portions of the buffer in incorrect faces. -* Emacs crashes in utmpname on Irix 5.3. +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. -This problem is fixed in Patch 3175 for Irix 5.3. -It is also fixed in Irix versions 6.2 and up. +Beginning with version 22.1, 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. -* The S-C-t key combination doesn't get passed to Emacs on X. +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.) -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. +Another alternative is to avoid a paren in column zero. For example, +in a Lisp string you could precede the paren with a backslash. -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. +** With certain fonts, when the cursor appears on a character, the +character doesn't appear--you get a solid box instead. -* On Solaris, CTRL-t is ignored by Emacs when you use -the fr.ISO-8859-15 locale (and maybe other related locales). +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. -You can fix this by editing the file: +** Characters are displayed as empty boxes or with wrong font under X. - /usr/openwin/lib/locale/iso8859-15/Compose - -Near the bottom there is a line that reads: +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. - Ctrl : "\276" threequarters +** Emacs pauses for several seconds when changing the default font. -that should read: +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. - Ctrl : "\276" threequarters +A workaround for this is to add something like -Note the lower case . Changing this line should make C-t work. +emacs.waitForWM: false -* Emacs on Digital Unix 4.0 fails to build, giving error message - Invalid dimension for the charset-ID 160 +to your X resources. Alternatively, add `(wait-for-wm . nil)' to a +frame's parameter list, like this: -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. + (modify-frame-parameters nil '((wait-for-wm . nil))) -* Buffers from `with-output-to-temp-buffer' get set up in Help mode. +(this should go into your `.emacs' file). -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. +** Underlines appear at the wrong position. -* Under X, C-v and/or other keys don't work. +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'. -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. +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 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". +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" +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 +* Internationalization problems -This problem manifests itself as an error message +** Characters from the mule-unicode charsets aren't displayed under X. - unexec: Bad address, writing data section to ... +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: -The user suspects that this happened because his X libraries -were built for an older system version, +mule-unicode-2500-33ff:-gnu-unifont-*-iso10646-1,\ +mule-unicode-e000-ffff:-gnu-unifont-*-iso10646-1,\ +mule-unicode-0100-24ff:-gnu-unifont-*-iso10646-1 - ./configure --x-includes=/usr/include --x-libraries=/usr/shlib +** The UTF-8/16/7 coding systems don't encode CJK (Far Eastern) characters. -made the problem go away. +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. -* No visible display on mips-sgi-irix6.2 when compiling with GCC 2.8.1. +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. -This problem went away after installing the latest IRIX patches -as of 8 Dec 1998. +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 _. -The same problem has been reported on Irix 6.3. +Try other font set sizes (S-mouse-1). If the problem persists with +other sizes as well, your text is corrupted, probably through software +that is not 8-bit clean. If the problem goes away with another font +size, it's probably because some fonts pretend to be ISO-8859-1 fonts +when they are really ASCII fonts. In particular the schumacher-clean +fonts have this bug in some versions of X. -* 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. +To see what glyphs are included in a font, use `xfd', like this: -* Emacs gives the error, Couldn't find per display information. + xfd -fn -schumacher-clean-medium-r-normal--12-120-75-75-c-60-iso8859-1 -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. +If this shows only ASCII glyphs, the font is indeed the source of the +problem. -We do not know of a way to prevent the problem. +The solution is to remove the corresponding lines from the appropriate +`fonts.alias' file, then run `mkfontdir' in that directory, and then run +`xset fp rehash'. -* Emacs makes HPUX 11.0 crash. +** The `oc-unicode' package doesn't work with Emacs 21. -This is a bug in HPUX; HPUX patch PHKL_16260 is said to fix it. +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. -* Emacs crashes during dumping on the HPPA machine (HPUX 10.20). +** After a while, Emacs slips into unibyte mode. -This seems to be due to a GCC bug; it is fixed in GCC 2.8.1. +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) -* 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. +* X runtime problems -* 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. +** X keyboard problems ---- 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)) +*** You "lose characters" after typing Compose Character key. -* Emacs 21 freezes when visiting a TeX file with AUC TeX installed. +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. -Emacs 21 needs version 10 or later of AUC TeX; upgrading should solve -these problems. +For example, here's one way to turn it into a Meta key: -* No colors in AUC TeX with Emacs 21. + xmodmap -e "keysym Multi_key = Meta_L" -Upgrade to AUC TeX version 10 or later, and make sure it is -byte-compiled with Emacs 21. +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. -* Running TeX from AUC TeX package with Emacs 20.3 gives a Lisp error -about a read-only tex output buffer. +*** Using X Windows, control-shift-leftbutton makes Emacs hang. -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. +Use the shell command `xset bc' to make the old X Menu package work. -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 +*** C-SPC fails to work on Fedora GNU/Linux. - Substituting nonexistent environment variable "" +Fedora Core 4 steals the C-SPC key by default for the `iiimx' program +which is the input method for some languages. It blocks Emacs users +from using the C-SPC key for `set-mark-command'. -This is not an Emacs bug; it is caused by something in SGI patch -003082 August 11, 1998. +One solutions is to remove the `space' from the `Iiimx' file +which can be found in the `/usr/lib/X11/app-defaults' directory. +However, that requires root access. -* After a while, Emacs slips into unibyte mode. +Another is to specify `Emacs*useXIM: false' in your X resources. -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) +Another is to build Emacs with the `--without-xim' configure option. -* Installing Emacs gets an error running `install-info'. +*** M-SPC seems to be ignored as input. -You need to install a recent version of Texinfo; that package -supplies the `install-info' command. +See if your X server is set up to use this as a command +for character composition. -* Emacs does not recognize the AltGr key, on HPUX. +*** The S-C-t key combination doesn't get passed to Emacs on X. -To fix this, set up a file ~/.dt/sessions/sessionetc with executable -rights, containing this text: +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. --------------------------------- -xmodmap 2> /dev/null - << EOF -keysym Alt_L = Meta_L -keysym Alt_R = Meta_R -EOF +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. -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. +*** Under X, C-v and/or other keys don't 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. +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. -* Emacs startup on GNU/Linux systems (and possibly other systems) is slow. +*** Clicking C-mouse-2 in the scroll bar doesn't split the window. -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: +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. -127.0.0.1 localhost -129.187.137.82 nuc04.t30.physik.tu-muenchen.de nuc04 +*** Inability to send an Alt-modified key, when Emacs is communicating +directly with an X server. -The way to set this up may vary on non-GNU systems. +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. -* Garbled display on non-X terminals when Emacs runs on Digital Unix 4.0. +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. -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. +If your keyboard has keys named Alt, you can enable them as follows: -* When you run Ispell from Emacs, it reports a "misalignment" error. + xmodmap -e 'add mod2 = Alt_L' + xmodmap -e 'add mod2 = Alt_R' -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. +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. -To see whether your Ispell program supports 8-bit characters, type -this at your shell's prompt: +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. - ispell -vv +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. -and look in the output for the string "NO8BIT". If Ispell says -"!NO8BIT (8BIT)", your speller supports 8-bit characters; otherwise it -does not. +** Window-manager and toolkit-related problems -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. +*** Gnome: Emacs' xterm-mouse-mode doesn't work on the Gnome terminal. -Another possible cause for "misalignment" error messages is that the -version of Ispell installed on your machine is old. Upgrade. +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. -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. +*** KDE: When running on KDE, colors or fonts are not as specified for Emacs, +or messed up. -* On Linux-based GNU systems using libc versions 5.4.19 through -5.4.22, Emacs crashes at startup with a segmentation fault. +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 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. +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". -* On Windows, you cannot use the right-hand ALT key and the left-hand -CTRL key together to type a Control-Meta character. +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: -This is a consequence of a misfeature beyond Emacs's control. + Emacs.default.attributeForeground + Emacs.default.attributeBackground + Emacs*Foreground + Emacs*Background -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. +*** KDE: Emacs hangs on KDE when a large portion of text is killed. -* Under some Windows X-servers, Emacs' display is incorrect +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 may print a message: -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. + Timed out waiting for property-notify event -This is known to occur under Exceed 6, and possibly earlier versions as -well. The problem lies in the X-server settings. +A workaround is to not use `klipper'. An upgrade to the `klipper' that +comes with KDE 3.3 or later also solves the problem. -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". +*** CDE: Frames may cover dialogs they created when using CDE. -Of this does not work, please inform bug-gnu-emacs@gnu.org. Then -please call support for your X-server and see if you can get a fix. -If you do, please send it to bug-gnu-emacs@gnu.org so we can list it -here. +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". -* On Solaris 2, Emacs dumps core when built with Motif. +*** 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. -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. +*** 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. -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. +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. -* On Solaris 2.6 and 7, the Compose key does not work. +*** Open Motif: Problems with file dialogs in Emacs built with Open Motif. -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. +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. -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. +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. -pen@lysator.liu.se says (Feb 1998) that the Compose key does work -if you link with the MIT X11 libraries instead of the Solaris X11 -libraries. +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 does not know your host's fully-qualified domain name. +*** LessTif: Problems in Emacs built with LessTif. -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. +The problems seem to depend on the version of LessTif and the Motif +emulation for which it is set up. -If you cannot fix the configuration, you can set the Lisp variable -mail-host-address to the value you want. +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. -* Error 12 (virtual memory exceeded) when dumping Emacs, on UnixWare 2.1 +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. -Paul Abrahams (abrahams@acm.org) 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. +*** Motif: The Motif version of Emacs paints the screen a solid color. -You can do this with the command `ulimit' (sh) or `limit' (csh). -But you have to be root to do it. +This has been observed to result from the following X resource: -According to Martin Sohnius, you can also retune this in the kernel: + Emacs*default.attributeFont: -*-courier-medium-r-*-*-*-140-*-*-*-*-iso8859-* - # /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 +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. -(He recommends you not change the stack limit, though.) -These changes take effect when you reboot. +** General X problems -* Redisplay using X11 is much slower than previous Emacs versions. +*** 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 @@ -1444,579 +1171,486 @@ 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. +*** Error messages about undefined colors on X. -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 messages might say something like this: -The intlfonts distribution includes a full spectrum of fonts that can -display all the characters Emacs supports. + Unable to load color "grey95" -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. +(typically, in the `*Messages*' buffer), or something like this: -* Under X11, some characters appear improperly aligned in their lines. + Error while displaying tooltip: (error Undefined color lightyellow) -You may have bad X11 fonts; try installing the intlfonts distribution. +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. -* Certain fonts make each line take one pixel more than it "should". +A solution is to exit the offending X programs before starting Emacs. -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. +*** Improving performance with slow X connections. -* You request inverse video, and the first Emacs frame is in inverse -video, but later frames are not in inverse video. +There are several ways to improve this performance, any subset of which can +be carried out at the same time: -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. +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. -* In FreeBSD 2.1.5, useless symbolic links remain in /tmp or other -directories that have the +t bit. +2) If the connection is very slow, you might also want to consider + switching off scroll bars, menu bar, and tool bar. -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. +3) Use ssh to forward the X connection, and enable compression on this + forwarded X connection (ssh -XC remotehostname emacs ...). -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. +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 -* When using M-x dbx with the SparcWorks debugger, the `up' and `down' -commands do not move the arrow in Emacs. +*** Emacs gives the error, Couldn't find per display information. -You can fix this by adding the following line to `~/.dbxinit': +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. - dbxenv output_short_file_name off +We do not know of a way to prevent the problem. -* Emacs says it has saved a file, but the file does not actually -appear on disk. +*** Emacs does not notice when you release the mouse. -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. +There are reports that this happened with (some) Microsoft mice and +that replacing the mouse made it stop. -* "Compose Character" key does strange things when used as a Meta key. +*** You can't select from submenus (in the X toolkit version). -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. +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). -You can use both functions (Meta, and Compose Character) if you assign -them to two different keys. +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. -* Emacs gets a segmentation fault at startup, on AIX4.2. +*** An error message such as `X protocol error: BadMatch (invalid +parameter attributes) on protocol request 93'. -If you are using IBM's xlc compiler, compile emacs.c -without optimization; that should avoid the problem. +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.) -* movemail compiled with POP support can't connect to the POP server. +The fix is to correct your X resources. -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. +*** Slow startup on X11R6 with X windows. -* Emacs crashes in x-popup-dialog. +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. -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). +One way to avoid this problem is to eliminate the type-1 fonts from +your font path, like this: -* Emacs crashes when you use Bibtex mode. + xset -fp /usr/X11R6/lib/X11/fonts/Type1/ -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. +*** Pull-down menus appear in the wrong place, in the toolkit version of Emacs. -Patches to raise the stack size limit automatically in `main' -(src/emacs.c) on various systems would be greatly appreciated. +An X resource of this form can cause the problem: -* Emacs crashes with SIGBUS or SIGSEGV on HPUX 9 after you delete a frame. + Emacs*geometry: 80x55+0+0 -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. +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. -* Emacs crashes with SIGBUS or SIGSEGV on Solaris after you delete a frame. +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. -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: +*** Emacs running under X Windows does not handle mouse clicks. +*** `emacs -geometry 80x20' finds a file named `80x20'. -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 +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. -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: +*** Emacs fails to get default settings from X Windows server. -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 +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. -* Problems running Perl under Emacs on Windows NT/95. +I don't believe there is any way Emacs can determine for itself +whether this problem is present on a given system. -`perl -de 0' just hangs when executed in an Emacs subshell. -The fault lies with Perl (indirectly with Windows NT/95). +*** X Windows doesn't work if DISPLAY uses a hostname. -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. +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. -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. +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. -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. +The easy way to do this is to put -A workaround is to modify perldb.pl to use STDIN/STDOUT instead of CON. + (setq x-sigio-bug t) -For Perl 4: +in your site-init.el file. - *** 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"; - } +* Runtime problems on character termunals - --- 68,74 ---- - $rcfile=".perldb"; - } - else { - ! $console = ""; - $rcfile="perldb.ini"; - } +** 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. - 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 { +There are three possible reasons why flow control could be taking place: -* Problems running DOS programs on Windows NT versions earlier than 3.51. + 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 -Some DOS programs, such as pkzip/pkunzip will not work at all, while -others will only work if their stdin is redirected from a file or NUL. +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. -When a DOS program does not work, a new process is actually created, but -hangs. It cannot be interrupted from Emacs, and might need to be killed -by an external program if Emacs is hung waiting for the process to -finish. If Emacs is not waiting for it, you should be able to kill the -instance of ntvdm that is running the hung process from Emacs, if you -can find out the process id. +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. -It is safe to run most DOS programs using call-process (eg. M-! and -M-|) since stdin is then redirected from a file, but not with -start-process since that redirects stdin to a pipe. Also, running DOS -programs in a shell buffer prompt without redirecting stdin does not -work. +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. -* Problems on MS-DOG if DJGPP v2.0 is used to compile Emacs: +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. -There are two DJGPP library bugs which cause problems: +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.) - * 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. +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. -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. +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. -* When compiling with DJGPP on Windows NT, "config msdos" fails. +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: -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. +(enable-flow-control-on "vt200" "vt300" "vt101" "vt131") -* When compiling with DJGPP on Windows 95, Make fails for some targets -like make-docfile. +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. -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. +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. -* Emacs compiled for MSDOS cannot find some Lisp files, or other -run-time support files, when long filename support is enabled. +** Control-S and Control-Q commands are ignored completely. -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. +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. -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. +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. -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. +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-\. -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. +** Screen is updated wrong, but only on one kind of terminal. -* Emacs compiled with DJGPP complains at startup: +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. - "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. +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: -* On Windows 95, Alt-f6 does not get through to Emacs. +1) The characters sent are correct, according to the terminal manual. -This character seems to be trapped by the kernel in Windows 95. -You can enter M-f6 by typing ESC f6. +In this case, there is no obvious bug in Emacs, and most likely you +need more padding, or possibly the terminal manual is wrong. -* Typing Alt-Shift has strange effects on Windows 95. +2) The characters sent are incorrect, due to an obscure aspect + of the terminal behavior not described in an obvious way + by termcap. -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. +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. -* `tparam' reported as a multiply-defined symbol when linking with ncurses. +3) The termcap entry is wrong. -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. +See the file etc/TERMS for information on changes +that are known to be needed in commonly used termcap entries +for certain terminals. -The fix is to install a newer version of ncurses, such as version 4.2. +4) The characters sent are incorrect, and clearly cannot be + right for any terminal with the termcap entry you were using. -* Strange results from format %d in a few cases, on a Sun. +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. -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. +** Control-S and Control-Q commands are ignored completely on a net connection. -* Output from subprocess (such as man or diff) is randomly truncated -on GNU/Linux systems. +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. -This is due to a kernel bug which seems to be fixed in Linux version -1.3.75. +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. -* Error messages `internal facep []' happen on GNU/Linux systems. +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. -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. +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): -Using the old library version is a workaround. +(enable-flow-control-on "vt200" "vt300" "vt101" "vt131") -* On Solaris, Emacs crashes if you use (display-time). +See the entry about spontaneous display of I-search (above) for more +info. -This can happen if you configure Emacs without specifying the precise -version of Solaris that you are using. +** Output from Control-V is slow. -* Emacs dumps core on startup, on Solaris. +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. -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. +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. -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. +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. - 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) +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. -(One user reports that the bug was fixed by those patches together -with patches 102980-04, 103279-01, 103300-02, and 103468-01.) +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. -If you can determine which patch does fix the bug, please tell -bug-gnu-emacs@gnu.org. +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. -Meanwhile, the GNU linker links Emacs properly on both Solaris 2.4 and -Solaris 2.5. +** You type Control-H (Backspace) expecting to delete characters. -* Emacs dumps core if lisp-complete-symbol is called, on Solaris. +Put `stty dec' in your .login file and your problems will disappear +after a day or two. -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. +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. -* "Cannot find callback list" messages from dialog boxes on HPUX, in -Emacs built with Motif. +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'. -This problem resulted from a bug in GCC 2.4.5. Newer GCC versions -such as 2.7.0 fix the problem. +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. -* On Irix 6.0, make tries (and fails) to build a program named unexelfsgi +** Colors are not available on a tty or in xterm. -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. +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". -Compiler fixes in Irix 6.0.1 should eliminate this problem. +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). -* "out of virtual swap space" on Irix 5.3 +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. -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'. +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. -You can increase swap space by changing the file /etc/fstab. Adding a -line like this: +Beginning with version 22.1, 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. -/usr/swap/swap.more swap swap pri=3 0 0 +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'. -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. +* Runtime problems specific to individual Unix variants -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. +** GNU/Linux -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. +*** GNU/Linux: Process output is corrupted. -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/. +There is a bug in Linux kernel 2.6.10 PTYs that can cause emacs to +read corrupted process output. -* With certain fonts, when the cursor appears on a character, the -character doesn't appear--you get a solid box instead. +*** GNU/Linux: Remote access to CVS with SSH causes file corruption. -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. +If you access a remote CVS repository via SSH, files may be corrupted +due to bad interaction between CVS, SSH, and libc. -* On SunOS 4.1.3, Emacs unpredictably crashes in _yp_dobind_soft. +To fix the problem, save the following script into a file, make it +executable, and set CVS_RSH environment variable to the file name of +the script: -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). +#!/bin/bash +exec 2> >(exec cat >&2 2>/dev/null) +exec ssh "$@" -* On SunOS 4, Emacs processes keep going after you kill the X server -(or log out, if you logged in using X). +*** 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. -Someone reported that recompiling with GCC 2.7.0 fixed this problem. +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 AIX 4, some programs fail when run in a Shell buffer -with an error message like No terminfo entry for "unknown". +*** GNU/Linux: After upgrading to a newer version of Emacs, +the Meta key stops working. -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. +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. -* On SunOS, you get linker errors - ld: Undefined symbol - _get_wmShellWidgetClass - _get_applicationShellWidgetClass +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: -The fix to this is to install patch 100573 for OpenWindows 3.0 -or link libXmu statically. + xmodmap -pk | egrep -i "meta|alt" -* 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. +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: -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: + xkbprint 0:0 /tmp/k.ps - 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 -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. +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 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. +The `xkeycaps' also shows a visual representation of the current +keyboard settings. It also allows to modify them. -* Slow startup on Linux-based GNU systems. +*** 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'. @@ -2028,7 +1662,7 @@ networked and non-networked machines. Here is how to fix the configuration. It requires being root. -** Networked Case +**** 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 @@ -2039,7 +1673,7 @@ exist. The first line in the `/etc/hosts' file should look like this Also make sure that the `/etc/host.conf' files contains the following lines: - order hosts, bind + order hosts, bind multi on Any changes, permanent and temporary, to the host name should be @@ -2047,7 +1681,7 @@ 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 +**** 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 @@ -2055,725 +1689,742 @@ 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. +*** GNU/Linux: Emacs on a tty switches the cursor to large blinking block. -casper@fwi.uva.nl says the problem is in X11R6. Rebuild libX11.so -after changing the file xc/config/cf/sunLib.tmpl. Change the lines +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. - #if ThreadedX - #define SharedX11Reqs -lthread - #endif +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: +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. - #if OSMinorVersion < 4 - #if ThreadedX - #define SharedX11Reqs -lthread - #endif - #endif +Alternatively, if you want a blinking underscore as your Emacs cursor, +change the "cvvis" capability to send the "\E[?25h\E[?0c" command. -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. +*** GNU/Linux: Error messages `internal facep []' happen on GNU/Linux systems. -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. +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. -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. +Using the old library version is a workaround. -However, Frank Rust 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. +** Mac OS X -* With M-x enable-flow-control, you need to type C-\ twice - to do incremental search--a single C-\ gets no response. +*** Mac OS X (Carbon): Environment Variables from dotfiles are ignored. -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 +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. - set escape-character 17 +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. -in his .kermrc file, to make C-q the kermit escape character. +*** Mac OS X (Carbon): Process output truncated when using ptys. -* The Motif version of Emacs paints the screen a solid color. +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. -This has been observed to result from the following X resource: +** FreeBSD - Emacs*default.attributeFont: -*-courier-medium-r-*-*-*-140-*-*-*-*-iso8859-* +*** FreeBSD 2.1.5: useless symbolic links remain in /tmp or other +directories that have the +t bit. -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. +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. -* Emacs gets hung shortly after startup, on Sunos 4.1.3. +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. -We think this is due to a bug in Sunos. The word is that -one of these Sunos patches fixes the bug: +*** FreeBSD: Getting a Meta key on the console. -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 +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 -We don't know which of these patches really matter. If you find out -which ones, please inform bug-gnu-emacs@gnu.org. + $ kbdcontrol -d >emacs.kbd -* Emacs aborts while starting up, only when run without X. +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 -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. + 105 meta meta meta meta meta meta meta meta O -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. +to make the Windows key the Meta key. Load the new keymap with -* On Solaris 2.x, GCC complains "64 bit integer types not supported" + $ kbdcontrol -l emacs.kbd -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 -. A better fix is -to upgrade to GCC 2.8.1 or later. +** HP-UX -* The Compose key on a DEC keyboard does not work as Meta key. +*** HP/UX : Shell mode gives the message, "`tty`: Ambiguous". -This shell command should fix it: +christos@theory.tn.cornell.edu says: - xmodmap -e 'keycode 0xb1 = Meta_L' +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. -* Regular expressions matching bugs on SCO systems. +The solution is to add a pair of quotes around `tty` to make it a single +word: -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. +if (`tty` == "/dev/console") -* On Sunos 4, you get the error ld: Undefined symbol __lib_version. +should be changed to: -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. +if ("`tty`" == "/dev/console") -* You can't select from submenus (in the X toolkit version). +Even better, move things that set up terminal sections out of .cshrc +and into .login. -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). +*** HP/UX: `Pid xxx killed due to text modification or page I/O error'. -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. +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. -* Unusable default font on SCO 3.2v4. +If this happens to you, extend the timeout period. -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 +*** HP/UX: The right Alt key works wrong on German HP keyboards (and perhaps +other non-English HP keyboards too). -The best solution is to create an application-specific resource file for -Emacs, /usr/lib/X11/sco/startup/Emacs, with the following contents: +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. - Emacs*Font: -*-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-1 - Emacs*Background: white - Emacs*Foreground: black + xmodmap 2> /dev/null - << EOF + keysym Alt_L = Meta_L + keysym Alt_R = Meta_R + EOF -(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. + xmodmap - << EOF + clear mod1 + keysym Mode_switch = NoSymbol + add mod1 = Meta_L + keysym Meta_R = Mode_switch + add mod2 = Mode_switch + EOF -These resource files are not normally shared across a network of SCO -machines; you must create the file on each machine individually. +*** HP/UX: "Cannot find callback list" messages from dialog boxes in +Emacs built with Motif. -* rcs2log gives you the awk error message "too many fields". +This problem resulted from a bug in GCC 2.4.5. Newer GCC versions +such as 2.7.0 fix the problem. -This is due to an arbitrary limit in certain versions of awk. -The solution is to use gawk (GNU awk). +*** HP/UX: Emacs does not recognize the AltGr key. -* Emacs is slow using X11R5 on HP/UX. +To fix this, set up a file ~/.dt/sessions/sessionetc with executable +rights, containing this text: -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. +-------------------------------- +xmodmap 2> /dev/null - << EOF +keysym Alt_L = Meta_L +keysym Alt_R = Meta_R +EOF -* Loading fonts is very slow. +xmodmap - << EOF +clear mod1 +keysym Mode_switch = NoSymbol +add mod1 = Meta_L +keysym Meta_R = Mode_switch +add mod2 = Mode_switch +EOF +-------------------------------- -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". +*** HP/UX 11.0: Emacs makes HP/UX 11.0 crash. -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. +This is a bug in HPUX; HPUX patch PHKL_16260 is said to fix it. -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. +** AIX -* On AIX 3.2.4, releasing Ctrl/Act key has no effect, if Shift is down. +*** AIX: Trouble using ptys. -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. +People often install the pty devices on AIX incorrectly. +Use `smit pty' to reinstall them properly. -You can get out of this "control-locked" state by pressing and -releasing Ctrl/Act while not pressing or holding any other keys. +*** AIXterm: Your Delete key sends a Backspace to the terminal. -* display-time causes kernel problems on ISC systems. +The solution is to include in your .Xdefaults the lines: -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. + *aixterm.Translations: #override BackSpace: string(0x7f) + aixterm*ttyModes: erase ^? -The only known fix: Don't run display-time. +This makes your Backspace key send DEL (ASCII 127). -* On Solaris, C-x doesn't get through to Emacs when you use the console. +*** 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'. -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. +*** AIX 4.3.x or 4.4: Compiling fails. -* Error message `Symbol's value as variable is void: x', followed by - segmentation fault and core dump. +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'. -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: +*** AIX 4: Some programs fail when run in a Shell buffer +with an error message like No terminfo entry for "unknown". - x FILENAME, N bytes, B tape blocks +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. -If your tar has this problem, install GNU tar--if you can manage to -untar it :-). +** Solaris -* Link failure when using acc on a Sun. +We list bugs in current versions here. Solaris 2.x and 4.x are covered in the +section on legacy systems. -To use acc, you need additional options just before the libraries, such as +*** On Solaris, C-x doesn't get through to Emacs when you use the console. - /usr/lang/SC2.0.1/values-Xt.o -L/usr/lang/SC2.0.1/cg87 -L/usr/lang/SC2.0.1 +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. -and you need to add -lansi just before -lc. +*** Problem with remote X server on Suns. -The precise file names depend on the compiler version, so we -cannot easily arrange to supply them. +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. -* Link failure on IBM AIX 1.3 ptf 0013. +*** Solaris 2,6: Emacs crashes with SIGBUS or SIGSEGV on Solaris after you delete a frame. -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: +We suspect that this is a 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: - cd /lib - ar xv libc_s.a NLtmtime.o - ar dv libc_s.a NLtmtime.o +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 -* Undefined symbols _dlopen, _dlsym and/or _dlclose on a Sun. +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: -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.) +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 -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. +*** Solaris 7 or 8: Emacs reports a BadAtom error (from X) -* Error messages `Wrong number of arguments: #, 5' +This happens when Emacs was built on some other version of Solaris. +Rebuild it on Solaris 8. -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. +*** When using M-x dbx with the SparcWorks debugger, the `up' and `down' +commands do not move the arrow in Emacs. -So the fix is to arrange not to load powerkey. +You can fix this by adding the following line to `~/.dbxinit': -* In Shell mode, you get a ^M at the end of every line. + dbxenv output_short_file_name off -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: +*** On Solaris, CTRL-t is ignored by Emacs when you use +the fr.ISO-8859-15 locale (and maybe other related locales). - if ($?EMACS) then - if ($EMACS == "t") then - unset edit - stty -icrnl -onlcr -echo susp ^Z - endif - endif +You can fix this by editing the file: -* An error message such as `X protocol error: BadMatch (invalid -parameter attributes) on protocol request 93'. + /usr/openwin/lib/locale/iso8859-15/Compose -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.) +Near the bottom there is a line that reads: -The fix is to correct your X resources. + Ctrl : "\276" threequarters -* Undefined symbols when linking on Sunos 4.1 using --with-x-toolkit. +that should read: -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. + Ctrl : "\276" threequarters -This problem seems to arise only when the international language -extensions to X11R5 are installed. +Note the lower case . Changing this line should make C-t work. -* Typing C-c C-c in Shell mode kills your X server. +** Irix -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. +*** Irix 6.5: Emacs crashes on the SGI R10K, when compiled with GCC. -* src/Makefile and lib-src/Makefile are truncated--most of the file missing. +This seems to be fixed in GCC 2.95. -This can happen if configure uses GNU sed version 2.03. That version -had a bug. GNU sed version 2.05 works properly. +*** Irix: Trouble using ptys, or running out of ptys. -* Slow startup on X11R6 with X windows. +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. -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. +* Runtime problems specific to MS-Windows -One way to avoid this problem is to eliminate the type-1 fonts from -your font path, like this: +** Emacs exits with "X protocol error" when run with an X server for MS-Windows. - xset -fp /usr/X11R6/lib/X11/fonts/Type1/ +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. -* Pull-down menus appear in the wrong place, in the toolkit version of Emacs. +** Known problems with the MS-Windows port of Emacs 21.2. -An X resource of this form can cause the problem: +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. - Emacs*geometry: 80x55+0+0 +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. -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. +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. -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. +Some minor flickering still persists during mouse-tracking, although +not as severely as in 21.1. -* --with-x-toolkit version crashes when used with shared libraries. +Emacs can sometimes abort when non-ASCII text, possibly with null +characters, is copied and pasted into a buffer. -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. +An inactive cursor remains in an active window after the Windows +Manager driven switch of the focus, until a key is pressed. -* `make install' fails on install-doc with `Error 141'. +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.) -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. +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. -* --with-x-toolkit option configures wrong on BSD/386. +** Typing Alt-Shift has strange effects on MS-Windows. -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. +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. -* Subprocesses remain, hanging but not zombies, on Sunos 5.3. +** Interrupting Cygwin port of Bash from Emacs doesn't work. -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. +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.) -* Mail is lost when sent to local aliases. +** Accessing remote files with ange-ftp hangs the MS-Windows version of Emacs. -Many emacs mail user agents (VM and rmail, for instance) use the -sendmail.el library. This library can arrange for mail to be -delivered by passing messages to the /usr/lib/sendmail (usually) -program . In doing so, it passes the '-t' flag to sendmail, which -means that the name of the recipient of the message is not on the -command line and, therefore, that sendmail must parse the message to -obtain the destination address. - -There is a bug in the SunOS4.1.1 and SunOS4.1.3 versions of sendmail. -In short, when given the -t flag, the SunOS sendmail won't recognize -non-local (i.e. NIS) aliases. It has been reported that the Solaris -2.x versions of sendmail do not have this bug. For those using SunOS -4.1, the best fix is to install sendmail V8 or IDA sendmail (which -have other advantages over the regular sendmail as well). At the time -of this writing, these official versions are available: - - Sendmail V8 on ftp.cs.berkeley.edu in /ucb/sendmail: - sendmail.8.6.9.base.tar.Z (the base system source & documentation) - sendmail.8.6.9.cf.tar.Z (configuration files) - sendmail.8.6.9.misc.tar.Z (miscellaneous support programs) - sendmail.8.6.9.xdoc.tar.Z (extended documentation, with postscript) +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. - IDA sendmail on vixen.cso.uiuc.edu in /pub: - sendmail-5.67b+IDA-1.5.tar.gz +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: -* On AIX, you get this message when running Emacs: + (setq ange-ftp-ftp-program-name "c:/windows/ftp.exe") - Could not load program emacs - Symbol smtcheckinit in csh is undefined - Error was: Exec format error +If you want to stick with the Cygwin FTP client, you can work around +this problem by putting this in your `.emacs' file: -or this one: + (setq ange-ftp-ftp-program-args '("-i" "-n" "-g" "-v" "--prompt" "") - Could not load program .emacs - Symbol _system_con in csh is undefined - Symbol _fp_trapsta in csh is undefined - Error was: Exec format error +** lpr commands don't work on MS-Windows with some cheap printers. -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. +This problem may also strike other platforms, but the solution is +likely to be a global one, and not Emacs specific. -* On AIX, you get this compiler error message: +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): - Processing include file ./XMenuInt.h - 1501-106: (S) Include file X11/Xlib.h not found. +(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 -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. +** Antivirus software interacts badly with the MS-Windows version of Emacs. -* You "lose characters" after typing Compose Character key. +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. -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. +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. -For example, here's one way to turn it into a Meta key: +** Pressing the mouse button on MS-Windows does not give a mouse-2 event. - xmodmap -e "keysym Multi_key = Meta_L" +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. -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. +** Scrolling the mouse wheel on MS-Windows always scrolls the top window. -* C-z just refreshes the screen instead of suspending Emacs. +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. -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. +** 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. -* Watch out for .emacs files and EMACSLOADPATH environment vars +** On MS-Windows, you cannot use the right-hand ALT key and the left-hand +CTRL key together to type a Control-Meta character. -These control the actions of Emacs. -~/.emacs is your Emacs init file. -EMACSLOADPATH overrides which directories the function -"load" will search. +This is a consequence of a misfeature beyond Emacs's control. -If you observe strange problems, check for these and get rid -of them, then try again. +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. -* After running emacs once, subsequent invocations crash. +** Under some X-servers running on MS-Windows, Emacs' display is incorrect. -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. +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. -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. +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. -* Inability to send an Alt-modified key, when Emacs is communicating -directly with an X server. +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". -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. +Of this does not work, please inform bug-gnu-emacs@gnu.org. Then +please call support for your X-server and see if you can get a fix. +If you do, please send it to bug-gnu-emacs@gnu.org so we can list it +here. -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. +* Build-time problems -If your keyboard has keys named Alt, you can enable them as follows: +** Configuration - xmodmap -e 'add mod2 = Alt_L' - xmodmap -e 'add mod2 = Alt_R' +*** The `configure' script doesn't find the jpeg library. -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. +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 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. +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. -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. +** Compilation -* `Pid xxx killed due to text modification or page I/O error' +*** Building Emacs over NFS fails with ``Text file busy''. -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. +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. -If this happens to you, extend the timeout period. +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. -* `expand-file-name' fails to work on any but the machine you dumped Emacs on. +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'. -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. +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. -The solution? Don't use expand-file-name in site-init.el, or in -anything it loads. Yuck - some solution. +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: -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. + marvin:/usr/local/src /usr/local/src ...options.omitted... -* On some variants of SVR4, Emacs does not work at all with X. +The solution is to remove this line from `etc/fstab'. -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. +*** Building Emacs with GCC 2.9x fails in the `src' directory. -* Linking says that the functions insque and remque are undefined. +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). -Change oldXMenu/Makefile by adding insque.o to the variable OBJS. +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: -* 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. + CPP='gcc -E -traditional' ./configure ... -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. +(replace the ellipsis "..." with any additional arguments you pass to +the script). -The result is that most programs, using the shared library, work with -the nameserver, but Emacs does not. +Note that this problem does not pertain to the MS-Windows port of +Emacs, since it doesn't use the preprocessor to generate Makefiles. -The fix is to install an unshared library that corresponds to what you -installed in the shared library, and then relink Emacs. +*** 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. -On SunOS 4.1, simply define HAVE_RES_INIT. +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. -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. +*** Compiling lib-src says there is no rule to make test-distrib.c. -Thus, you could start by adding this to config.h: +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. -#define LIBS_SYSTEM -lresolv +*** Building the MS-Windows port with Cygwin GCC can fail. -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: +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: -#define LIBS_SYSTEM -lresolv -lfoo -lbar + configure --with-gcc --cflags -mwin32 --cflags -D__MSVCRT__ -* On a Sun running SunOS 4.1.1, you get this error message from GNU ld: +*** Building the MS-Windows port fails with a CreateProcess failure. - /lib/libc.a(_Q_sub.o): Undefined symbol __Q_get_rp_rd referenced from text segment +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. -The problem is in the Sun shared C library, not in GNU ld. +*** Building the MS-Windows port with Leim fails in the `leim' directory. -The solution is to install Patch-ID# 100267-03 from Sun. +The error message might be something like this: -* Self documentation messages are garbled. + 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 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. +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. -* Trouble using ptys on AIX. +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. -People often install the pty devices on AIX incorrectly. -Use `smit pty' to reinstall them properly. +*** Building `ctags' for MS-Windows with the MinGW port of GCC fails. -* Shell mode on HP/UX gives the message, "`tty`: Ambiguous". +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: -christos@theory.tn.cornell.edu says: +*** 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); -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. + #else /* debugging enabled */ -The solution is to add a pair of quotes around `tty` to make it a single -word: +--- 41,47 ---- + /* + * If not debugging, assert does nothing. + */ +! #define assert(x) ((void)0) -if (`tty` == "/dev/console") + #else /* debugging enabled */ -should be changed to: -if ("`tty`" == "/dev/console") +** Linking -Even better, move things that set up terminal sections out of .cshrc -and into .login. +*** Building Emacs with a system compiler fails to link because of an +undefined symbol such as __eprintf which does not appear in Emacs. -* Using X Windows, control-shift-leftbutton makes Emacs hang. +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. -Use the shell command `xset bc' to make the old X Menu package work. +A solution is to link with GCC, like this: -* Emacs running under X Windows does not handle mouse clicks. -* `emacs -geometry 80x20' finds a file named `80x20'. + make CC=gcc -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. +Since the .o object files already exist, this will not recompile Emacs +with GCC, but just restart by trying again to link temacs. -* Emacs gets error message from linker on Sun. +*** AIX 1.3 ptf 0013: Link failure. -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. +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: -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. + cd /lib + ar xv libc_s.a NLtmtime.o + ar dv libc_s.a NLtmtime.o -* Emacs fails to get default settings from X Windows server. +*** 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. -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. +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: -I don't believe there is any way Emacs can determine for itself -whether this problem is present on a given system. + cp /usr/lib/libIM.a . + chmod 664 libIM.a + ranlib libIM.a -* Keyboard input gets confused after a beep when using a DECserver - as a concentrator. +Then change -lIM to ./libIM.a in the command to link temacs (in +Makefile). -This problem seems to be a matter of configuring the DECserver to use -7 bit characters rather than 8 bit characters. +*** Sun with acc: Link failure when using acc on a Sun. -* M-x shell persistently reports "Process shell exited abnormally with code 1". +To use acc, you need additional options just before the libraries, such as -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. + /usr/lang/SC2.0.1/values-Xt.o -L/usr/lang/SC2.0.1/cg87 -L/usr/lang/SC2.0.1 -* Programs running under terminal emulator do not recognize `emacs' - terminal type. +and you need to add -lansi just before -lc. -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. +The precise file names depend on the compiler version, so we +cannot easily arrange to supply them. -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. +*** Linking says that the functions insque and remque are undefined. - if ( ! ${?TERMCAP} ) setenv TERMCAP ~/my-termcap-file +Change oldXMenu/Makefile by adding insque.o to the variable OBJS. -Or you could set TERMCAP only when you set TERM--which should not -happen in a non-login shell. +*** `tparam' reported as a multiply-defined symbol when linking with ncurses. -* X Windows doesn't work if DISPLAY uses a hostname. +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. -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. +The fix is to install a newer version of ncurses, such as version 4.2. -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. +** Dumping -The easy way to do this is to put +*** Linux: Segfault during `make bootstrap' under certain recent versions of the Linux kernel. - (setq x-sigio-bug t) +With certain recent Linux kernels (like the one of Redhat Fedora Core +1 and newer), the new "Exec-shield" functionality is enabled by default, which +creates a different memory layout that breaks the emacs dumper. Emacs tries +to handle this at build time, but if the workaround used fails, these +instructions can be useful. +The work-around explained here is not enough on Fedora Core 4 (and possible +newer). Read the next item. -in your site-init.el file. +Configure can overcome the problem of exec-shield if the architecture is +x86 and the program setarch is present. On other architectures no +workaround is known. -* Problem with remote X server on Suns. +You can check the Exec-shield state like this: -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. + cat /proc/sys/kernel/exec-shield -* Shell mode ignores interrupts on Apollo Domain +It returns non-zero when Exec-shield is enabled, 0 otherwise. Please +read your system documentation for more details on Exec-shield and +associated commands. Exec-shield can be turned off with this command: -You may find that M-x shell prints the following message: + echo "0" > /proc/sys/kernel/exec-shield - Warning: no access to tty; thus no job control in this shell... +When Exec-shield is enabled, building Emacs will segfault during the +execution of this command: -This can happen if there are not enough ptys on your system. -Here is how to make more of them. + ./temacs --batch --load loadup [dump|bootstrap] - % 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 +To work around this problem, it is necessary to temporarily disable +Exec-shield while building Emacs, or, on x86, by using the `setarch' +command when running temacs like this: + + setarch i386 ./temacs --batch --load loadup [dump|bootstrap] + + +*** Fedora Core 4 GNU/Linux: Segfault during dumping. + +In addition to exec-shield explained above "Linux: Segfault during +`make bootstrap' under certain recent versions of the Linux kernel" +item, Linux kernel shipped with Fedora Core 4 randomizes the virtual +address space of a process. As the result dumping may fail even if +you turn off exec-shield. In this case, use the -R option to the setarch +command: -* Fatal signal in the command temacs -l loadup inc dump + setarch i386 -R ./temacs --batch --load loadup [dump|bootstrap] + +or + + setarch i386 -R make bootstrap + +*** 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. @@ -2781,14 +2432,14 @@ 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 +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 +*** 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 @@ -2821,7 +2472,7 @@ nonprinting characters, you can fix them: and remake temacs. 7) Remake emacs. It should work now, with valid .elc files. -* temacs prints "Pure Lisp storage exhausted" +*** 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 @@ -2850,17 +2501,65 @@ 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. +*** Linux: Emacs crashes when dumping itself on Mac PPC running Yellow Dog GNU/Linux. -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. +The crashes happen inside the function Fmake_symbol; here's a typical +C backtrace printed by GDB: -Emacs should print a warning when loading a .elc file which is older -than the corresponding .el file. + 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. + +** 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. +*** The dumped Emacs crashes when run, trying to write pure data. Two causes have been seen for such problems. @@ -2875,356 +2574,916 @@ 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. +* Emacs 19 problems -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. +** Error messages `Wrong number of arguments: #, 5'. -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. +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. -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; +So the fix is to arrange not to load powerkey. - 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. +* Runtime problems on legacy systems -* rmail gets error getting new mail +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. -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. +** Ancient operating systems -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! +AIX 4.2 was end-of-lifed on Dec 31st, 1999. -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): +*** AIX: You get this compiler error message: - chgrp mail movemail - chmod 2755 movemail + Processing include file ./XMenuInt.h + 1501-106: (S) Include file X11/Xlib.h not found. -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. +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. - chgrp mail movemail - chmod 2755 movemail +(This report must be ancient. Bootable tapes are long dead.) -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. +*** AIX 3.2.4: Releasing Ctrl/Act key has no effect, if Shift is down. -* Emacs spontaneously displays "I-search: " at the bottom of the screen. +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. -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. +You can get out of this "control-locked" state by pressing and +releasing Ctrl/Act while not pressing or holding any other keys. -There are three possible reasons why flow control could be taking place: +*** AIX 3.2.5: You get this message when running Emacs: - 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 + Could not load program emacs + Symbol smtcheckinit in csh is undefined + Error was: Exec format error -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. +or this one: -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. + Could not load program .emacs + Symbol _system_con in csh is undefined + Symbol _fp_trapsta in csh is undefined + Error was: Exec format error -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. +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 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. + +*** 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 + +SunOS 4.1.4 stopped shipping on Sep 30 1998. + +**** SunOS: You get linker errors + ld: Undefined symbol + _get_wmShellWidgetClass + _get_applicationShellWidgetClass + +**** 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 +delivered by passing messages to the /usr/lib/sendmail (usually) +program . In doing so, it passes the '-t' flag to sendmail, which +means that the name of the recipient of the message is not on the +command line and, therefore, that sendmail must parse the message to +obtain the destination address. + +There is a bug in the SunOS4.1.1 and SunOS4.1.3 versions of sendmail. +In short, when given the -t flag, the SunOS sendmail won't recognize +non-local (i.e. NIS) aliases. It has been reported that the Solaris +2.x versions of sendmail do not have this bug. For those using SunOS +4.1, the best fix is to install sendmail V8 or IDA sendmail (which +have other advantages over the regular sendmail as well). At the time +of this writing, these official versions are available: + + Sendmail V8 on ftp.cs.berkeley.edu in /ucb/sendmail: + sendmail.8.6.9.base.tar.Z (the base system source & documentation) + sendmail.8.6.9.cf.tar.Z (configuration files) + sendmail.8.6.9.misc.tar.Z (miscellaneous support programs) + sendmail.8.6.9.xdoc.tar.Z (extended documentation, with postscript) + + IDA sendmail on vixen.cso.uiuc.edu in /pub: + sendmail-5.67b+IDA-1.5.tar.gz + +**** 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 bug-gnu-emacs@gnu.org. + +**** 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. + +The fix to this is to install patch 100573 for OpenWindows 3.0 +or link libXmu statically. + +**** 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. + +*** 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 +bug-gnu-emacs@gnu.org. + +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. + +casper@fwi.uva.nl 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 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 +. 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. + +pen@lysator.liu.se says (Feb 1998) that the Compose key does work +if you link with the MIT X11 libraries instead of the Solaris X11 +libraries. + +*** HP/UX versions before 11.0 + +HP/UX 9 was end-of-lifed in December 1998. +HP/UX 10 was end-of-lifed in May 1999. + +**** HP/UX 9: Emacs crashes with SIGBUS or SIGSEGV 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. + +*** HP/UX 10: Large file support is disabled. + +See the comments in src/s/hpux10.h. + +*** 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. + +*** 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. + +*** Irix 5 and earlier + +Exactly when Irix-5 end-of-lifed is obscure. But since Irix 6.0 +shipped in 1994, it has been some years. + +**** 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. -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. +*** SCO Unix and UnixWare -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.) +**** SCO 3.2v4: Unusable default font. -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. +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. + +**** SCO 4.2.0: 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 (abrahams@acm.org) 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. + +*** 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. + +** Windows 3.1, 95, 98, and ME + +*** MS-Windows NT/95: Problems running Perl under Emacs + +`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 { + +*** 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. + +*** 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. + +** 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. -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. +** Archaic window managers and toolkits -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: +*** OpenLook: Under OpenLook, the Emacs window disappears when you type M-q. -(enable-flow-control-on "vt200" "vt300" "vt101" "vt131") +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: -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. + OpenWindows.WindowMenuAccelerators: False -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. +**** twm: A position you specified in .Xdefaults is ignored, using twm. -* Control-S and Control-Q commands are ignored completely. +twm normally ignores "program-specified" positions. +You can tell it to obey them with this command in your `.twmrc' file: -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. + UsePPosition "on" #allow clients to request a position -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. +** Bugs related to old DEC hardware -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-\. +*** The Compose key on a DEC keyboard does not work as Meta key. -* Control-S and Control-Q commands are ignored completely on a net connection. +This shell command should fix it: -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. + xmodmap -e 'keycode 0xb1 = Meta_L' -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. +*** Keyboard input gets confused after a beep when using a DECserver +as a concentrator. -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. +This problem seems to be a matter of configuring the DECserver to use +7 bit characters rather than 8 bit characters. -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): +* Build problems on legacy systems -(enable-flow-control-on "vt200" "vt300" "vt101" "vt131") +** BSD/386 1.0: --with-x-toolkit option configures wrong. -See the entry about spontaneous display of I-search (above) for more -info. +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. -* Screen is updated wrong, but only on one kind of terminal. +** Digital Unix 4.0: Emacs fails to build, giving error message + Invalid dimension for the charset-ID 160 -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. +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. -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: +** Digital Unix 4.0: Failure in unexec while dumping emacs. -1) The characters sent are correct, according to the terminal manual. +This problem manifests itself as an error message -In this case, there is no obvious bug in Emacs, and most likely you -need more padding, or possibly the terminal manual is wrong. + unexec: Bad address, writing data section to ... -2) The characters sent are incorrect, due to an obscure aspect - of the terminal behavior not described in an obvious way - by termcap. +The user suspects that this happened because his X libraries +were built for an older system version, -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. + ./configure --x-includes=/usr/include --x-libraries=/usr/shlib -3) The termcap entry is wrong. +made the problem go away. -See the file etc/TERMS for information on changes -that are known to be needed in commonly used termcap entries -for certain terminals. +** Sunos 4.1.1: there are errors compiling sysdep.c. -4) The characters sent are incorrect, and clearly cannot be - right for any terminal with the termcap entry you were using. +If you get errors such as -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. + "sysdep.c", line 2017: undefined structure or union + "sysdep.c", line 2017: undefined structure or union + "sysdep.c", line 2019: nodename undefined -* Output from Control-V is slow. +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. -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. +** SunOS 4.1.1: You get this error message from GNU ld: -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. + /lib/libc.a(_Q_sub.o): Undefined symbol __Q_get_rp_rd referenced from text segment -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. +The problem is in the Sun shared C library, not in GNU ld. -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. +The solution is to install Patch-ID# 100267-03 from Sun. -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. +** Sunos 4.1: Undefined symbols when linking using --with-x-toolkit. -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. +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. -* Your Delete key sends a Backspace to the terminal, using an AIXterm. +This problem seems to arise only when the international language +extensions to X11R5 are installed. -The solution is to include in your .Xdefaults the lines: +** SunOS: Emacs gets error message from linker on Sun. - *aixterm.Translations: #override BackSpace: string(0x7f) - aixterm*ttyModes: erase ^? +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. -This makes your Backspace key send DEL (ASCII 127). +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. -* You type Control-H (Backspace) expecting to delete characters. +** SunOS: Undefined symbols _dlopen, _dlsym and/or _dlclose. -Put `stty dec' in your .login file and your problems will disappear -after a day or two. +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.) -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. +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. -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'. +** SunOS4, DGUX 5.4.2: --with-x-toolkit version crashes when used with shared libraries. -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. +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. -* 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. +** HPUX 10.20: Emacs crashes during dumping on the HPPA machine. - There was a serious pair of bugs in the handling of the fsync() system - call in the RFS server. +This seems to be due to a GCC bug; it is fixed in GCC 2.8.1. - 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. +** VMS: Compilation errors on VMS. - This is fixed by the enclosed patch to the RFS server. +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. - 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. +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. - (as always, your line numbers may vary) +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; - % 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 - { + 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. +** Vax C compiler bugs affecting Emacs. You may get one of these problems compiling Emacs: @@ -3257,22 +3516,22 @@ causes the problem to go away. 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 +** 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. +*** 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. +*** "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. +*** 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: @@ -3292,7 +3551,7 @@ In the XCONS, etc., macros in lisp.h you must replace (a).u.val with 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 +*** 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 @@ -3302,7 +3561,15 @@ This problem will not happen if the m-...h file for your type of machine defines NO_UNION_TYPE. +Copyright 1987, 1988, 1989, 1993, 1994, 1995, 1996, 1997, 1998, 1999, + 2001, 2002, 2003, 2004, 2005 Free Software Foundation, Inc. + +Copying and redistribution of this file with or without modification +are permitted without royalty provided this notice is preserved. + Local variables: mode: outline paragraph-separate: "[ ]*$" end: + +arch-tag: 49fc0d95-88cb-4715-b21c-f27fb5a4764a