Mercurial > hg > xemacs-beta
diff PROBLEMS @ 0:376386a54a3c r19-14
Import from CVS: tag r19-14
| author | cvs |
|---|---|
| date | Mon, 13 Aug 2007 08:45:50 +0200 |
| parents | |
| children | 8d2a9b52c682 |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/PROBLEMS Mon Aug 13 08:45:50 2007 +0200 @@ -0,0 +1,1720 @@ +This file describes various problems that have been encountered +in compiling, installing and running XEmacs. + +(synched up with: 19.30) + +* On Irix, I don't see the toolbar icons and I'm getting lots of + entries in the warnings buffer. + +SGI ships a really old Xpm library in /usr/lib which does not work at +all well with XEmacs. The solution is to install your own copy of the +latest version of Xpm somewhere and then use the --site-includes and +--site-libraries flags to tell configure where to find it. + +* On Digital UNIX, the DEC C compiler might have a problem compiling + some files. + +In particular, src/extents.c and src/faces.c might cause the DEC C +compiler to abort. When this happens: cd src, compile the files by +hand, cd .., and redo the "make" command. When recompiling the files by +hand, use the old C compiler for the following versions of Digital UNIX: + - V3.n: Remove "-migrate" from the compile command. + - V4.n: Add "-oldc" to the compile command. + +* On HPUX, the HP C compiler might have a problem compiling some files + with optimization. + +Richard Cognot <cognot@ensg.u-nancy.fr> writes: + + Had to drop once again to level 2 optimization, at least to + compile lstream.c. Otherwise, I get a "variable is void: \if" + problem while dumping (this is a problem I already reported + with vanilla hpux 10.01 and 9.07, which went away after + applying patches for the C compiler). Trouble is I still + haven't found the same patch for hpux 10.10, and I don't + remember the patch numbers. I think potential XEmacs builders + on HP should be warned about this. + +* On HPUX, you get "poll: Interrupted system call" message in the window + where XEmacs was launched. + +Richard Cognot <cognot@ensg.u-nancy.fr> writes: + + I get a very strange problem when linking libc.a + dynamically: every event (mouse, keyboard, expose...) results + in a "poll: Interrupted system call" message in the window + where XEmacs was launched. Forcing a static link of libc.a + alone by adding /usr/lib/libc.a at the end of the link line + solves this. Note that my 9.07 build of 19.14b17 and my (old) + build of 19.13 both exhibit the same behaviour. I've tried + various hpux patches to no avail. If this problem cannot be + solved before the release date, binary kits for HP *must* be + linked statically against libc, otherwise this problem will + show up. (This is directed at whoever will volunteer for this + kit, as I won't be available to do it, unless 19.14 gets + delayed until mid-june ;-). I think this problem will be an FAQ + soon after the release otherwise. + +* Native cc on SCO OpenServer 5 is now OK. Icc may still throw you + a curve. Here is what Robert Lipe <robertl@arnet.com> says: + +Unlike XEmacs 19.13, building with the native cc on SCO OpenServer 5 +now produces a functional binary. I will typically build this +configuration for COFF with: + + /path_to_XEmacs_source/configure --with-gcc=no \ + --site-includes=/usr/local/include --site-libraries=/usr/local/lib \ + --with-xpm --with-xface --with-sound=nas + +This version now supports ELF builds. I highly recommend this to +reduce the in-core footprint of XEmacs. This is now how I compile +all my test releases. Build it like this: + + /path_to_XEmacs_source/configure --with-gcc=no \ + --site-includes=/usr/local/include --site-libraries=/usr/local/lib \ + --with-xpm --with-xface --with-sound=nas --dynamic + +The compiler known as icc [ supplied with the OpenServer 5 Development +System ] generates a working binary, but it takes forever to generate +XEmacs. ICC also whines more about the code than /bin/cc does. I do +believe all its whining is legitimate, however. Note that you do +have to 'cd src ; make LD=icc' to avoid linker errors. + +The way I handle the build procedure is: + + /path_to_XEmacs_source/configure --with-gcc=no \ + --site-includes=/usr/local/include --site-libraries=/usr/local/lib \ + --with-xpm --with-xface --with-sound=nas --dynamic --compiler="icc" + +*NOTE* I have the xpm, xface, and audio libraries and includes in + /usr/local/lib, /usr/local/include. If you don't have these, + don't include the "--with-*" arguments in any of my examples. + +In previous versions of XEmacs, you had to override the defaults while +compiling font-lock.o and extents.o when building with icc. This seems +to no longer be true, but I'm including this old information in case it +resurfaces. The process I used was: + + make -k + [ procure pizza, beer, repeat ] + cd src + make CC="icc -W0,-mP1COPT_max_tree_size=3000" font-lock.o extents.o + make LD=icc + +If you want sound support, get the tls566 supplement from +ftp.sco.com:/TLS or any of its mirrors. It works just groovy +with XEmacs. + +The M-x manual-entry is known not to work. If you know Lisp and would +like help in making it work, e-mail me at <robertl@dgii.com> + +In earlier releases, gnuserv/gnuclient/gnudoit would open a frame +just fine, but the client would lock up and the server would +terminate when you used C-x # to close the frame. This is now +fixed in XEmacs. + +In etc/ there are two files of note. emacskeys.sco and emacsstrs.sco. +The comments at the top of emacskeys.sco describe its function, and +the emacstrs.sco is a suitable candidate for /usr/lib/keyboard/strings +to take advantage of the keyboard map in emacskeys.sco. + +* Don't use -O2 with gcc under Linux without also using + -fno-strength-reduce. gcc will generate incorrect code otherwise. + This bug is present in at least 2.6.x and 2.7.[0-2]. A patched + binary for 2.7.2 is available in + + ftp://tsx-11.mit.edu/pub/linux/packages/GCC/gcc272-no-sr-bug.lbin.tgz + + Or wait for GCC 2.7.3. + +* Under some versions of OSF XEmacs runs fine if built without +optimization but will crash randomly if built with optimization. +Using 'cc -g' is not sufficient to eliminate all optimization. Try +'cc -g -O0' instead. + +* On HP/UX configure selects gcc even though it isn't actually present. + +Some versions of SoftBench have an executable called 'gcc' that is not +actually the GNU C compiler. Use the --with-gcc=no flag when running +configure. + + +* When Emacs tries to ring the bell, you get an error like + + audio: sst_open: SETQSIZE" Invalid argument + audio: sst_close: SETREG MMR2, Invalid argument + +you have probably compiled using an ANSI C compiler, but with non-ANSI include +files. In particular, on Suns, the file /usr/include/sun/audioio.h uses the +_IOW macro to define the constant AUDIOSETQSIZE. _IOW in turn uses a K&R +preprocessor feature that is now explicitly forbidden in ANSI preprocessors, +namely substitution inside character constants. All ANSI C compilers must +provide a workaround for this problem. Lucid's C compiler is shipped with a +new set of system include files. If you are using GCC, there is a script +called fixincludes that creates new versions of some system include files that +use this obsolete feature. + +* The `Alt' key doesn't behave as `Meta' when running DECwindows. + +The default DEC keyboard mapping has the Alt keys set up to generate the +keysym `Multi_key', which has a meaning to xemacs which is distinct from that +of the `Meta_L' and `Meta-R' keysyms. A second problem is that certain keys +have the Mod2 modifier attached to them for no adequately explored reason. +The correct fix is to pass this file to xmodmap upon starting X: + + clear mod2 + keysym Multi_key = Alt_L + add mod1 = Alt_L + add mod1 = Alt_R + +* I get complaints about the mapping of my HP keyboard at startup, but I + haven't changed anything. + +The default HP keymap is set up to have Mod1 assigned to two different keys: +Meta_L and Mode_switch (even though there is not actually a Mode_switch key on +the keyboard -- it uses an "imaginary" keycode.) There actually is a reason +for this, but it's not a good one. The correct fix is to execute this command +upon starting X: + + xmodmap -e 'remove mod1 = Mode_switch' + +* I have focus problems when I use `M-o' to switch to another screen without + using the mouse. + +The focus issues with a program like XEmacs, which has multiple homogeneous +top-level windows, are very complicated, and as a result, most window managers +don't implement them correctly. + +The R4/R5 version of twm (and all of its descendants) had buggy focus +handling; there is a patch in .../xemacs/etc/twm-patch which fixes this. +Sufficiently recent versions of tvtwm do not need this patch, but most other +versions of twm do. If you need to apply this patch, please try to get it +integrated by the maintainer of whichever version of twm you're using. + +In addition, if you're using twm, make sure you have not specified +"NoTitleFocus" in your .tvtwmrc file. The very nature of this option makes +twm do some illegal focus tricks, even with the patch. + +It is known that olwm and olvwm are buggy, and in different ways. If you're +using click-to-type mode, try using point-to-type, or vice versa. + +In older versions of NCDwm, one could not even type at XEmacs windows. This +has been fixed in newer versions (2.4.3, and possibly earlier). + +(Many people suggest that XEmacs should warp the mouse when focusing on +another screen in point-to-type mode. This is not ICCCM-compliant behavior. +Implementing such policy is the responsibility of the window manager itself, +it is not legal for a client to do this.) + +* My buffers are full of \000 characters or otherwise corrupt. + +Some compilers have trouble with gmalloc.c and ralloc.c; try recompiling +without optimization. If that doesn't work, try recompiling with +SYSTEM_MALLOC defined, and/or with REL_ALLOC undefined. + +* Some packages that worked before now cause the error + Wrong type argument: arrayp, #<face ... > + +Code which uses the `face' accessor functions must be recompiled with xemacs +19.9 or later. The functions whose callers must be recompiled are: face-font, +face-foreground, face-background, face-background-pixmap, and face-underline-p. +The .elc files generated by version 19.9 will work in 19.6 and 19.8, but older +.elc files which contain calls to these functions will not work in 19.9. + +* On Solaris 2.* I get undefined symbols from libcurses.a. + +You probably have /usr/ucblib/ on your LD_LIBRARY_PATH. Do the link with +LD_LIBRARY_PATH unset. + +* I don't have `xmkmf' and `imake' on my HP. + +You can get these standard X tools by anonymous FTP to hpcvaaz.cv.hp.com. +Essentially all X programs need these. + +* When emacs starts up, I get lots of warnings about unknown keysyms. + +If you are running the prebuilt binaries, the Motif library expects to find +certain thing in the XKeysymDB file. This file is normally in /usr/lib/X11/ +or in /usr/openwin/lib/. If you keep yours in a different place, set the +environment variable $XKEYSYMDB to point to it before starting emacs. If +you still have the problem after doing that, perhaps your version of X is +too old. There is a copy of the MIT X11R5 XKeysymDB file in the emacs `etc' +directory. Try using that one. + +* My X resources used to work, and now some of them are being ignored. + +Check the resources in .../etc/Emacs.ad (which is the same as the file +sample.Xdefaults). Perhaps some of the default resources built in to +emacs are now overriding your existing resources. Copy and edit the +resources in Emacs.ad as necessary. + +* Solaris 2.3 /bin/sh coredumps during configuration. + +This only occurs if you have LANG != C. This is a known bug with +/bin/sh fixed by installing Patch-ID# 101613-01. + +* "Cannot find callback list" messages from dialog boxes on HPUX, in +Emacs built with Motif. + +This problem resulted from a bug in GCC 2.4.5. Newer GCC versions +such as 2.7.0 fix the problem. + +* On Irix 6.0, make tries (and fails) to build a program named unexelfsgi + +A compiler bug inserts spaces into the string "unexelfsgi . o" +in src/Makefile. Edit src/Makefile, after configure is run, +find that string, and take out the spaces. + +Compiler fixes in Irix 6.0.1 should eliminate this problem. + +* With certain fonts, when the cursor appears on a character, the +character doesn't appear--you get a solid box instead. + +One user on a Linux-based GNU system reported that this problem went +away with installation of a new X server. The failing server was +XFree86 3.1.1. XFree86 3.1.2 works. + +* On SunOS 4.1.3, Emacs unpredictably crashes in _yp_dobind_soft. + +This happens if you configure Emacs specifying just `sparc-sun-sunos4' +on a system that is version 4.1.3. You must specify the precise +version number (or let configure figure out the configuration, which +it can do perfectly well for SunOS). + +* On SunOS 4, Emacs processes keep going after you kill the X server +(or log out, if you logged in using X). + +Someone reported that recompiling with GCC 2.7.0 fixed this problem. + +* On AIX 4, some programs fail when run in a Shell buffer +with an error message like No terminfo entry for "unknown". + +On AIX, many terminal type definitions are not installed by default. +`unknown' is one of them. Install the "Special Generic Terminal +Definitions" to make them defined. + +* On SunOS, you get linker errors + ld: Undefined symbol + _get_wmShellWidgetClass + _get_applicationShellWidgetClass + +The fix to this is to install patch 100573 for OpenWindows 3.0 +or link libXmu statically. + +* On AIX 4.1.2, linker error messages such as + ld: 0711-212 SEVERE ERROR: Symbol .__quous, found in the global symbol table + of archive /usr/lib/libIM.a, was not defined in archive member shr.o. + +This is a problem in libIM.a. You can work around it by executing +these shell commands in the src subdirectory of the directory where +you build Emacs: + + cp /usr/lib/libIM.a . + chmod 664 libIM.a + ranlib libIM.a + +Then change -lIM to ./libIM.a in the command to link temacs (in +Makefile). + +* Unpredictable segmentation faults on Solaris 2.3 and 2.4. + +A user reported that this happened in 19.29 when it was compiled with +the Sun compiler, but not when he recompiled with GCC 2.7.0. + +We do not know whether something in Emacs is partly to blame for this. + +* Emacs exits with "X protocol error" when run with an X server for +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. + +* 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 clents 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. + +* On Sunos 4.1.1, there are errors compiling sysdep.c. + +If you get errors such as + + "sysdep.c", line 2017: undefined structure or union + "sysdep.c", line 2017: undefined structure or union + "sysdep.c", line 2019: nodename undefined + +This can result from defining LD_LIBRARY_PATH. It is very tricky +to use that environment variable with Emacs. The Emacs configure +script links many test programs with the system libraries; you must +make sure that the libraries available to configure are the same +ones available when you build Emacs. + +* The right Alt key works wrong on German HP keyboards (and perhaps +other non-English HP keyboards too). + +This is because HPUX defines the modifiers wrong in X. Here is a +shell script to fix the problem; be sure that it is run after VUE +configures the X server. + + xmodmap 2> /dev/null - << EOF + keysym Alt_L = Meta_L + keysym Alt_R = Meta_R + EOF + + xmodmap - << EOF + clear mod1 + keysym Mode_switch = NoSymbol + add mod1 = Meta_L + keysym Meta_R = Mode_switch + add mod2 = Mode_switch + EOF + +* The Emacs window disappears when you type M-q. + +Some versions of the Open Look window manager interpret M-q as a quit +command for whatever window you are typing at. If you want to use +Emacs with that window manager, you should try to configure the window +manager to use some other command. You can disable the +shortcut keys entirely by adding this line to ~/.OWdefaults: + + OpenWindows.WindowMenuAccelerators: False + +* Emacs does not notice when you release the mouse. + +There are reports that this happened with (some) Microsoft mice and +that replacing the mouse made it stop. + +* Trouble using ptys on IRIX, or running out of ptys. + +The program mkpts (which may be in `/usr/adm' or `/usr/sbin') needs to +be set-UID to root, or non-root programs like Emacs will not be able +to allocate ptys reliably. + +* On Irix 5.2, unexelfsgi.c can't find cmplrs/stsupport.h. + +The file cmplrs/stsupport.h was included in the wrong file set in the +Irix 5.2 distribution. You can find it in the optional fileset +compiler_dev, or copy it from some other Irix 5.2 system. A kludgy +workaround is to change unexelfsgi.c to include sym.h instead of +syms.h. + +* Slow startup on Linux. + +People using systems based on the Linux kernel sometimes report that +startup takes 10 to 15 seconds longer than `usual'. + +This is because Emacs looks up the host name when it starts. +Normally, this takes negligible time; the extra delay is due to +improper system configuration. This problem can occur for both +networked and non-networked machines. + +Here is how to fix the configuration. It requires being root. + +** Networked Case + +First, make sure the files `/etc/hosts' and `/etc/host.conf' both +exist. The first line in the `/etc/hosts' file should look like this +(replace HOSTNAME with your host name): + + 127.0.0.1 HOSTNAME + +Also make sure that the `/etc/host.conf' files contains the following +lines: + + order hosts, bind + multi on + +Any changes, permanent and temporary, to the host name should be +indicated in the `/etc/hosts' file, since it acts a limited local +database of addresses and names (e.g., some SLIP connections +dynamically allocate ip addresses). + +** Non-Networked Case + +The solution described in the networked case applies here as well. +However, if you never intend to network your machine, you can use a +simpler solution: create an empty `/etc/host.conf' file. The command +`touch /etc/host.conf' suffices to create the file. The `/etc/hosts' +file is not necessary with this approach. + +* On Solaris 2.4, Dired hangs and C-g does not work. Or Emacs hangs +forever waiting for termination of a subprocess that is a zombie. + +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 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 <frust@iti.cs.tu-bs.de> used a simpler solution: +he changed + #define ThreadedX YES +to + #define ThreadedX NO +in sun.cf and did `make World' to rebuild X11R6. Removing all +`-DXTHREAD*' flags and `-lthread' entries from lib/X11/Makefile and +typing 'make install' in that directory also seemed to work. + +* With M-x enable-flow-control, you need to type C-\ twice + to do incremental search--a single C-\ gets no response. + +This has been traced to communicating with your machine via kermit, +with C-\ as the kermit escape character. One solution is to use +another escape character in kermit. One user did + + set escape-character 17 + +in his .kermrc file, to make C-q the kermit escape character. + +* The Motif version of Emacs paints the screen a solid color. + +This has been observed to result from the following X resource: + + Emacs*default.attributeFont: -*-courier-medium-r-*-*-*-140-*-*-*-*-iso8859-* + +That the resource has this effect indicates a bug in something, but we +do not yet know what. If it is an Emacs bug, we hope someone can +explain what the bug is so we can fix it. In the mean time, removing +the resource prevents the problem. + +* Emacs gets hung shortly after startup, on Sunos 4.1.3. + +We think this is due to a bug in Sunos. The word is that +one of these Sunos patches fixes the bug: + +100075-11 100224-06 100347-03 100482-05 100557-02 100623-03 100804-03 101080-01 +100103-12 100249-09 100496-02 100564-07 100630-02 100891-10 101134-01 +100170-09 100296-04 100377-09 100507-04 100567-04 100650-02 101070-01 101145-01 +100173-10 100305-15 100383-06 100513-04 100570-05 100689-01 101071-03 101200-02 +100178-09 100338-05 100421-03 100536-02 100584-05 100784-01 101072-01 101207-01 + +We don't know which of these patches really matter. If you find out +which ones, please inform bug-gnu-emacs@prep.ai.mit.edu. + +* Emacs aborts while starting up, only when run without X. + +This problem often results from compiling Emacs with GCC when GCC was +installed incorrectly. The usual error in installing GCC is to +specify --includedir=/usr/include. Installation of GCC makes +corrected copies of the system header files. GCC is supposed to use +the corrected copies in preference to the original system headers. +Specifying --includedir=/usr/include causes the original system header +files to be used. On some systems, the definition of ioctl in the +original system header files is invalid for ANSI C and causes Emacs +not to work. + +The fix is to reinstall GCC, and this time do not specify --includedir +when you configure it. Then recompile Emacs. Specifying --includedir +is appropriate only in very special cases and it should *never* be the +same directory where system header files are kept. + +* The Compose key on a DEC keyboard does not work as Meta key. + +This shell command should fix it: + + xmodmap -e 'keycode 0xb1 = Meta_L' + +* Regular expressions matching bugs on SCO systems. + +On SCO, there are problems in regexp matching when Emacs is compiled +with the system compiler. The compiler version is "Microsoft C +version 6", SCO 4.2.0h Dev Sys Maintenance Supplement 01/06/93; Quick +C Compiler Version 1.00.46 (Beta). The solution is to compile with +GCC. + +* On Sunos 4, you get the error ld: Undefined symbol __lib_version. + +This is the result of using cc or gcc with the shared library meant +for acc (the Sunpro compiler). Check your LD_LIBRARY_PATH and delete +/usr/lang/SC2.0.1 or some similar directory. + +* You can't select from submenus. + +On certain systems, mouse-tracking and selection in top-level menus +works properly with the X toolkit, but neither of them works when you +bring up a submenu (such as Bookmarks or Compare or Apply Patch, in +the Files menu). + +This works on most systems. There is speculation that the failure is +due to bugs in old versions of X toolkit libraries, but no one really +knows. If someone debugs this and finds the precise cause, perhaps a +workaround can be found. + +* Unusable default font on SCO 3.2v4. + +The Open Desktop environment comes with default X resource settings +that tell Emacs to use a variable-width font. Emacs cannot use such +fonts, so it does not work. + +This is caused by the file /usr/lib/X11/app-defaults/ScoTerm, which is +the application-specific resource file for the `scoterm' terminal +emulator program. It contains several extremely general X resources +that affect other programs besides `scoterm'. In particular, these +resources affect Emacs also: + + *Font: -*-helvetica-medium-r-*--12-*-p-* + *Background: scoBackground + *Foreground: scoForeground + +The best solution is to create an application-specific resource file for +Emacs, /usr/lib/X11/app-defaults/Emacs, with the following contents: + + Emacs*Font: -*-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-1 + Emacs*Background: white + Emacs*Foreground: black + +(or whatever other defaults you prefer). + +These resource files are not normally shared across a network of SCO +machines; you must create the file on each machine individually. + +* rcs2log gives you the awk error message "too many fields". + +This is due to an arbitrary limit in certain versions of awk. +The solution is to use gawk (GNU awk). + +* Emacs is slow using X11R5 on HP/UX. + +This happens if you use the MIT versions of the X libraries--it +doesn't run as fast as HP's version. People sometimes use the version +because they see the HP version doesn't have the libraries libXaw.a, +libXmu.a, libXext.a and others. HP/UX normally doesn't come with +those libraries installed. To get good performance, you need to +install them and rebuild Emacs. + +* Loading fonts is very slow. + +You might be getting scalable fonts instead of precomputed bitmaps. +Known scalable font directories are "Type1" and "Speedo". A font +directory contains scalable fonts if it contains the file +"fonts.scale". + +If this is so, re-order your X windows font path to put the scalable +font directories last. See the documentatoin of `xset' for details. + +With some X servers, it may be necessary to take the scalable font +directories out of your path entirely, at least for Emacs 19.26. +Changes in the future may make this unnecessary. + +* On AIX 3.2.4, releasing Ctrl/Act key has no effect, if Shift is down. + +Due to a feature of AIX, pressing or releasing the Ctrl/Act key is +ignored when the Shift, Alt or AltGr keys are held down. This can +lead to the keyboard being "control-locked"--ordinary letters are +treated as control characters. + +You can get out of this "control-locked" state by pressing and +releasing Ctrl/Act while not pressing or holding any other keys. + +* display-time causes kernel problems on ISC systems. + +Under Interactive Unix versions 3.0.1 and 4.0 (and probably other +versions), display-time causes the loss of large numbers of STREVENT +cells. Eventually the kernel's supply of these cells is exhausted. +This makes emacs and the whole system run slow, and can make other +processes die, in particular pcnfsd. + +Other emacs functions that communicate with remote processes may have +the same problem. Display-time seems to be far the worst. + +The only known fix: Don't run display-time. + +* On Solaris, C-x doesn't get through to Emacs when you use the console. + +This is a Solaris feature (at least on Intel x86 cpus). Type C-r +C-r C-t, to toggle whether C-x gets through to Emacs. + +* Error message `Symbol's value as variable is void: x', followed by + segmentation fault and core dump. + +This has been tracked to a bug in tar! People report that tar erroneously +added a line like this at the beginning of files of Lisp code: + + x FILENAME, N bytes, B tape blocks + +If your tar has this problem, install GNU tar--if you can manage to +untar it :-). + +* Link failure when using acc on a Sun. + +To use acc, you need additional options just before the libraries, such as + + /usr/lang/SC2.0.1/values-Xt.o -L/usr/lang/SC2.0.1/cg87 -L/usr/lang/SC2.0.1 + +and you need to add -lansi just before -lc. + +The precise file names depend on the compiler version, so we +cannot easily arrange to supply them. + +* Link failure on IBM AIX 1.3 ptf 0013. + +There is a real duplicate definition of the function `_slibc_free' in +the library /lib/libc_s.a (just do nm on it to verify). The +workaround/fix is: + + cd /lib + ar xv libc_s.a NLtmtime.o + ar dv libc_s.a NLtmtime.o + +* Undefined symbols _dlopen, _dlsym and/or _dlclose on a Sun. + +If you see undefined symbols _dlopen, _dlsym, or _dlclose when linking +with -lX11, compile and link against the file mit/util/misc/dlsym.c in +the MIT X11R5 distribution. Alternatively, link temacs using shared +libraries with s/sunos4shr.h. (This doesn't work if you use the X +toolkit.) + +If you get the additional error that the linker could not find +lib_version.o, try extracting it from X11/usr/lib/X11/libvim.a in +X11R4, then use it in the link. + +* In Shell mode, you get a ^M at the end of every line. + +This happens to people who use tcsh, because it is trying to be too +smart. It sees that the Shell uses terminal type `unknown' and turns +on the flag to output ^M at the end of each line. You can fix the +problem by adding this to your .cshrc file: + + if ($?EMACS) then + if ($EMACS == "t") then + unset edit + stty -icrnl -onlcr -echo susp ^Z + endif + endif + +* An error message such as `X protocol error: BadMatch (invalid +parameter attributes) on protocol request 93'. + +This comes from having an invalid X resource, such as + emacs*Cursor: black +(which is invalid because it specifies a color name for something +that isn't a color.) + +The fix is to correct your X resources. + +* Undefined symbols when linking on Sunos 4.1. + +If you get the undefined symbols _atowc _wcslen, _iswprint, _iswspace, +_iswcntrl, _wcscpy, and _wcsncpy, then you need to add -lXwchar after +-lXaw in the command that links temacs. + +This problem seems to arise only when the international language +extensions to X11R5 are installed. + +* Typing C-c C-c in Shell mode kills your X server. + +This happens with Linux kernel 1.0 thru 1.04, approximately. The workaround is +to define SIGNALS_VIA_CHARACTERS in config.h and recompile Emacs. +Newer Linux kernel versions don't have this problem. + +* src/Makefile and lib-src/Makefile are truncated--most of the file missing. + +This can happen if configure uses GNU sed version 2.03. That version +had a bug. GNU sed version 2.05 works properly. + +* Slow startup on X11R6 with X windows. + +If Emacs takes two minutes to start up on X11R6, see if your X +resources specify any Adobe fonts. That causes the type-1 font +renderer to start up, even if the font you asked for is not a type-1 +font. + +One way to avoid this problem is to eliminate the type-1 fonts from +your font path, like this: + + xset -fp /usr/X11R6/lib/X11/fonts/Type1/ + +* Pull-down menus appear in the wrong place, in the toolkit version of Emacs. + +An X resource of this form can cause the problem: + + Emacs*geometry: 80x55+0+0 + +This resource is supposed to apply, and does apply, to the menus +individually as well as to Emacs frames. If that is not what you +want, rewrite the resource. + +To check thoroughly for such resource specifications, use `xrdb +-query' to see what resources the X server records, and also look at +the user's ~/.Xdefaults and ~/.Xdefaults-* files. + +* `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. + +* Subprocesses remain, hanging but not zombies, on Sunos 5.3. + +A bug in Sunos 5.3 causes Emacs subprocesses to remain after Emacs +exits. Sun patch # 101415-02 is part of the fix for this, but it only +applies to ptys, and doesn't fix the problem with subprocesses +communicating through pipes. + +* Mail is lost when sent to local aliases. + +Many emacs mail user agents (VM and rmail, for instance) use the +sendmail.el library. This library can arrange for mail to be +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 + +* On AIX, you get this message when running Emacs: + + Could not load program emacs + Symbol smtcheckinit in csh is undefined + Error was: Exec format error + +or this one: + + Could not load program .emacs + Symbol _system_con in csh is undefined + Symbol _fp_trapsta in csh is undefined + Error was: Exec format error + +These can happen when you try to run on AIX 3.2.5 a program that was +compiled with 3.2.4. The fix is to recompile. + +* On AIX, you get this compiler error message: + + Processing include file ./XMenuInt.h + 1501-106: (S) Include file X11/Xlib.h not found. + +This means your system was installed with only the X11 runtime i.d +libraries. You have to find your sipo (bootable tape) and install +X11Dev... with smit. + +* You "lose characters" after typing Compose Character key. + +This is because the Compose Character key is defined as the keysym +Multi_key, and Emacs (seeing that) does the proper X11 +character-composition processing. If you don't want your Compose key +to do that, you can redefine it with xmodmap. + +For example, here's one way to turn it into a Meta key: + + xmodmap -e "keysym Multi_key = Meta_L" + +If all users at your site of a particular keyboard prefer Meta to +Compose, you can make the remapping happen automatically by adding the +xmodmap command to the xdm setup script for that display. + +* C-z just refreshes the screen instead of suspending Emacs. + +You are probably using a shell that doesn't support job control, even +though the system itself is capable of it. Either use a different shell, +or set the variable `cannot-suspend' to a non-nil value. + +* Watch out for .emacs files and EMACSLOADPATH environment vars + +These control the actions of Emacs. +~/.emacs is your Emacs init file. +EMACSLOADPATH overrides which directories the function +"load" will search. + +If you observe strange problems, check for these and get rid +of them, then try again. + +* After running emacs once, subsequent invocations crash. + +Some versions of SVR4 have a serious bug in the implementation of the +mmap () system call in the kernel; this causes emacs to run correctly +the first time, and then crash when run a second time. + +Contact your vendor and ask for the mmap bug fix; in the mean time, +you may be able to work around the problem by adding a line to your +operating system description file (whose name is reported by the +configure script) that reads: +#define SYSTEM_MALLOC +This makes Emacs use memory less efficiently, but seems to work around +the kernel bug. + +* Inability to send an Alt-modified key, when Emacs is communicating +directly with an X server. + +If you have tried to bind an Alt-modified key as a command, and it +does not work to type the command, the first thing you should check is +whether the key is getting through to Emacs. To do this, type C-h c +followed by the Alt-modified key. C-h c should say what kind of event +it read. If it says it read an Alt-modified key, then make sure you +have made the key binding correctly. + +If C-h c reports an event that doesn't have the Alt modifier, it may +be because your X server has no key for the Alt modifier. The X +server that comes from MIT does not set up the Alt modifier by +default. + +If your keyboard has keys named Alt, you can enable them as follows: + + xmodmap -e 'add mod2 = Alt_L' + xmodmap -e 'add mod2 = Alt_R' + +If the keyboard has just one key named Alt, then only one of those +commands is needed. The modifier `mod2' is a reasonable choice if you +are using an unmodified MIT version of X. Otherwise, choose any +modifier bit not otherwise used. + +If your keyboard does not have keys named Alt, you can use some other +keys. Use the keysym command in xmodmap to turn a function key (or +some other 'spare' key) into Alt_L or into Alt_R, and then use the +commands show above to make them modifier keys. + +Note that if you have Alt keys but no Meta keys, Emacs translates Alt +into Meta. This is because of the great importance of Meta in Emacs. + +* `Pid xxx killed due to text modification or page I/O error' + +On HP/UX, you can get that error when the Emacs executable is on an NFS +file system. HP/UX responds this way if it tries to swap in a page and +does not get a response from the server within a timeout whose default +value is just ten seconds. + +If this happens to you, extend the timeout period. + +* `expand-file-name' fails to work on any but the machine you dumped Emacs on. + +On Ultrix, if you use any of the functions which look up information +in the passwd database before dumping Emacs (say, by using +expand-file-name in site-init.el), then those functions will not work +in the dumped Emacs on any host but the one Emacs was dumped on. + +The solution? Don't use expand-file-name in site-init.el, or in +anything it loads. Yuck - some solution. + +I'm not sure why this happens; if you can find out exactly what is +going on, and perhaps find a fix or a workaround, please let us know. +Perhaps the YP functions cache some information, the cache is included +in the dumped Emacs, and is then inaccurate on any other host. + +* On some variants of SVR4, Emacs does not work at all with X. + +Try defining BROKEN_FIONREAD in your config.h file. If this solves +the problem, please send a bug report to tell us this is needed; be +sure to say exactly what type of machine and system you are using. + +* Emacs fails to understand most Internet host names, even though +the names work properly with other programs on the same system. +* Emacs won't work with X-windows if the value of DISPLAY is HOSTNAME:0. +* GNUs can't make contact with the specified host for nntp. + +This typically happens on Suns and other systems that use shared +libraries. The cause is that the site has installed a version of the +shared library which uses a name server--but has not installed a +similar version of the unshared library which Emacs uses. + +The result is that most programs, using the shared library, work with +the nameserver, but Emacs does not. + +The fix is to install an unshared library that corresponds to what you +installed in the shared library, and then relink Emacs. + +On SunOS 4.1, simply define HAVE_RES_INIT. + +If you have already installed the name resolver in the file libresolv.a, +then you need to compile Emacs to use that library. The easiest way to +do this is to add to config.h a definition of LIBS_SYSTEM, LIBS_MACHINE +or LIB_STANDARD which uses -lresolv. Watch out! If you redefine a macro +that is already in use in your configuration to supply some other libraries, +be careful not to lose the others. + +Thus, you could start by adding this to config.h: + +#define LIBS_SYSTEM -lresolv + +Then if this gives you an error for redefining a macro, and you see that +the s- file defines LIBS_SYSTEM as -lfoo -lbar, you could change config.h +again to say this: + +#define LIBS_SYSTEM -lresolv -lfoo -lbar + +* On a Sun running SunOS 4.1.1, you get this error message from GNU ld: + + /lib/libc.a(_Q_sub.o): Undefined symbol __Q_get_rp_rd referenced from text segment + +The problem is in the Sun shared C library, not in GNU ld. + +The solution is to install Patch-ID# 100267-03 from Sun. + +* SunOS 4.1.2: undefined symbol _get_wmShellWidgetClass + + Apparently the version of libXmu.so.a that Sun ships is hosed: it's missing + some stuff that is in libXmu.a (the static version). Sun has a patch for + this, but a workaround is to use the static version of libXmu, by changing + the link command from "-lXmu" to "-Bstatic -lXmu -Bdynamic". If you have + OpenWindows 3.0, ask Sun for these patches: + 100512-02 4.1.x OpenWindows 3.0 libXt Jumbo patch + 100573-03 4.1.x OpenWindows 3.0 undefined symbols with shared libXmu + +* Random other SunOS 4.1.[12] link errors. + + The X headers and libraries that Sun ships in /usr/{include,lib}/X11 are + broken. Use the ones in /usr/openwin/{include,lib} instead. + +* Bus errors on startup when compiled with Sun's "acc" (in the routine + make_string_internal() called from initialize_environment_alist()) + + The Sun ANSI compiler doesn't place uninitialized static variables in BSS + space like other compilers do. This breaks emacs. If you want to use acc, + you need to make the file "lastfile.o" be the *first* file in the link + command. Better yet, use Lucid C or GCC. + +* The compiler generates lots and lots of syntax errors. + +Are you using an ANSI C compiler, like lcc or gcc? The SunOS 4.1 bundled cc +is not ANSI. + +If X has not been configured to compile itself using lcc, gcc, or another ANSI +compiler, then you will have to hack the automatically-generated makefile in +the `lwlib' directory by hand to make it use an ANSI compiler. + +* When using gcc, you get the error message "undefined symbol __fixunsdfsi". +* When using gcc, you get the error message "undefined symbol __main". + +This means that you need to link with the gcc library. It may be called +"gcc-gnulib" or "libgcc.a"; figure out where it is, and define LIB_GCC in +config.h to point to it. + +It may also work to use the GCC version of `ld' instead of the standard one. + +* When compiling with X11, you get "undefined symbol _XtStrings". + +This means that you are trying to link emacs against the X11r4 version of +libXt.a, but you have compiled either Emacs or the code in the lwlib +subdirectory with the X11r5 header files. That doesn't work. + +Remember, you can't compile lwlib for r4 and emacs for r5, or vice versa. +They must be in sync. + +* Self documentation messages are garbled. + +This means that the file `etc/DOC-...' doesn't properly correspond +with the Emacs executable. Redumping Emacs and then installing the +corresponding pair of files should fix the problem. + +* Trouble using ptys on AIX. + +People often install the pty devices on AIX incorrectly. +Use `smit pty' to reinstall them properly. + +* Shell mode on HP/UX gives the message, "`tty`: Ambiguous". + +christos@theory.tn.cornell.edu says: + +The problem is that in your .cshrc you have something that tries to +execute `tty`. If you are not running the shell on a real tty then +tty will print "not a tty". Csh expects one word in some places, +but tty is giving it back 3. + +The solution is to add a pair of quotes around `tty` to make it a single +word: + +if (`tty` == "/dev/console") + +should be changed to: + +if ("`tty`" == "/dev/console") + +Even better, move things that set up terminal sections out of .cshrc +and into .login. + +* With process-connection-type set to t, each line of subprocess output is + terminated with a ^M, making ange-ftp and GNUS not work. + +On SunOS systems, this problem has been seen to be a result of an incomplete +installation of gcc 2.2 which allowed some non-ANSI compatible include files +into the compilation. In particular this affected virtually all ioctl() calls. + +* Once you pull down a menu from the menubar, it won't go away. + +It has been claimed that this is caused by a bug in certain very old (1990?) +versions of the twm window manager. It doesn't happen with recent vintages, +or with other window managers. + +* Emacs ignores the "help" key when running OLWM. + +OLWM grabs the help key, and retransmits it to the appropriate client using +XSendEvent. Allowing emacs to react to synthetic events is a security hole, +so this is turned off by default. You can enable it by setting the variable +x-allow-sendevents to t. You can also cause fix this by telling OLWM to not +grab the help key, with the null binding "OpenWindows.KeyboardCommand.Help:". + +* Something awful happens when I type M-ESC, instead of `eval-expression'. + +MWM intercepts this and several other keys. Turn this off by adding this to +your resources: "mwm*keyBindings: NoKeyBindings". + +* Using X Windows, control-shift-leftbutton makes Emacs hang. + +Use the shell command `xset bc' to make the old X Menu package work. + +* Emacs running under X Windows does not handle mouse clicks. +* `emacs -geometry 80x20' finds a file named `80x20'. + +One cause of such problems is having (setq term-file-prefix nil) in +your .emacs file. Another cause is a bad value of EMACSLOADPATH in +the environment. + +* Emacs gets error message from linker on Sun. + +If the error message says that a symbol such as `f68881_used' or +`ffpa_used' or `start_float' is undefined, this probably indicates +that you have compiled some libraries, such as the X libraries, +with a floating point option other than the default. + +It's not terribly hard to make this work with small changes in +crt0.c together with linking with Fcrt1.o, Wcrt1.o or Mcrt1.o. +However, the easiest approach is to build Xlib with the default +floating point option: -fsoft to decide at run time what hardware +is available. + +* Keyboard input gets confused after a beep when using a DECserver + as a concentrator. + +This problem seems to be a matter of configuring the DECserver to use +7 bit characters rather than 8 bit characters. + +* M-x shell persistently reports "Process shell exited abnormally with code 1". + +This happened on Suns as a result of what is said to be a bug in Sunos +version 4.0.x. The only fix was to reboot the machine. + +* Programs running under terminal emulator do not recognize `emacs' + terminal type. + +The cause of this is a shell startup file that sets the TERMCAP +environment variable. The terminal emulator uses that variable to +provide the information on the special terminal type that Emacs +emulates. + +Rewrite your shell startup file so that it does not change TERMCAP +in such a case. You could use the following conditional which sets +it only if it is undefined. + + if ( ! ${?TERMCAP} ) setenv TERMCAP ~/my-termcap-file + +Or you could set TERMCAP only when you set TERM--which should not +happen in a non-login shell. + +* Problem with remote X server on Suns. + +On a Sun, running Emacs on one machine with the X server on another +may not work if you have used the unshared system libraries. This +is because the unshared libraries fail to use YP for host name lookup. +As a result, the host name you specify may not be recognized. + +* Shell mode ignores interrupts on Apollo Domain + +You may find that M-x shell prints the following message: + + Warning: no access to tty; thus no job control in this shell... + +This can happen if there are not enough ptys on your system. +Here is how to make more of them. + + % cd /dev + % ls pty* + # shows how many pty's you have. I had 8, named pty0 to pty7) + % /etc/crpty 8 + # creates eight new pty's + +* Fatal signal in the command temacs -l loadup inc dump + +This command is the final stage of building Emacs. It is run by the +Makefile in the src subdirectory, or by build.com on VMS. + +It has been known to get fatal errors due to insufficient swapping +space available on the machine. + +On 68000's, it has also happened because of bugs in the +subroutine `alloca'. Verify that `alloca' works right, even +for large blocks (many pages). + +* test-distrib says that the distribution has been clobbered +* or, temacs prints "Command key out of range 0-127" +* or, temacs runs and dumps xemacs, but xemacs totally fails to work. +* or, temacs gets errors dumping xemacs + +This can be because the .elc files have been garbled. Do not be +fooled by the fact that most of a .elc file is text: these are +binary files and can contain all 256 byte values. + +In particular `shar' cannot be used for transmitting GNU Emacs. +It typically truncates "lines". What appear to be "lines" in +a binary file can of course be of any length. Even once `shar' +itself is made to work correctly, `sh' discards null characters +when unpacking the shell archive. + +I have also seen character \177 changed into \377. I do not know +what transfer means caused this problem. Various network +file transfer programs are suspected of clobbering the high bit. + +If you have a copy of Emacs that has been damaged in its +nonprinting characters, you can fix them: + + 1) Record the names of all the .elc files. + 2) Delete all the .elc files. + 3) Recompile alloc.c with a value of PURESIZE twice as large. + You might as well save the old alloc.o. + 4) Remake xemacs. It should work now. + 5) Running xemacs, do Meta-x byte-compile-file repeatedly + to recreate all the .elc files that used to exist. + You may need to increase the value of the variable + max-lisp-eval-depth to succeed in running the compiler interpreted + on certain .el files. 400 was sufficient as of last report. + 6) Reinstall the old alloc.o (undoing changes to alloc.c if any) + and remake temacs. + 7) Remake xemacs. It should work now, with valid .elc files. + +* temacs prints "Pure Lisp storage exhausted" + +This means that the Lisp code loaded from the .elc and .el +files during temacs -l loadup inc dump took up more +space than was allocated. + +This could be caused by + 1) adding code to the preloaded Lisp files + 2) adding more preloaded files in loadup.el + 3) having a site-init.el or site-load.el which loads files. + Note that ANY site-init.el or site-load.el is nonstandard; + if you have received Emacs from some other site + and it contains a site-init.el or site-load.el file, consider + deleting that file. + 4) getting the wrong .el or .elc files + (not from the directory you expected). + 5) deleting some .elc files that are supposed to exist. + This would cause the source files (.el files) to be + loaded instead. They take up more room, so you lose. + 6) a bug in the Emacs distribution which underestimates + the space required. + +If the need for more space is legitimate, use the --puresize option +to `configure' to specify more pure space. + +But in some of the cases listed above, this problem is a consequence +of something else that is wrong. Be sure to check and fix the real +problem. + +* Changes made to .el files do not take effect. + +You may have forgotten to recompile them into .elc files. +Then the old .elc files will be loaded, and your changes +will not be seen. To fix this, do M-x byte-recompile-directory +and specify the directory that contains the Lisp files. + +Note that you may get a warning when loading a .elc file that +is older than the corresponding .el file. + +* Things which should be bold or italic (such as the initial copyright notice) + are not. + +The fonts of the "bold" and "italic" faces are generated from the font of +the "default" face; in this way, your bold and italic fonts will have the +appropriate size and family. However, emacs can only be clever in this +way if you have specified the default font using the XLFD (X Logical Font +Description) format, which looks like + + *-courier-medium-r-*-*-*-120-*-*-*-*-*-* + +if you use any of the other, less strict font name formats, some of which +look like + lucidasanstypewriter-12 +and fixed +and 9x13 + +then emacs won't be able to guess the names of the "bold" and "italic" +versions. All X fonts can be referred to via XLFD-style names, so you +should use those forms. See the man pages for X(1), xlsfonts(1), and +xfontsel(1). + +* The dumped Emacs (xemacs) crashes when run, trying to write pure data. + +Two causes have been seen for such problems. + +1) On a system where getpagesize is not a system call, it is defined +as a macro. If the definition (in both unexec.c and malloc.c) is wrong, +it can cause problems like this. You might be able to find the correct +value in the man page for a.out (5). + +2) Some systems allocate variables declared static among the +initialized variables. Emacs makes all initialized variables in most +of its files pure after dumping, but the variables declared static and +not initialized are not supposed to be pure. On these systems you +may need to add "#define static" to the m- or the s- file. + +* Reading and writing files is very very slow. + +Try evaluating the form (setq lock-directory nil) and see if that helps. +There is a problem with file-locking on some systems (possibly related +to NFS) that I don't understand. Please send mail to the address +xemacs@xemacs.org if you figure this one out. + +* Compilation errors on VMS. + +Sorry, XEmacs does not work under VMS. You might consider working on +the port if you really want to have XEmacs work under VMS. + +* "Symbol's value as variable is void: unread-command-char". +* "Wrong type argument: arrayp, #<keymap 143 entries>" +* "Wrong type argument: stringp, [#<keypress-event return>]" + +There are a few incompatible changes in XEmacs, and these are the +symptoms. Some of the emacs-lisp code you are running needs to be +updated to be compatible with XEmacs. + +We have provided modified versions of several popular emacs packages (GNUS, +VM, etc) which are compatible with this version of emacs. Check to make +sure you have not set your load-path so that your private copies of these +packages are being found before the versions in the lisp directory. + +Make sure that your load-path and your $EMACSLOADPATH environment variable +are not pointing at an Emacs18 lisp directory. This will cripple emacs. + +* rmail or VM gets error getting new mail + +rmail and VM get new mail from /usr/spool/mail/$USER using a program +called `movemail'. This program interlocks with /bin/mail using +the protocol defined by /bin/mail. + +There are two different protocols in general use. One of them uses +the `flock' system call. The other involves creating a lock file; +`movemail' must be able to write in /usr/spool/mail in order to do +this. You control which one is used by defining, or not defining, +the macro MAIL_USE_FLOCK in config.h or the m- or s- file it includes. +IF YOU DON'T USE THE FORM OF INTERLOCKING THAT IS NORMAL ON YOUR +SYSTEM, YOU CAN LOSE MAIL! + +If your system uses the lock file protocol, and fascist restrictions +prevent ordinary users from writing the lock files in /usr/spool/mail, +you may need to make `movemail' setgid to a suitable group such as +`mail'. You can use these commands (as root): + + chgrp mail movemail + chmod 2755 movemail + +If your system uses the lock file protocol, and fascist restrictions +prevent ordinary users from writing the lock files in /usr/spool/mail, +you may need to make `movemail' setgid to a suitable group such as +`mail'. To do this, use the following commands (as root) after doing the +make install. + + chgrp mail movemail + chmod 2755 movemail + +Installation normally copies movemail from the build directory to an +installation directory which is usually under /usr/local/lib. The +installed copy of movemail is usually in the directory +/usr/local/lib/emacs/VERSION/TARGET. You must change the group and +mode of the installed copy; changing the group and mode of the build +directory copy is ineffective. + +* Emacs spontaneously displays "I-search: " at the bottom of the screen. + +This means that Control-S/Control-Q (XON/XOFF) "flow control" is being +used. C-s/C-q flow control is bad for Emacs editors because it takes +away C-s and C-q as user commands. Since editors do not output long +streams of text without user commands, there is no need for a +user-issuable "stop output" command in an editor; therefore, a +properly designed flow control mechanism would transmit all possible +input characters without interference. Designing such a mechanism is +easy, for a person with at least half a brain. + +There are three possible reasons why flow control could be taking place: + + 1) Terminal has not been told to disable flow control + 2) Insufficient padding for the terminal in use + 3) Some sort of terminal concentrator or line switch is responsible + +First of all, many terminals have a set-up mode which controls whether +they generate XON/XOFF flow control characters. This must be set to +"no XON/XOFF" in order for Emacs to work. Sometimes there is an +escape sequence that the computer can send to turn flow control off +and on. If so, perhaps the termcap `ti' string should turn flow +control off, and the `te' string should turn it on. + +Once the terminal has been told "no flow control", you may find it +needs more padding. The amount of padding Emacs sends is controlled +by the termcap entry for the terminal in use, and by the output baud +rate as known by the kernel. The shell command `stty' will print +your output baud rate; `stty' with suitable arguments will set it if +it is wrong. Setting to a higher speed causes increased padding. If +the results are wrong for the correct speed, there is probably a +problem in the termcap entry. You must speak to a local Unix wizard +to fix this. Perhaps you are just using the wrong terminal type. + +For terminals that lack a "no flow control" mode, sometimes just +giving lots of padding will prevent actual generation of flow control +codes. You might as well try it. + +If you are really unlucky, your terminal is connected to the computer +through a concentrator which sends XON/XOFF flow control to the +computer, or it insists on sending flow control itself no matter how +much padding you give it. Unless you can figure out how to turn flow +control off on this concentrator (again, refer to your local wizard), +you are screwed! You should have the terminal or concentrator +replaced with a properly designed one. In the mean time, some drastic +measures can make Emacs semi-work. + +You can make Emacs ignore C-s and C-q and let the operating system +handle them. To do this on a per-session basis, just type M-x +enable-flow-control RET. You will see a message that C-\ and C-^ are +now translated to C-s and C-q. (Use the same command M-x +enable-flow-control to turn *off* this special mode. It toggles flow +control handling.) + +If C-\ and C-^ are inconvenient for you (for example, if one of them +is the escape character of your terminal concentrator), you can choose +other characters by setting the variables flow-control-c-s-replacement +and flow-control-c-q-replacement. But choose carefully, since all +other control characters are already used by emacs. + +IMPORTANT: if you type C-s by accident while flow control is enabled, +Emacs output will freeze, and you will have to remember to type C-q in +order to continue. + +If you work in an environment where a majority of terminals of a +certain type are flow control hobbled, you can use the function +`enable-flow-control-on' to turn on this flow control avoidance scheme +automatically. Here is an example: + +(enable-flow-control-on "vt200" "vt300" "vt101" "vt131") + +If this isn't quite correct (e.g. you have a mixture of flow-control hobbled +and good vt200 terminals), you can still run enable-flow-control +manually. + +I have no intention of ever redesigning the Emacs command set for the +assumption that terminals use C-s/C-q flow control. XON/XOFF flow +control technique is a bad design, and terminals that need it are bad +merchandise and should not be purchased. Now that X is becoming +widespread, XON/XOFF seems to be on the way out. If you can get some +use out of GNU Emacs on inferior terminals, more power to you, but I +will not make Emacs worse for properly designed systems for the sake +of inferior systems. + +* Control-S and Control-Q commands are ignored completely. + +For some reason, your system is using brain-damaged C-s/C-q flow +control despite Emacs's attempts to turn it off. Perhaps your +terminal is connected to the computer through a concentrator +that wants to use flow control. + +You should first try to tell the concentrator not to use flow control. +If you succeed in this, try making the terminal work without +flow control, as described in the preceding section. + +If that line of approach is not successful, map some other characters +into C-s and C-q using keyboard-translate-table. The example above +shows how to do this with C-^ and C-\. + +* Control-S and Control-Q commands are ignored completely on a net connection. + +Some versions of rlogin (and possibly telnet) do not pass flow +control characters to the remote system to which they connect. +On such systems, emacs on the remote system cannot disable flow +control on the local system. + +One way to cure this is to disable flow control on the local host +(the one running rlogin, not the one running rlogind) using the +stty command, before starting the rlogin process. On many systems, +"stty start u stop u" will do this. + +Some versions of tcsh will prevent even this from working. One way +around this is to start another shell before starting rlogin, and +issue the stty command to disable flow control from that shell. + +If none of these methods work, the best solution is to type +M-x enable-flow-control at the beginning of your emacs session, or +if you expect the problem to continue, add a line such as the +following to your .emacs (on the host running rlogind): + +(enable-flow-control-on "vt200" "vt300" "vt101" "vt131") + +See the entry about spontaneous display of I-search (above) for more +info. + +* Screen is updated wrong, but only on one kind of terminal. + +This could mean that the termcap entry you are using for that +terminal is wrong, or it could mean that Emacs has a bug handing +the combination of features specified for that terminal. + +The first step in tracking this down is to record what characters +Emacs is sending to the terminal. Execute the Lisp expression +(open-termscript "./emacs-script") to make Emacs write all +terminal output into the file ~/emacs-script as well; then do +what makes the screen update wrong, and look at the file +and decode the characters using the manual for the terminal. +There are several possibilities: + +1) The characters sent are correct, according to the terminal manual. + +In this case, there is no obvious bug in Emacs, and most likely you +need more padding, or possibly the terminal manual is wrong. + +2) The characters sent are incorrect, due to an obscure aspect + of the terminal behavior not described in an obvious way + by termcap. + +This case is hard. It will be necessary to think of a way for +Emacs to distinguish between terminals with this kind of behavior +and other terminals that behave subtly differently but are +classified the same by termcap; or else find an algorithm for +Emacs to use that avoids the difference. Such changes must be +tested on many kinds of terminals. + +3) The termcap entry is wrong. + +See the file etc/TERMS for information on changes +that are known to be needed in commonly used termcap entries +for certain terminals. + +4) The characters sent are incorrect, and clearly cannot be + right for any terminal with the termcap entry you were using. + +This is unambiguously an Emacs bug, and can probably be fixed +in termcap.c, tparam.c, term.c, scroll.c, cm.c or dispnew.c. + +* Output from Control-V is slow. + +On many bit-map terminals, scrolling operations are fairly slow. +Often the termcap entry for the type of terminal in use fails +to inform Emacs of this. The two lines at the bottom of the screen +before a Control-V command are supposed to appear at the top after +the Control-V command. If Emacs thinks scrolling the lines is fast, +it will scroll them to the top of the screen. + +If scrolling is slow but Emacs thinks it is fast, the usual reason is +that the termcap entry for the terminal you are using does not +specify any padding time for the `al' and `dl' strings. Emacs +concludes that these operations take only as much time as it takes to +send the commands at whatever line speed you are using. You must +fix the termcap entry to specify, for the `al' and `dl', as much +time as the operations really take. + +Currently Emacs thinks in terms of serial lines which send characters +at a fixed rate, so that any operation which takes time for the +terminal to execute must also be padded. With bit-map terminals +operated across networks, often the network provides some sort of +flow control so that padding is never needed no matter how slow +an operation is. You must still specify a padding time if you want +Emacs to realize that the operation takes a long time. This will +cause padding characters to be sent unnecessarily, but they do +not really cost much. They will be transmitted while the scrolling +is happening and then discarded quickly by the terminal. + +Most bit-map terminals provide commands for inserting or deleting +multiple lines at once. Define the `AL' and `DL' strings in the +termcap entry to say how to do these things, and you will have +fast output without wasted padding characters. These strings should +each contain a single %-spec saying how to send the number of lines +to be scrolled. These %-specs are like those in the termcap +`cm' string. + +You should also define the `IC' and `DC' strings if your terminal +has a command to insert or delete multiple characters. These +take the number of positions to insert or delete as an argument. + +A `cs' string to set the scrolling region will reduce the amount +of motion you see on the screen when part of the screen is scrolled. + +* Your Delete key sends a Backspace to the terminal, using an AIXterm. + +The solution is to include in your .Xdefaults the lines: + + *aixterm.Translations: #override <Key>BackSpace: string(0x7f) + aixterm*ttyModes: erase ^? + +This makes your Backspace key send DEL (ASCII 127). + +* You type Control-H (Backspace) expecting to delete characters. + +Emacs has traditionally used Control-H for help; unfortunately +this interferes with its use as Backspace on TTY's. This has not +been fixed due to an incredible arrogance on RMS's part. One way +to solve this problem is to put this in your .emacs: + + (global-set-key "\b" 'delete-backward-char) + (global-set-key "\M-h" 'help-command) + +This makes Control-H (Backspace) work sensibly, and moves help to +Meta-H (ESC H). + +Note that you can probably also access help using F1. + +* Editing files through RFS gives spurious "file has changed" warnings. +It is possible that a change in Emacs 18.37 gets around this problem, +but in case not, here is a description of how to fix the RFS bug that +causes it. + + There was a serious pair of bugs in the handling of the fsync() system + call in the RFS server. + + The first is that the fsync() call is handled as another name for the + close() system call (!!). It appears that fsync() is not used by very + many programs; Emacs version 18 does an fsync() before closing files + to make sure that the bits are on the disk. + + This is fixed by the enclosed patch to the RFS server. + + The second, more serious problem, is that fsync() is treated as a + non-blocking system call (i.e., it's implemented as a message that + gets sent to the remote system without waiting for a reply). Fsync is + a useful tool for building atomic file transactions. Implementing it + as a non-blocking RPC call (when the local call blocks until the sync + is done) is a bad idea; unfortunately, changing it will break the RFS + protocol. No fix was supplied for this problem. + + (as always, your line numbers may vary) + + % rcsdiff -c -r1.2 serversyscall.c + RCS file: RCS/serversyscall.c,v + retrieving revision 1.2 + diff -c -r1.2 serversyscall.c + *** /tmp/,RCSt1003677 Wed Jan 28 15:15:02 1987 + --- serversyscall.c Wed Jan 28 15:14:48 1987 + *************** + *** 163,169 **** + /* + * No return sent for close or fsync! + */ + ! if (syscall == RSYS_close || syscall == RSYS_fsync) + proc->p_returnval = deallocate_fd(proc, msg->m_args[0]); + else + { + --- 166,172 ---- + /* + * No return sent for close or fsync! + */ + ! if (syscall == RSYS_close) + proc->p_returnval = deallocate_fd(proc, msg->m_args[0]); + else + { + +* Vax C compiler bugs affecting Emacs. + +You may get one of these problems compiling Emacs: + + foo.c line nnn: compiler error: no table entry for op STASG + foo.c: fatal error in /lib/ccom + +These are due to bugs in the C compiler; the code is valid C. +Unfortunately, the bugs are unpredictable: the same construct +may compile properly or trigger one of these bugs, depending +on what else is in the source file being compiled. Even changes +in header files that should not affect the file being compiled +can affect whether the bug happens. In addition, sometimes files +that compile correctly on one machine get this bug on another machine. + +As a result, it is hard for me to make sure this bug will not affect +you. I have attempted to find and alter these constructs, but more +can always appear. However, I can tell you how to deal with it if it +should happen. The bug comes from having an indexed reference to an +array of Lisp_Objects, as an argument in a function call: + Lisp_Object *args; + ... + ... foo (5, args[i], ...)... +putting the argument into a temporary variable first, as in + Lisp_Object *args; + Lisp_Object tem; + ... + tem = args[i]; + ... foo (r, tem, ...)... +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 + +Various 68000 compilers have different problems. +These are some that have been observed. + +** Using value of assignment expression on union type loses. +This means that x = y = z; or foo (x = z); does not work +if x is of type Lisp_Object. + +** "cannot reclaim" error. + +This means that an expression is too complicated. You get the correct +line number in the error message. The code must be rewritten with +simpler expressions. + +** XCONS, XSTRING, etc macros produce incorrect code. + +If temacs fails to run at all, this may be the cause. +Compile this test program and look at the assembler code: + +struct foo { char x; unsigned int y : 24; }; + +lose (arg) + struct foo arg; +{ + test ((int *) arg.y); +} + +If the code is incorrect, your compiler has this problem. +In the XCONS, etc., macros in lisp.h you must replace (a).u.val with +((a).u.val + coercedummy) where coercedummy is declared as int. + +This problem will not happen if the m-...h file for your type +of machine defines NO_UNION_TYPE. That is the recommended setting now. + +* C compilers lose on returning unions + +I hear that some C compilers cannot handle returning a union type. +Most of the functions in GNU Emacs return type Lisp_Object, which is +defined as a union on some rare architectures. + +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.