problems

早期freebsd实现

give it.  You are screwed!  You should replace the terminal or
concentrator with a properly designed one.  In the mean time,
some drastic measures can make Emacs semi-work.

One drastic measure to ignore C-s and C-q, while sending enough
padding that the terminal will not really lose any output.
Ignoring C-s and C-q can be done by using keyboard-translate-table
to map them into an undefined character such as C-^ or C-\.  Sending
lots of padding is done by changing the termcap entry.  Here is how
to make such a keyboard-translate-table:

    (let ((the-table (make-string 128 0)))
      ;; Default is to translate each character into itself.
      (let ((i 0))
	(while (< i 128)
	  (aset the-table i i)
	  (setq i (1+ i))))
      ;; Swap C-s with C-\
      (aset the-table ?\C-\\ ?\C-s)
      (aset the-table ?\C-s ?\C-\\)
      ;; Swap C-q with C-^
      (aset the-table ?\C-^ ?\C-q)
      (aset the-table ?\C-q ?\C-^)
      (setq keyboard-translate-table the-table))

An even more drastic measure is to make Emacs use flow control.
To do this, evaluate the Lisp expression (set-input-mode nil t).
Emacs will then interpret C-s and C-q as flow control commands.  (More
precisely, it will allow the kernel to do so as it usually does.)  You
will lose the ability to use them for Emacs commands.  Also, as a
consequence of using CBREAK mode, the terminal's Meta-key, if any,
will not work, and C-g will be liable to cause a loss of output which
will produce garbage on the screen.  (These problems apply to 4.2BSD;
they may not happen in 4.3 or VMS, and I don't know what would happen
in sysV.)  You can use keyboard-translate-table, as shown above,
to map two other input characters (such as C-^ and C-\) into C-s and
C-q, so that you can still search and quote.

I have no intention of ever redisigning the Emacs command set for
the assumption that terminals use C-s/C-q flow control.  This
flow control technique is a bad design, and terminals that need
it are bad merchandise and should not be purchased.  If you can
get some use out of GNU Emacs on inferior terminals, I am glad,
but I will not make Emacs worse for properly designed systems
for the sake of inferior systems.

* Control-S and Control-Q commands are ignored completely.

For some reason, your system is using brain-damaged C-s/C-q flow
control despite Emacs's attempts to turn it off.  Perhaps your
terminal is connected to the computer through a concentrator
that wants to use flow control.

You should first try to tell the concentrator not to use flow control.
If you succeed in this, try making the terminal work without
flow control, as described in the preceding section.

If that line of approach is not successful, map some other characters
into C-s and C-q using keyboard-translate-table.  The example above
shows how to do this with C-^ and C-\.

* Screen is updated wrong, but only on one kind of terminal.

This could mean that the termcap entry you are using for that
terminal is wrong, or it could mean that Emacs has a bug handing
the combination of features specified for that terminal.

The first step in tracking this down is to record what characters
Emacs is sending to the terminal.  Execute the Lisp expression
(open-termscript "./emacs-script") to make Emacs write all
terminal output into the file ~/emacs-script as well; then do
what makes the screen update wrong, and look at the file
and decode the characters using the manual for the terminal.
There are several possibilities:

1) The characters sent are correct, according to the terminal manual.

In this case, there is no obvious bug in Emacs, and most likely you
need more padding, or possibly the terminal manual is wrong.

2) The characters sent are incorrect, due to an obscure aspect
 of the terminal behavior not described in an obvious way
 by termcap.

This case is hard.  It will be necessary to think of a way for
Emacs to distinguish between terminals with this kind of behavior
and other terminals that behave subtly differently but are
classified the same by termcap; or else find an algorithm for
Emacs to use that avoids the difference.  Such changes must be
tested on many kinds of terminals.

3) The termcap entry is wrong.

See the file etc/TERMS for information on changes
that are known to be needed in commonly used termcap entries
for certain terminals.

4) The characters sent are incorrect, and clearly cannot be
 right for any terminal with the termcap entry you were using.

This is unambiguously an Emacs bug, and can probably be fixed
in termcap.c, tparam.c, term.c, scroll.c, cm.c or dispnew.c.

* Output from Control-V is slow.

On many bit-map terminals, scrolling operations are fairly slow.
Often the termcap entry for the type of terminal in use fails
to inform Emacs of this.  The two lines at the bottom of the screen
before a Control-V command are supposed to appear at the top after
the Control-V command.  If Emacs thinks scrolling the lines is fast,
it will scroll them to the top of the screen.

If scrolling is slow but Emacs thinks it is fast, the usual reason is
that the termcap entry for the terminal you are using does not
specify any padding time for the `al' and `dl' strings.  Emacs
concludes that these operations take only as much time as it takes to
send the commands at whatever line speed you are using.  You must
fix the termcap entry to specify, for the `al' and `dl', as much
time as the operations really take.

Currently Emacs thinks in terms of serial lines which send characters
at a fixed rate, so that any operation which takes time for the
terminal to execute must also be padded.  With bit-map terminals
operated across networks, often the network provides some sort of
flow control so that padding is never needed no matter how slow
an operation is.  You must still specify a padding time if you want
Emacs to realize that the operation takes a long time.  This will
cause padding characters to be sent unnecessarily, but they do
not really cost much.  They will be transmitted while the scrolling
is happening and then discarded quickly by the terminal.

Most bit-map terminals provide commands for inserting or deleting
multiple lines at once.  Define the `AL' and `DL' strings in the
termcap entry to say how to do these things, and you will have
fast output without wasted padding characters.  These strings should
each contain a single %-spec saying how to send the number of lines
to be scrolled.  These %-specs are like those in the termcap
`cm' string.

You should also define the `IC' and `DC' strings if your terminal
has a command to insert or delete multiple characters.  These
take the number of positions to insert or delete as an argument.

A `cs' string to set the scrolling region will reduce the amount
of motion you see on the screen when part of the screen is scrolled.

* You type Control-H (Backspace) expecting to delete characters.

Put `stty dec' in your .login file and your problems will disappear
after a day or two.

The choice of Backspace for erasure was based on confusion, caused by
the fact that backspacing causes erasure (later, when you type another
character) on most display terminals.  But it is a mistake.  Deletion
of text is not the same thing as backspacing followed by failure to
overprint.  I do not wish to propagate this confusion by conforming
to it.

For this reason, I believe `stty dec' is the right mode to use,
and I have designed Emacs to go with that.  If there were a thousand
other control characters, I would define Control-h to delete as well;
but there are not very many other control characters, and I think
that providing the most mnemonic possible Help character is more
important than adapting to people who don't use `stty dec'.

If you are obstinate about confusing buggy overprinting with deletion,
you can redefine Backspace in your .emacs file:
  (global-set-key "\b" 'delete-backward-char)
You may then wish to put the function  help-command  on some
other key.  I leave to you the task of deciding which key.

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

* ld complains because `alloca' is not defined on your system.

Alloca is a library function in 4.2bsd, which is used very heavily by
GNU Emacs.  Use of malloc instead is very difficult, as you would have
to arrange for the storage to be freed, and do so even in the case of
a longjmp happening inside a subroutine.  Many subroutines in Emacs
can do longjmp.

If your system does not support alloca, try defining the symbol
C_ALLOCA in the m-...h file for that machine.  This will enable the use
in Emacs of a portable simulation for alloca.  But you will find that
Emacs's performance and memory use improve if you write a true
alloca in assembler language.

alloca (N) should return the address of an N-byte block of memory
added dynamically to the current stack frame.

* 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 currently defined as a union.

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.