problems

windows版本的emacs

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

* Characters from the mule-unicode charsets aren't displayed under X.

XFree86 4 contains many fonts in iso10646-1 encoding which have
minimal character repertoires (whereas the encoding is meant to be a
reasonable indication of the repertoire).  Emacs may choose one of
these to display characters from the mule-unicode charsets and then
typically won't be able to find the glyphs to display many characters.
(Check with C-u C-x = .)  To avoid this, you may need to use a fontset
which sets the font for the mule-unicode sets explicitly.  E.g. to use
GNU unifont, include in the fontset spec:

mule-unicode-2500-33ff:-gnu-unifont-*-iso10646-1,\
mule-unicode-e000-ffff:-gnu-unifont-*-iso10646-1,\
mule-unicode-0100-24ff:-gnu-unifont-*-iso10646-1

* Mule-UCS loads very slowly.

Changes to Emacs internals interact badly with Mule-UCS's `un-define'
library, which is the usual interface to Mule-UCS.  Apply the
following patch to Mule-UCS 0.84 and rebuild it.  That will help,
though loading will still be slower than in Emacs 20.  (Some
distributions, such as Debian, may already have applied such a patch.)

--- lisp/un-define.el	6 Mar 2001 22:41:38 -0000	1.30
+++ lisp/un-define.el	19 Apr 2002 18:34:26 -0000
@@ -610,13 +624,21 @@ by calling post-read-conversion and pre-
 
  (mapcar
   (lambda (x)
-    (mapcar
-     (lambda (y)
-       (mucs-define-coding-system
-	(nth 0 y) (nth 1 y) (nth 2 y)
-	(nth 3 y) (nth 4 y) (nth 5 y) (nth 6 y))
-       (coding-system-put (car y) 'alias-coding-systems (list (car x))))
-     (cdr x)))
+    (if (fboundp 'register-char-codings)
+	;; Mule 5, where we don't need the eol-type specified and
+	;; register-char-codings may be very slow for these coding
+	;; system definitions.
+	(let ((y (cadr x)))
+	  (mucs-define-coding-system
+	   (car x) (nth 1 y) (nth 2 y)
+	   (nth 3 y) (nth 4 y) (nth 5 y)))
+      (mapcar
+       (lambda (y)
+	 (mucs-define-coding-system
+	  (nth 0 y) (nth 1 y) (nth 2 y)
+	  (nth 3 y) (nth 4 y) (nth 5 y) (nth 6 y))
+	 (coding-system-put (car y) 'alias-coding-systems (list (car x)))))
+      (cdr x)))
   `((utf-8
      (utf-8-unix
       ?u "UTF-8 coding system"

Note that Emacs 21 has native support for (non-CJK) Unicode, so you
may not need Mule-UCS to edit Western utf-8 text, for instance.  There
are various enhancements at <URL:ftp://dlpx1.dl.ac.uk/fx/emacs/Mule>
which improve Emacs 21's handling of non-ASCII text, including dealing
with CJK Unicode.

* Building Emacs with GCC 2.9x fails in the `src' directory.

This may happen if you use a development version of GNU `cpp' from one
of the GCC snapshots between Oct 2000 and Feb 2001, or from a released
version of GCC newer than 2.95.2 which was prepared around those
dates; similar problems were reported with some snapshots of GCC 3.1
around Sep 30 2001.  The preprocessor in those versions is
incompatible with a traditional Unix cpp (e.g., it expands ".." into
". .", which breaks relative file names that reference the parent
directory; or inserts TAB characters before lines that set Make
variables).

The solution is to make sure the preprocessor is run with the
`-traditional' option.  The `configure' script does that automatically
when it detects the known problems in your cpp, but you might hit some
unknown ones.  To force the `configure' script to use `-traditional',
run the script like this:

  CPP='gcc -E -traditional' ./configure ...

(replace the ellipsis "..." with any additional arguments you pass to
the script).

Note that this problem does not pertain to the MS-Windows port of
Emacs, since it doesn't use the preprocessor to generate Makefiles.

* Building Emacs with a system compiler fails to link because of an
  undefined symbol such as __eprintf which does not appear in Emacs.

This can happen if some of the libraries linked into Emacs were built
with GCC, but Emacs itself is being linked with a compiler other than
GCC.  Object files compiled with GCC might need some helper functions
from libgcc.a, the library which comes with GCC, but the system
compiler does not instruct the linker to search libgcc.a during the
link stage.

A solution is to link with GCC, like this:

  	make CC=gcc

Since the .o object files already exist, this will not recompile Emacs
with GCC, but just start by trying again to link temacs.

* Building the MS-Windows port with Cygwin GCC can fail.

Emacs may not build using recent Cygwin builds of GCC, such as Cygwin
version 1.1.8, using the default configure settings.  It appears to be
necessary to specify the -mwin32 flag when compiling, and define
__MSVCRT__, like so:

  configure --with-gcc --cflags -mwin32 --cflags -D__MSVCRT__

* Building the MS-Windows port with Leim fails in the `leim' directory.

The error message might be something like this:

 Converting d:/emacs-21.2/leim/CXTERM-DIC/4Corner.tit to quail-package...
 Invalid ENCODE: value in TIT dictionary
 NMAKE : fatal error U1077: '"../src/obj-spd/i386/emacs.exe"' : return code
       '0xffffffff'
 Stop.

This can happen if the Leim distribution is unpacked with a program
which converts the `*.tit' files to DOS-style CR-LF text format.  The
`*.tit' files in the leim/CXTERM-DIC directory require Unix-style line
endings to compile properly, because Emacs reads them without any code
or EOL conversions.

The solution is to make sure the program used to unpack Leim does not
change the files' line endings behind your back.  The GNU FTP site has
in the `/gnu/emacs/windows' directory a program called `djtarnt.exe'
which can be used to unpack `.tar.gz' and `.zip' archives without
mangling them.

* Emacs crashes when dumping itself on Mac PPC running Yellow Dog GNU/Linux.

The crashes happen inside the function Fmake_symbol; here's a typical
C backtrace printed by GDB:

  0x190c0c0 in Fmake_symbol ()
  (gdb) where
  #0  0x190c0c0 in Fmake_symbol ()
  #1  0x1942ca4 in init_obarray ()
  #2  0x18b3500 in main ()
  #3  0x114371c in __libc_start_main (argc=5, argv=0x7ffff5b4, envp=0x7ffff5cc,

This could happen because GCC version 2.95 and later changed the base
of the load address to 0x10000000.  Emacs needs to be told about this,
but we currently cannot do that automatically, because that breaks
other versions of GNU/Linux on the MacPPC.  Until we find a way to
distinguish between the Yellow Dog and the other varieties of
GNU/Linux systems on the PPC, you will have to manually uncomment the
following section near the end of the file src/m/macppc.h in the Emacs
distribution:

  #if 0  /* This breaks things on PPC GNU/Linux ecept for Yellowdog,
	    even with identical GCC, as, ld.  Let's take it out until we
	    know what's really going on here.  */
  /* GCC 2.95 and newer on GNU/Linux PPC changed the load address to
     0x10000000.  */
  #if defined __linux__
  #if __GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 95)
  #define DATA_SEG_BITS  0x10000000
  #endif
  #endif
  #endif /* 0 */

Remove the "#if 0" and "#endif" directives which surround this, save
the file, and then reconfigure and rebuild Emacs.  The dumping process
should now succeed.

* JPEG images aren't displayed.

This has been reported when Emacs is built with jpeg-6a library.
Upgrading to jpeg-6b solves the problem.  Configure checks for the
correct version, but this problem could occur if a binary built
against a shared libjpeg is run on a system with an older version.

* Building `ctags' for MS-Windows with the MinGW port of GCC fails.

This might happen due to a bug in the MinGW header assert.h, which
defines the `assert' macro with a trailing semi-colon.  The following
patch to assert.h should solve this:

*** include/assert.h.orig	Sun Nov  7 02:41:36 1999
--- include/assert.h	Mon Jan 29 11:49:10 2001
***************
*** 41,47 ****
  /*
   * If not debugging, assert does nothing.
   */
! #define assert(x)	((void)0);
  
  #else /* debugging enabled */
  
--- 41,47 ----
  /*
   * If not debugging, assert does nothing.
   */
! #define assert(x)	((void)0)
  
  #else /* debugging enabled */
  


* Improving performance with slow X connections

There are several ways to improve this performance, any subset of which can
be carried out at the same time:

1) If you don't need X Input Methods (XIM) for entering text in some
   language you use, you can improve performance on WAN links by
   configuring Emacs with option `--without-xim'.  Configuring Emacs
   without XIM does not affect the use of Emacs' own input methods, which
   are part of the Leim package.

2) If the connection is very slow, you might also want to consider
   switching off scroll bars, menu bar, and tool bar.

3) Use ssh to forward the X connection, and enable compression on this
   forwarded X connection (ssh -XC remotehostname emacs ...).

4) Use lbxproxy on the remote end of the connection.  This is an interface
   to the low bandwidth X extension in most modern X servers, which
   improves performance dramatically, at the slight expense of correctness
   of the X protocol.  lbxproxy acheives the performance gain by grouping
   several X requests in one TCP packet and sending them off together,
   instead of requiring a round-trip for each X request in a seperate
   packet.  The switches that seem to work best for emacs are:
    -noatomsfile  -nowinattr  -cheaterrors -cheatevents
   Note that the -nograbcmap option is known to cause problems.
   For more about lbxproxy, see:
   http://www.xfree86.org/4.2.0/lbxproxy.1.html

* Getting a Meta key on the FreeBSD console

By default, neither Alt nor any other key acts as a Meta key on
FreeBSD, but this can be changed using kbdcontrol(1).  Dump the
current keymap to a file with the command

  $ kbdcontrol -d >emacs.kbd

Edit emacs.kbd, and give the key you want to be the Meta key the
definition `meta'.  For instance, if your keyboard has a ``Windows''
key with scan code 105, change the line for scan code 105 in emacs.kbd
to look like this

  105   meta   meta   meta   meta   meta   meta   meta   meta    O

to make the Windows key the Meta key.  Load the new keymap with

  $ kbdcontrol -l emacs.kbd

* Emacs' xterm-mouse-mode doesn't work on the Gnome terminal.

A symptom of this bug is that double-clicks insert a control sequence
into the buffer.  The reason this happens is an apparent
incompatibility of the Gnome terminal with Xterm, which also affects
other programs using the Xterm mouse interface.  A problem report has
been filed.

* Emacs pauses for several seconds when changing the default font

This has been reported for fvwm 2.2.5 and the window manager of KDE
2.1.  The reason for the pause is Xt waiting for a ConfigureNotify
event from the window manager, which the window manager doesn't send.
Xt stops waiting after a default timeout of usually 5 seconds.

A workaround for this is to add something like

emacs.waitForWM: false

to your X resources.  Alternatively, add `(wait-for-wm . nil)' to a
frame's parameter list, like this:

   (modify-frame-parameters nil '((wait-for-wm . nil)))

(this should go into your `.emacs' file).

* Underlines appear at the wrong position.

This is caused by fonts having a wrong UNDERLINE_POSITION property.
Examples are the font 7x13 on XFree prior to version 4.1, or the jmk
neep font from the Debian xfonts-jmk package.  To circumvent this
problem, set x-use-underline-position-properties to nil in your
`.emacs'.

To see what is the value of UNDERLINE_POSITION defined by the font,
type `xlsfonts -lll FONT' and look at the font's UNDERLINE_POSITION
property.

* When using Xaw3d scroll bars without arrows, the very first mouse
click in a scroll bar might be ignored by the scroll bar widget.  This
is probably a bug in Xaw3d; when Xaw3d is compiled with arrows, the
problem disappears.

* There are known binary incompatibilities between Xaw, Xaw3d, neXtaw,
XawM and the few other derivatives of Xaw.  So when you compile with
one of these, it may not work to dynamically link with another one.
For example, strange problems, such as Emacs exiting when you type
"C-x 1", were reported when Emacs compiled with Xaw3d and libXaw was
used with neXtaw at run time.

The solution is to rebuild Emacs with the toolkit version you actually
want to use, or set LD_PRELOAD to preload the same toolkit version you
built Emacs with.

* Clicking C-mouse-2 in the scroll bar doesn't split the window.

This currently doesn't work with scroll-bar widgets (and we don't know
a good way of implementing it with widgets).  If Emacs is configured
--without-toolkit-scroll-bars, C-mouse-2 on the scroll bar does work.

* Emacs aborts inside the function `tparam1'.

This can happen if Emacs was built without terminfo support, but the
terminal's capabilities use format that is only supported by terminfo.
If your system has ncurses installed, this might happen if your
version of ncurses is broken; upgrading to a newer version of ncurses
and reconfiguring and rebuilding Emacs should solve this.

All modern systems support terminfo, so even if ncurses is not the
problem, you should look for a way to configure Emacs so that it uses
terminfo when built.

* Error messages about undefined colors on X.

The messages might say something like this: