problems

早期freebsd实现

This file describes various problems that have been encountered
in compiling, installing and running GNU Emacs.

* Emacs fails to get default settings from X Windows server.

The X library in X11R4 has a bug; it interchanges the 2nd and 3rd
arguments to XGetDefaults.  Define the macro XBACKWARDS in config.h to
tell Emacs to compensate for this.

I don't believe there is any way Emacs can determine for itself
whether this problem is present on a given system.

* Keyboard input gets confused after a beep when using a DECserver
  as a concentrator.

This problem seems to be a matter of configuring the DECserver to use
7 bit characters rather than 8 bit characters.

* M-x shell persistently reports "Process shell exited abnormally with code 1".

This happened on Suns as a result of what is said to be a bug in Sunos
version 4.0.x.  The only fix was to reboot the machine. 

* Programs running under terminal emulator do not recognize `emacs'
  terminal type.

The cause of this is a shell startup file that sets the TERMCAP
environment variable.  The terminal emulator uses that variable to
provide the information on the special terminal type that Emacs
emulates.

Rewrite your shell startup file so that it does not change TERMCAP
in such a case.  You could use the following conditional which sets
it only if it is undefined.

    if ( ! ${?TERMCAP} ) setenv TERMCAP ~/my-termcap-file

Or you could set TERMCAP only when you set TERM--which should not
happen in a non-login shell.

* Error compiling sysdep.c, "sioctl.h: no such file or directory".

Among USG systems with TIOCGWINSZ, some require sysdep.c to include
the file sioctl.h; on others, sioctl.h does not exist.  We don't know
how to distinguish these two kind of systems, so currently we try to
include sioctl.h on all of them.  If this #include gets an error, just
delete it.

* X Windows doesn't work if DISPLAY uses a hostname.

People have reported kernel bugs in certain systems that cause Emacs
not to work with X Windows if DISPLAY is set using a host name.  But
the problem does not occur if DISPLAY is set to `unix:0.0'.  I think
the bug has to do with SIGIO or FIONREAD.

You may be able to compensate for the bug by doing (set-input-mode nil nil).
However, that has the disadvantage of turning off interrupts, so that
you are unable to quit out of a Lisp program by typing C-g.

The easy way to do this is to put 

  (setq x-sigio-bug t)

in your site-init.el file.

* Problem with remote X server on Suns.

On a Sun, running Emacs on one machine with the X server on another
may not work if you have used the unshared system libraries.  This
is because the unshared libraries fail to use YP for host name lookup.
As a result, the host name you specify may not be recognized.

* Copying text between Emacs and Xterm windows fails in X11R3 or X11R4.

According to Thomas Narten:
Most X clients now use selections instead of (well, superceding) cut buffers.
If there is a selection around, Xterms will use that instead of the cut
buffer.  Emacs doesn't know about selections, but you can convince Xterm to
always use the cut buffer instead of selections by adding this to you
.Xdefaults: 

! emacs only copies to cut buffer 0.  xterm by default 
! wants to paste from the PRIMARY selection 
XTerm*VT100.Translations: #override ~Meta <Btn2Up>: insert-selection(CUT_BUFFER0)

(Emacs 19 has been changed to use selections.)

* 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.

* 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.

The only verified ways to transfer GNU Emacs are `tar', kermit (in
binary mode on Unix), and rcp or internet ftp between two Unix systems,
or chaosnet cftp using raw mode.

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, change the definition
of PURESIZE in config.h.

But in some of the cases listed above, this problem is a consequence
of something else that is wrong.  Be sure to check and fix the real
problem.

* Changes made to .el files do not take effect.

You may have forgotten to recompile them into .elc files.
Then the old .elc files will be loaded, and your changes
will not be seen.  To fix this, do M-x byte-recompile-directory
and specify the directory that contains the Lisp files.

* 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.

* Compilation errors on VMS.

You will get warnings when compiling on VMS because there are
variable names longer than 32 (or whatever it is) characters.
This is not an error.  Ignore it.

VAX C does not support #if defined(foo).  Uses of this construct
were removed, but some may have crept back in.  They must be rewritten.

There is a bug in the C compiler which fails to sign extend characters
in conditional expressions.  The bug is:
	char c = -1, d = 1;
	int i;

	i = d ? c : d;
The result is i == 255;  the fix is to typecast the char in the
conditional expression as an (int).  Known occurrences of such
constructs in Emacs have been fixed.

* rmail gets error getting new mail

rmail gets new mail from /usr/spool/mail/$USER using a program
called `movemail'.  This program interlocks with /bin/mail using
the protocol defined by /bin/mail.

There are two different protocols in general use.  One of them uses
the `flock' system call.  The other involves creating a lock file;
`movemail' must be able to write in /usr/spool/mail in order to do
this.  You control which one is used by defining, or not defining,
the macro MAIL_USE_FLOCK in config.h or the m- or s- file it includes.
IF YOU DON'T USE THE FORM OF INTERLOCKING THAT IS NORMAL ON YOUR
SYSTEM, YOU CAN LOSE MAIL!

If your system uses the lock file protocol, and fascist restrictions
prevent ordinary users from writing the lock files in /usr/spool/mail,
you may need to make `movemail' setgid to a suitable group such as
`mail'.  You can use these commands (as root):

	chgrp mail movemail
	chmod 2755 movemail

* Emacs won't work with X-windows if the value of DISPLAY is HOSTNAME:0.

Some people have found that Emacs was unable to connect to the local
host by name, as in DISPLAY=prep:0 if you are running on prep, but
could handle DISPLAY=unix:0.  Here is what [e-mail] said:

      Seems as
    though gethostbyname was bombing somewhere along the way.  Well, we
    had just upgrade from SunOS 3.5 (which X11 was built under) to SunOS
    4.0.1.  Any new X applications which tried to be built with the pre
    OS-upgrade libraries had the same problems which Emacs was having.
    Missing /etc/resolv.conf for a little while (when one of the libraries
    was built?) also might have had a hand in it.

    The result of all of this (with some speculation) was that we rebuilt
    X and then rebuilt Emacs with the new libraries.  Works as it should
    now.  Hoorah.

* Emacs spontaneously displays "I-search: " at the bottom of the screen.

This means that Control-S/Control-Q "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 flow control characters.  This must be
set to "no flow control" 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 flow control to the computer, or it
insists on sending flow control itself no matter how much padding you