problems

windows版本的emacs

   Unable to load color "grey95"

(typically, in the `*Messages*' buffer), or something like this:

  Error while displaying tooltip: (error Undefined color lightyellow)

These problems could happen if some other X program has used up too
many colors of the X palette, leaving Emacs with insufficient system
resources to load all the colors it needs.

A solution is to exit the offending X programs before starting Emacs.

* Colors are not available on a tty or in xterm.

Emacs 21 supports colors on character terminals and terminal
emulators, but this support relies on the terminfo or termcap database
entry to specify that the display supports color.  Emacs looks at the
"Co" capability for the terminal to find out how many colors are
supported; it should be non-zero to activate the color support within
Emacs.  (Most color terminals support 8 or 16 colors.)  If your system
uses terminfo, the name of the capability equivalent to "Co" is
"colors".

In addition to the "Co" capability, Emacs needs the "op" (for
``original pair'') capability, which tells how to switch the terminal
back to the default foreground and background colors.  Emacs will not
use colors if this capability is not defined.  If your terminal entry
doesn't provide such a capability, try using the ANSI standard escape
sequence \E[00m (that is, define a new termcap/terminfo entry and make
it use your current terminal's entry plus \E[00m for the "op"
capability).

Finally, the "NC" capability (terminfo name: "ncv") tells Emacs which
attributes cannot be used with colors.  Setting this capability
incorrectly might have the effect of disabling colors; try setting
this capability to `0' (zero) and see if that helps.

Emacs uses the database entry for the terminal whose name is the value
of the environment variable TERM.  With `xterm', a common terminal
entry that supports color is `xterm-color', so setting TERM's value to
`xterm-color' might activate the color support on an xterm-compatible
emulator.

Some modes do not use colors unless you turn on the Font-lock mode.
Some people have long ago set their `~/.emacs' files to turn on
Font-lock on X only, so they won't see colors on a tty.  The
recommended way of turning on Font-lock is by typing "M-x
global-font-lock-mode RET" or by customizing the variable
`global-font-lock-mode'.

* Emacs on a tty switches the cursor to large blinking block.

This was reported to happen on some GNU/Linux systems which use
ncurses version 5.0, but could be relevant for other versions as well.
These versions of ncurses come with a `linux' terminfo entry, where
the "cvvis" capability (termcap "vs") is defined as "\E[?25h\E[?8c"
(show cursor, change size).  This escape sequence switches on a
blinking hardware text-mode cursor whose size is a full character
cell.  This blinking cannot be stopped, since a hardware cursor
always blinks.

A work-around is to redefine the "cvvis" capability so that it
enables a *software* cursor.  The software cursor works by inverting
the colors of the character at point, so what you see is a block
cursor that doesn't blink.  For this to work, you need to redefine
the "cnorm" capability as well, so that it operates on the software
cursor instead of the hardware cursor.

To this end, run "infocmp linux > linux-term", edit the file
`linux-term' to make both the "cnorm" and "cvvis" capabilities send
the sequence "\E[?25h\E[?17;0;64c", and then run "tic linux-term" to
produce a modified terminfo entry.

* Problems in Emacs built with LessTif.

The problems seem to depend on the version of LessTif and the Motif
emulation for which it is set up.

Only the Motif 1.2 emulation seems to be stable enough in LessTif.
Lesstif 0.92-17's Motif 1.2 emulation seems to work okay on FreeBSD.
On GNU/Linux systems, lesstif-0.92.6 configured with "./configure
--enable-build-12 --enable-default-12" is reported to be the most
successful.  The binary GNU/Linux package
lesstif-devel-0.92.0-1.i386.rpm was reported to have problems with
menu placement.

On some systems, even with Motif 1.2 emulation, Emacs occasionally
locks up, grabbing all mouse and keyboard events.  We still don't know
what causes these problems; they are not reproducible by Emacs
developers.

* Known problems with the MS-Windows port of Emacs 21.2.

Emacs 21.2 built for MS-Windows doesn't support images, the tool bar,
and tooltips.  Support for these will be added in future versions.

Help text that is displayed in a tooltip on other window systems, on
Windows is printed in the echo area, since tooltips are not yet
available.

Frames are not refreshed while the File or Font dialog or a pop-up menu
is displayed. This also means help text for pop-up menu items is not
displayed at all.  This is because message handling under Windows is
synchronous, so we cannot handle repaint (or any other) messages while
waiting for a system function to return the result of the dialog or
pop-up menu interaction.

There are problems with display if mouse-tracking is enabled and the
mouse is moved off a frame, over another frame then back over the first
frame.  A workaround is to click the left mouse button inside the frame
after moving back into it.

Some minor flickering still persists during mouse-tracking, although
not as severely as in 21.1.

Emacs can sometimes abort when non-ASCII text, possibly with null
characters, is copied and pasted into a buffer.

An inactive cursor remains in an active window after the Windows
Manager driven switch of the focus, until a key is pressed.

Windows input methods are not recognized by Emacs (as of v21.2).  Some
of these input methods cause the keyboard to send characters encoded
in the appropriate coding system (e.g., ISO 8859-1 for Latin-1
characters, ISO 8859-8 for Hebrew characters, etc.).  To make this
work, set the keyboard coding system to the appropriate value after
you activate the Windows input method.  For example, if you activate
the Hebrew input method, type "C-x RET k iso-8859-8 RET".  (Emacs
ought to recognize the Windows language-change event and set up the
appropriate keyboard encoding automatically, but it doesn't do that
yet.)

Windows uses UTF-16 encoding to deal with multilingual text (text not
encodable in the `system codepage') in the clipboard.  To deal with
this, load the library `utf-16' and use `set-selection-coding-system'
to set the clipboard coding system to `utf-16-le-dos'.  This won't
cope with Far Eastern (`CJK') text; if necessary, install the Mule-UCS
package (see etc/MORE.STUFF), whose `utf-16-le-dos' coding system does
encode a lot of CJK characters.

The %h format specifier for format-time-string does not work on Windows.
The %b format specifier does not produce abbreviated month names with
consistent widths for some locales on some versions of Windows. This is
caused by a deficiency in the underlying system library function.

* The `configure' script doesn't find the jpeg library.

This can happen because the linker by default only looks for shared
libraries, but jpeg distribution by default doesn't build and doesn't
install a shared version of the library, `libjpeg.so'.  One system
where this is known to happen is Compaq OSF/1 (`Tru64'), but it
probably isn't limited to that system.

You can configure the jpeg library with the `--enable-shared' option
and then rebuild libjpeg.  This produces a shared version of libjpeg,
which you need to install.  Finally, rerun the Emacs configure script,
which should now find the jpeg library.  Alternatively, modify the
generated src/Makefile to link the .a file explicitly.

(If you need the static version of the jpeg library as well, configure
libjpeg with both `--enable-static' and `--enable-shared' options.)

