comparison etc/PROBLEMS @ 42167:7d43b2a3529d

Update location of Windows Emacs FAQ. Minor fixes.

42166:3f9afbe82974

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__

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

`{' 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

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 examlpe, 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

* On Windows 95/98/ME, subprocesses do not terminate properly.

This is a limitation of the Operating System, and can cause problems
when shutting down Windows. Ensure that all subprocesses are exited
cleanly before exiting Emacs. For more details, see the FAQ at
ftp://ftp.gnu.org/gnu/windows/emacs/doc/index.html

* Mail sent through Microsoft Exchange in some encodings appears to be
mangled and is not seen correctly in Rmail or Gnus.  We don't know
exactly what happens, but it isn't an Emacs problem in cases we've
seen.

42167:7d43b2a3529d

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 except 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__

(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 executable 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.

`{' 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
pathological 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

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

* On Windows 95/98/ME, subprocesses do not terminate properly.

This is a limitation of the Operating System, and can cause problems
when shutting down Windows. Ensure that all subprocesses are exited
cleanly before exiting Emacs. For more details, see the FAQ at
http://www.gnu.org/software/emacs/windows/.

* Mail sent through Microsoft Exchange in some encodings appears to be
mangled and is not seen correctly in Rmail or Gnus.  We don't know
exactly what happens, but it isn't an Emacs problem in cases we've
seen.