xemacs-beta: PROBLEMS comparison

comparison 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

comparison

equal deleted inserted replaced

--1:000000000000
+:376386a54a3c
+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.

Mercurial > hg > xemacs-beta

comparison PROBLEMS @ 0:376386a54a3c r19-14