* Building Emacs over NFS fails with ``Text file busy''.

This was reported to happen when building Emacs on a GNU/Linux system
(RedHat Linux 6.2) using a build directory automounted from Solaris
(SunOS 5.6) file server, but it might not be limited to that
configuration alone.  Presumably, the NFS server doesn't commit the
files' data to disk quickly enough, and the Emacs executable file is
left ``busy'' for several seconds after Emacs has finished dumping
itself.  This causes the subsequent commands which invoke the dumped
Emacs excutable to fail with the above message.

In some of these cases, a time skew between the NFS server and the
machine where Emacs is built is detected and reported by GNU Make
(it says that some of the files have modification time in the future).
This might be a symptom of NFS-related problems.

If the NFS server runs on Solaris, apply the Solaris patch 105379-05
(Sunos 5.6: /kernel/misc/nfssrv patch).  If that doesn't work, or if
you have a different version of the OS or the NFS server, you can
force the NFS server to use 1KB blocks, which was reported to fix the
problem albeit at a price of slowing down file I/O.  You can force 1KB
blocks by specifying the "-o  rsize=1024,wsize=1024" options to the
`mount' command, or by adding ",rsize=1024,wsize=1024" to the mount
options in the appropriate system configuration file, such as
`/etc/auto.home'.

Alternatively, when Make fails due to this problem, you could wait for
a few seconds and then invoke Make again.  In one particular case,
waiting for 10 or more seconds between the two Make invocations seemed
to work around the problem.

Similar problems can happen if your machine NFS-mounts a directory
onto itself.  Suppose the Emacs sources live in `/usr/local/src' and
you are working on the host called `marvin'.  Then an entry in the
`/etc/fstab' file like the following is asking for trouble:

    marvin:/usr/local/src /usr/local/src ...options.omitted...

The solution is to remove this line from `etc/fstab'.

* Emacs binary is not in executable format, and cannot be run.

This was reported to happen when Emacs is built in a directory mounted
via NFS.  Usually, the file `emacs' produced in these cases is full of
binary null characters, and the `file' utility says:

    emacs: ASCII text, with no line terminators

We don't know what exactly causes this failure.  A work-around is to
build Emacs in a directory on a local disk.

* Accented ISO-8859-1 characters are displayed as | or _.

