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'.
+neep font from the Debian xfonts-jmk package prior to version 3.0.17.
+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
Using the old library version is a workaround.
-** Mac OS X
-
-*** Mac OS X (Carbon): Environment Variables from dotfiles are ignored.
-
-When starting Emacs from the Dock or the Finder on Mac OS X, the
-environment variables that are set up in dotfiles, such as .cshrc or
-.profile, are ignored. This is because the Finder and Dock are not
-started from a shell, but instead from the Window Manager itself.
-
-The workaround for this is to create a .MacOSX/environment.plist file to
-setup these environment variables. These environment variables will
-apply to all processes regardless of where they are started.
-For me information, see http://developer.apple.com/qa/qa2001/qa1067.html.
-
-*** Mac OS X (Carbon): Process output truncated when using ptys.
-
-There appears to be a problem with the implementation of pty's on the
-Mac OS X that causes process output to be truncated. To avoid this,
-leave process-connection-type set to its default value of nil.
-
-*** Mac OS X 10.3.9 (Carbon): QuickTime updater breaks build.
-
-Some QuickTime updaters such as 7.0.4 and 7.2.0 are known to break
-build at the link stage with the message like "Undefined symbols:
-_HICopyAccessibilityActionDescription referenced from QuickTime
-expected to be defined in Carbon". A workaround is to use a QuickTime
-reinstaller. Alternatively, you can link with the frameworks in the
-corresponding SDK by specifying LDFLAGS as
-"-Wl,-F/Developer/SDKs/MacOSX10.3.0.sdk/System/Library/Frameworks".
-
** FreeBSD
*** FreeBSD 2.1.5: useless symbolic links remain in /tmp or other
** Known problems with the MS-Windows port of Emacs 22.1
+M-x term does not work on MS-Windows. TTY emulation on Windows is
+undocumented, and programs such as stty which are used on posix platforms
+to control tty emulation do not exist for native windows terminals.
+
Using create-fontset-from-ascii-font or the --font startup parameter
with a Chinese, Japanese or Korean font leads to display problems.
Use a Latin-only font as your default font. If you want control over
*** 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.
+Makefile in the src subdirectory.
It has been known to get fatal errors due to insufficient swapping
space available on the machine.
This seems to be due to a GCC bug; it is fixed in GCC 2.8.1.
-** VMS: 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.
-
** Vax C compiler bugs affecting Emacs.
You may get one of these problems compiling Emacs:
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.
+This problem will only happen if USE_LISP_UNION_TYPE is manually
+defined in lisp.h.
*** C compilers lose on returning unions.
Most of the functions in GNU Emacs return type Lisp_Object, which is
defined as a union on some rare architectures.
-This problem will not happen if the m-...h file for your type
-of machine defines NO_UNION_TYPE.
+This problem will only happen if USE_LISP_UNION_TYPE is manually
+defined in lisp.h.
\f
This file is part of GNU Emacs.
-GNU Emacs is free software; you can redistribute it and/or modify
+GNU Emacs is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 3, or (at your option)
-any later version.
+the Free Software Foundation, either version 3 of the License, or
+(at your option) any later version.
GNU Emacs is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
-along with GNU Emacs; see the file COPYING. If not, write to the
-Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
-Boston, MA 02110-1301, USA.
+along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>.
\f
Local variables:
HCoop / bpt / emacs.git / blobdiff