Try other font set sizes (S-mouse-1).  If the problem persists with
other sizes as well, your text is corrupted, probably through software
that is not 8-bit clean.  If the problem goes away with another font
size, it's probably because some fonts pretend to be ISO-8859-1 fonts
when they are really ASCII fonts. In particular the schumacher-clean
fonts have this bug in some versions of X.

To see what glyphs are included in a font, use `xfd', like this:

  xfd -fn -schumacher-clean-medium-r-normal--12-120-75-75-c-60-iso8859-1

If this shows only ASCII glyphs, the font is indeed the source of the
problem.

The solution is to remove the corresponding lines from the appropriate
`fonts.alias' file, then run `mkfontdir' in that directory, and then run
`xset fp rehash'.

* Large file support is disabled on HP-UX.  See the comments in
src/s/hpux10.h.

* Crashes when displaying GIF images in Emacs built with version
libungif-4.1.0 are resolved by using version libungif-4.1.0b1.
Configure checks for the correct version, but this problem could occur
if a binary built against a shared libungif is run on a system with an
older version.

* Font Lock displays portions of the bufefr in incorrect faces.

By far the most frequent cause of this is a parenthesis `(' or a brace
`{' in column zero.  Font Lock assumes that such a paren is outside of
any comment or string.  This is of course not true in general, but the
vast majority of well-formatted program source files don't have such
parens, and therefore this assumption is used to allow optimizations
in Font Lock's syntactical analysis.  These optimizations avoid some
patological cases where jit-lock, the Just-in-Time fontification
introduced with Emacs 21.1, could significantly slow down scrolling
through the buffer, especially scrolling backwards, and also jumping
to the end of a very large buffer.

If you don't use large buffers, or have a very fast machine which
makes the delays insignificant, you can avoid the incorrect
fontification by setting the variable
`font-lock-beginning-of-syntax-function' to a nil value.  (This must
be done _after_ turning on Font Lock.)

Another alternative is to avoid a paren in column zero.  For example,
in a Lisp string you could precede the paren with a backslash.

* When running on KDE, colors or fonts are not as specified for Emacs,
or messed up.

For example, you could see background you set for Emacs only in the
empty portions of the Emacs display, while characters have some other
background.

This happens because KDE's defaults apply its color and font
definitions even to applications that weren't compiled for KDE.  The
solution is to uncheck the "Apply fonts and colors to non-KDE apps"
option in Preferences->Look&Feel->Style (KDE 2).  In KDE 3, this option
is in the "Colors" section, rather than "Style".

Alternatively, if you do want the KDE defaults to apply to other
applications, but not to Emacs, you could modify the file `Emacs.ad'
(should be in the `/usr/share/apps/kdisplay/app-defaults/' directory)
so that it doesn't set the default background and foreground only for
Emacs.  For example, make sure the following resources are either not
present or commented out:

   Emacs.default.attributeForeground
   Emacs.default.attributeBackground
   Emacs*Foreground
   Emacs*Background

* Interrupting Cygwin port of Bash from Emacs doesn't work.

Cygwin 1.x builds of the ported Bash cannot be interrupted from the
MS-Windows version of Emacs.  This is due to some change in the Bash
port or in the Cygwin library which apparently make Bash ignore the
keyboard interrupt event sent by Emacs to Bash.  (Older Cygwin ports
of Bash, up to b20.1, did receive SIGINT from Emacs.)

* Dired is very slow.

This could happen if invocation of the `df' program takes a long
time.  Possible reasons for this include:

  - ClearCase mounted filesystems (VOBs) that sometimes make `df'
    response time extremely slow (dozens of seconds);

  - slow automounters on some old versions of Unix;

  - slow operation of some versions of `df'.

To work around the problem, you could either (a) set the variable
`directory-free-space-program' to nil, and thus prevent Emacs from
invoking `df'; (b) use `df' from the GNU Fileutils package; or
(c) use CVS, which is Free Software, instead of ClearCase.

* Accessing remote files with ange-ftp hangs the MS-Windows version of Emacs.

If the FTP client is the Cygwin port of GNU `ftp', this appears to be
due to some bug in the Cygwin DLL or some incompatibility between it
and the implementation of asynchronous subprocesses in the Windows
port of Emacs.  Specifically, some parts of the FTP server responses
are not flushed out, apparently due to buffering issues, which
confuses ange-ftp.

The solution is to downgrade to an older version of the Cygwin DLL
(version 1.3.2 was reported to solve the problem), or use the stock
Windows FTP client, usually found in the `C:\WINDOWS' or 'C:\WINNT'
directory.  To force ange-ftp use the stock Windows client, set the
variable `ange-ftp-ftp-program-name' to the absolute file name of the
client's executable.  For example:

 (setq ange-ftp-ftp-program-name "c:/windows/ftp.exe")