1 |
This file describes various problems that have been encountered |
This file describes various problems that have been encountered |
2 |
in compiling, installing and running GNU Emacs. |
in compiling, installing and running GNU Emacs. Try doing Ctl t |
3 |
|
and browsing through the outline headers. |
4 |
|
|
5 |
* Mule-UCS doesn't work in Emacs 22. |
* Mule-UCS doesn't work in Emacs 22. |
6 |
|
|
7 |
It's completely redundant now, as far as we know. |
It's completely redundant now, as far as we know. |
8 |
|
|
9 |
* Environment Variables from dotfiles are ignored with Mac OS X (Carbon). |
* Emacs startup failures |
10 |
|
|
11 |
When starting Emacs from the Dock or the Finder on Mac OS X, the |
** Emacs fails to start, complaining about missing fonts. |
|
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. |
|
|
|
|
|
* Segfault on GNU/Linux using certain recent versions of the Linux kernel. |
|
|
|
|
|
With certain recent Linux kernels (like the one of Redhat Fedora Core |
|
|
1), the new "Exec-shield" functionality is enabled by default, which |
|
|
creates a different memory layout that breaks the emacs dumper. |
|
|
|
|
|
You can check the Exec-shield state like this: |
|
|
|
|
|
cat /proc/sys/kernel/exec-shield |
|
|
|
|
|
It returns 1 or 2 when Exec-shield is enabled, 0 otherwise. Please |
|
|
read your system documentation for more details on Exec-shield and |
|
|
associated commands. |
|
|
|
|
|
When Exec-shield is enabled, building Emacs will segfault during the |
|
|
execution of this command: |
|
|
|
|
|
temacs --batch --load loadup [dump|bootstrap] |
|
|
|
|
|
To work around this problem, it is necessary to temporarily disable |
|
|
Exec-shield while building Emacs, using the `setarch' command like |
|
|
this: |
|
|
|
|
|
setarch i386 ./configure <configure parameters> |
|
|
setarch i386 make <make parameters> |
|
|
|
|
|
* Characters are displayed as empty boxes or with wrong font under X. |
|
|
|
|
|
This can occur when two different versions of FontConfig are used. |
|
|
For example, XFree86 4.3.0 has one version and Gnome usually comes |
|
|
with a newer version. Emacs compiled with --with-gtk will then use |
|
|
the newer version. In most cases the problem can be temporarily |
|
|
fixed by stopping the application that has the error (it can be |
|
|
Emacs or any other application), removing ~/.fonts.cache-1, |
|
|
and then start the application again. |
|
|
If removing ~/.fonts.cache-1 and restarting doesn't help, the |
|
|
application with problem must be recompiled with the same version |
|
|
of FontConfig as the rest of the system uses. For KDE, it is |
|
|
sufficient to recompile Qt. |
|
|
|
|
|
* Process output truncated on Mac OS X (Carbon) when using pty's. |
|
|
|
|
|
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. |
|
|
|
|
|
* Emacs crashes on Mac OS X (Carbon) after system software upgrade. |
|
|
|
|
|
This problem seems to be now solved by Steven Tamm's patch to |
|
|
unexmacosx.c on Nov 24, 2002. |
|
|
|
|
|
Between Mac OS X release 10.2.1 and 10.2.2 there was an incompatible |
|
|
change in the memory allocator that causes a EXC_BAD_ACCESS error near |
|
|
xrealloc(). Relinking the application (by deleting src/temacs and |
|
|
running make) will solve the problem. It appears to be caused by some |
|
|
problems with the unexec code and its interaction with libSystem.B. |
|
|
|
|
|
* Emacs crashes with SIGSEGV in XtInitializeWidgetClass |
|
|
|
|
|
It crashes on X, but runs fine when called with option "-nw". |
|
|
|
|
|
This has been observed when Emacs is linked with GNU ld but without passing |
|
|
the -z nocombreloc flag. Emacs normally knows to pass the -z nocombreloc |
|
|
flag when needed, so if you come across a situation where the flag is |
|
|
necessary but missing, please report it via M-x report-emacs-bug. |
|
|
|
|
|
On platforms such as Solaris, you can also work around this problem by |
|
|
configuring your compiler to use the native linker instead of GNU ld. |
|
|
|
|
|
* Characters from the mule-unicode charsets aren't displayed under X. |
|
12 |
|
|
13 |
XFree86 4 contains many fonts in iso10646-1 encoding which have |
A typical error message might be something like |
|
minimal character repertoires (whereas the encoding part of the font |
|
|
name is meant to be a reasonable indication of the repertoire |
|
|
according to the XLFD spec). 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 |
|
14 |
|
|
15 |
* The UTF-8/16/7 coding systems don't encode CJK (Far Eastern) characters. |
No fonts match `-*-fixed-medium-r-*--6-*-*-*-*-*-iso8859-1' |
16 |
|
|
17 |
Emacs by default only supports the parts of the Unicode BMP whose code |
This happens because some X resource specifies a bad font family for |
18 |
points are in the ranges 0000-33ff and e000-ffff. This excludes: most |
Emacs to use. The possible places where this specification might be |
19 |
of CJK, Yi and Hangul, as well as everything outside the BMP. |
are: |
20 |
|
|
21 |
If you read UTF-8 data with code points outside these ranges, the |
- in your ~/.Xdefaults file |
|
characters appear in the buffer as raw bytes of the original UTF-8 |
|
|
(composed into a single quasi-character) and they will be written back |
|
|
correctly as UTF-8, assuming you don't break the composed sequences. |
|
|
If you read such characters from UTF-16 or UTF-7 data, they are |
|
|
substituted with the Unicode `replacement character', and you lose |
|
|
information. |
|
22 |
|
|
23 |
To edit such UTF data, turn on Utf-Translate-Cjk mode, which makes |
- client-side X resource file, such as ~/Emacs or |
24 |
many common CJK characters available for encoding and decoding and can |
/usr/X11R6/lib/app-defaults/Emacs or |
25 |
be extended by updating the tables it uses. This also allows you to |
/usr/X11R6/lib/X11/app-defaults/Emacs |
|
save as UTF buffers containing characters decoded by the chinese-, |
|
|
japanese- and korean- coding systems, e.g. cut and pasted from |
|
|
elsewhere. |
|
26 |
|
|
27 |
* Problems with file dialogs in Emacs built with Open Motif. |
One of these files might have bad or malformed specification of a |
28 |
|
fontset that Emacs should use. To fix the problem, you need to find |
29 |
|
the problematic line(s) and correct them. |
30 |
|
|
31 |
When Emacs 21 is built with Open Motif 2.1, it can happen that the |
** Emacs aborts while starting up, only when run without X. |
|
graphical file dialog boxes do not work properly. The "OK", "Filter" |
|
|
and "Cancel" buttons do not respond to mouse clicks. Dragging the |
|
|
file dialog window usually causes the buttons to work again. |
|
32 |
|
|
33 |
The solution is to use LessTif instead. LessTif is a free replacement |
This problem often results from compiling Emacs with GCC when GCC was |
34 |
for Motif. See the file INSTALL for information on how to do this. |
installed incorrectly. The usual error in installing GCC is to |
35 |
|
specify --includedir=/usr/include. Installation of GCC makes |
36 |
|
corrected copies of the system header files. GCC is supposed to use |
37 |
|
the corrected copies in preference to the original system headers. |
38 |
|
Specifying --includedir=/usr/include causes the original system header |
39 |
|
files to be used. On some systems, the definition of ioctl in the |
40 |
|
original system header files is invalid for ANSI C and causes Emacs |
41 |
|
not to work. |
42 |
|
|
43 |
Another workaround is not to use the mouse to trigger file prompts, |
The fix is to reinstall GCC, and this time do not specify --includedir |
44 |
but to use the keyboard. This way, you will be prompted for a file in |
when you configure it. Then recompile Emacs. Specifying --includedir |
45 |
the minibuffer instead of a graphical file dialog. |
is appropriate only in very special cases and it should *never* be the |
46 |
|
same directory where system header files are kept. |
47 |
|
|
48 |
* Emacs reports a BadAtom error (from X) running on Solaris 7 or 8. |
** Emacs does not start, complaining that it cannot open termcap database file. |
49 |
|
|
50 |
This happens when Emacs was built on some other version of Solaris. |
If your system uses Terminfo rather than termcap (most modern |
51 |
Rebuild it on Solaris 8. |
systems do), this could happen if the proper version of |
52 |
|
ncurses is not visible to the Emacs configure script (i.e. it |
53 |
|
cannot be found along the usual path the linker looks for |
54 |
|
libraries). It can happen because your version of ncurses is |
55 |
|
obsolete, or is available only in form of binaries. |
56 |
|
|
57 |
* Mule-UCS loads very slowly. |
The solution is to install an up-to-date version of ncurses in |
58 |
|
the developer's form (header files, static libraries and |
59 |
|
symbolic links); in some GNU/Linux distributions (e.g. Debian) |
60 |
|
it constitutes a separate package. |
61 |
|
|
62 |
Changes to Emacs internals interact badly with Mule-UCS's `un-define' |
** Emacs 20 and later fails to load Lisp files at startup. |
|
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.) |
|
63 |
|
|
64 |
--- lisp/un-define.el 6 Mar 2001 22:41:38 -0000 1.30 |
The typical error message might be like this: |
|
+++ lisp/un-define.el 19 Apr 2002 18:34:26 -0000 |
|
|
@@ -610,13 +624,21 @@ by calling post-read-conversion and pre- |
|
65 |
|
|
66 |
(mapcar |
"Cannot open load file: fontset" |
|
(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" |
|
67 |
|
|
68 |
Note that Emacs has native support for Unicode, roughly equivalent to |
This could happen if you compress the file lisp/subdirs.el. That file |
69 |
Mule-UCS's, so you may not need it. |
tells Emacs what are the directories where it should look for Lisp |
70 |
|
files. Emacs cannot work with subdirs.el compressed, since the |
71 |
|
Auto-compress mode it needs for this will not be loaded until later, |
72 |
|
when your .emacs file is processed. (The package `fontset.el' is |
73 |
|
required to set up fonts used to display text on window systems, and |
74 |
|
it's loaded very early in the startup procedure.) |
75 |
|
|
76 |
* Building Emacs with GCC 2.9x fails in the `src' directory. |
Similarly, any other .el file for which there's no corresponding .elc |
77 |
|
file could fail to load if it is compressed. |
78 |
|
|
79 |
This may happen if you use a development version of GNU `cpp' from one |
The solution is to uncompress all .el files which don't have a .elc |
80 |
of the GCC snapshots between Oct 2000 and Feb 2001, or from a released |
file. |
|
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). |
|
81 |
|
|
82 |
The solution is to make sure the preprocessor is run with the |
Another possible reason for such failures is stale *.elc files |
83 |
`-traditional' option. The `configure' script does that automatically |
lurking somewhere on your load-path. The following command will |
84 |
when it detects the known problems in your cpp, but you might hit some |
print any duplicate Lisp files that are present in load-path: |
|
unknown ones. To force the `configure' script to use `-traditional', |
|
|
run the script like this: |
|
85 |
|
|
86 |
CPP='gcc -E -traditional' ./configure ... |
emacs -q -batch -f list-load-path-shadows |
87 |
|
|
88 |
(replace the ellipsis "..." with any additional arguments you pass to |
If this command prints any file names, some of these files are stale, |
89 |
the script). |
and should be deleted or their directories removed from your |
90 |
|
load-path. |
91 |
|
|
92 |
Note that this problem does not pertain to the MS-Windows port of |
** Emacs prints an error at startup after upgrading from an earlier version. |
|
Emacs, since it doesn't use the preprocessor to generate Makefiles. |
|
93 |
|
|
94 |
* Building Emacs with a system compiler fails to link because of an |
An example of such an error is: |
|
undefined symbol such as __eprintf which does not appear in Emacs. |
|
95 |
|
|
96 |
This can happen if some of the libraries linked into Emacs were built |
x-complement-fontset-spec: "Wrong type argument: stringp, nil" |
|
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. |
|
97 |
|
|
98 |
A solution is to link with GCC, like this: |
This can be another symptom of stale *.elc files in your load-path. |
99 |
|
The following command will print any duplicate Lisp files that are |
100 |
|
present in load-path: |
101 |
|
|
102 |
make CC=gcc |
emacs -q -batch -f list-load-path-shadows |
103 |
|
|
104 |
Since the .o object files already exist, this will not recompile Emacs |
If this command prints any file names, some of these files are stale, |
105 |
with GCC, but just restart by trying again to link temacs. |
and should be deleted or their directories removed from your |
106 |
|
load-path. |
107 |
|
|
108 |
* Building the MS-Windows port with Cygwin GCC can fail. |
** With X11R6.4, public-patch-3, Emacs crashes at startup. |
109 |
|
|
110 |
Emacs may not build using recent Cygwin builds of GCC, such as Cygwin |
Reportedly this patch in X fixes the problem. |
|
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: |
|
111 |
|
|
112 |
configure --with-gcc --cflags -mwin32 --cflags -D__MSVCRT__ |
--- xc/lib/X11/imInt.c~ Wed Jun 30 13:31:56 1999 |
113 |
|
+++ xc/lib/X11/imInt.c Thu Jul 1 15:10:27 1999 |
114 |
|
@@ -1,4 +1,4 @@ |
115 |
|
-/* $TOG: imInt.c /main/5 1998/05/30 21:11:16 kaleb $ */ |
116 |
|
+/* $TOG: imInt.c /main/5 1998/05/30 21:11:16 kaleb $ */ |
117 |
|
/****************************************************************** |
118 |
|
|
119 |
* Building the MS-Windows port fails with a CreateProcess failure. |
Copyright 1992, 1993, 1994 by FUJITSU LIMITED |
120 |
|
@@ -166,8 +166,8 @@ |
121 |
|
_XimMakeImName(lcd) |
122 |
|
XLCd lcd; |
123 |
|
{ |
124 |
|
- char* begin; |
125 |
|
- char* end; |
126 |
|
+ char* begin = NULL; |
127 |
|
+ char* end = NULL; |
128 |
|
char* ret; |
129 |
|
int i = 0; |
130 |
|
char* ximmodifier = XIMMODIFIER; |
131 |
|
@@ -182,7 +182,11 @@ |
132 |
|
} |
133 |
|
ret = Xmalloc(end - begin + 2); |
134 |
|
if (ret != NULL) { |
135 |
|
- (void)strncpy(ret, begin, end - begin + 1); |
136 |
|
+ if (begin != NULL) { |
137 |
|
+ (void)strncpy(ret, begin, end - begin + 1); |
138 |
|
+ } else { |
139 |
|
+ ret[0] = '\0'; |
140 |
|
+ } |
141 |
|
ret[end - begin + 1] = '\0'; |
142 |
|
} |
143 |
|
return ret; |
144 |
|
|
145 |
Some versions of mingw32 make on some versions of Windows do not seem |
* Crash bugs |
|
to detect the shell correctly. Try "make SHELL=cmd.exe", or if that |
|
|
fails, try running make from Cygwin bash instead. |
|
146 |
|
|
147 |
* Building the MS-Windows port with Leim fails in the `leim' directory. |
** Emacs crashes in x-popup-dialog. |
148 |
|
|
149 |
The error message might be something like this: |
This can happen if the dialog widget cannot find the font it wants to |
150 |
|
use. You can work around the problem by specifying another font with |
151 |
|
an X resource--for example, `Emacs.dialog*.font: 9x15' (or any font that |
152 |
|
happens to exist on your X server). |
153 |
|
|
154 |
Converting d:/emacs-21.3/leim/CXTERM-DIC/4Corner.tit to quail-package... |
** Emacs crashes when you use Bibtex mode. |
|
Invalid ENCODE: value in TIT dictionary |
|
|
NMAKE : fatal error U1077: '"../src/obj-spd/i386/emacs.exe"' : return code |
|
|
'0xffffffff' |
|
|
Stop. |
|
155 |
|
|
156 |
This can happen if the Leim distribution is unpacked with a program |
This happens if your system puts a small limit on stack size. You can |
157 |
which converts the `*.tit' files to DOS-style CR-LF text format. The |
prevent the problem by using a suitable shell command (often `ulimit') |
158 |
`*.tit' files in the leim/CXTERM-DIC directory require Unix-style line |
to raise the stack size limit before you run Emacs. |
|
endings to compile properly, because Emacs reads them without any code |
|
|
or EOL conversions. |
|
159 |
|
|
160 |
The solution is to make sure the program used to unpack Leim does not |
Patches to raise the stack size limit automatically in `main' |
161 |
change the files' line endings behind your back. The GNU FTP site has |
(src/emacs.c) on various systems would be greatly appreciated. |
|
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. |
|
162 |
|
|
163 |
* Emacs crashes when dumping itself on Mac PPC running Yellow Dog GNU/Linux. |
** Emacs crashes with SIGBUS or SIGSEGV on HPUX 9 after you delete a frame. |
164 |
|
|
165 |
The crashes happen inside the function Fmake_symbol; here's a typical |
We think this is due to a bug in the X libraries provided by HP. With |
166 |
C backtrace printed by GDB: |
the alternative X libraries in /usr/contrib/mitX11R5/lib, the problem |
167 |
|
does not happen. |
168 |
|
|
169 |
0x190c0c0 in Fmake_symbol () |
** Emacs crashes with SIGBUS or SIGSEGV on Solaris after you delete a frame. |
|
(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, |
|
170 |
|
|
171 |
This could happen because GCC version 2.95 and later changed the base |
We suspect that this is a similar bug in the X libraries provided by |
172 |
of the load address to 0x10000000. Emacs needs to be told about this, |
Sun. There is a report that one of these patches fixes the bug and |
173 |
but we currently cannot do that automatically, because that breaks |
makes the problem stop: |
|
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: |
|
174 |
|
|
175 |
#if 0 /* This breaks things on PPC GNU/Linux except for Yellowdog, |
105216-01 105393-01 105518-01 105621-01 105665-01 105615-02 105216-02 |
176 |
even with identical GCC, as, ld. Let's take it out until we |
105667-01 105401-08 105615-03 105621-02 105686-02 105736-01 105755-03 |
177 |
know what's really going on here. */ |
106033-01 105379-01 105786-01 105181-04 105379-03 105786-04 105845-01 |
178 |
/* GCC 2.95 and newer on GNU/Linux PPC changed the load address to |
105284-05 105669-02 105837-01 105837-02 105558-01 106125-02 105407-01 |
|
0x10000000. */ |
|
|
#if defined __linux__ |
|
|
#if __GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 95) |
|
|
#define DATA_SEG_BITS 0x10000000 |
|
|
#endif |
|
|
#endif |
|
|
#endif /* 0 */ |
|
179 |
|
|
180 |
Remove the "#if 0" and "#endif" directives which surround this, save |
Another person using a newer system (kernel patch level Generic_105181-06) |
181 |
the file, and then reconfigure and rebuild Emacs. The dumping process |
suspects that the bug was fixed by one of these more recent patches: |
|
should now succeed. |
|
182 |
|
|
183 |
* JPEG images aren't displayed. |
106040-07 SunOS 5.6: X Input & Output Method patch |
184 |
|
106222-01 OpenWindows 3.6: filemgr (ff.core) fixes |
185 |
|
105284-12 Motif 1.2.7: sparc Runtime library patch |
186 |
|
|
187 |
This has been reported when Emacs is built with jpeg-6a library. |
** Error message `Symbol's value as variable is void: x', followed by |
188 |
Upgrading to jpeg-6b solves the problem. Configure checks for the |
a segmentation fault and core dump. |
|
correct version, but this problem could occur if a binary built |
|
|
against a shared libjpeg is run on a system with an older version. |
|
189 |
|
|
190 |
* Building `ctags' for MS-Windows with the MinGW port of GCC fails. |
This has been tracked to a bug in tar! People report that tar erroneously |
191 |
|
added a line like this at the beginning of files of Lisp code: |
192 |
|
|
193 |
This might happen due to a bug in the MinGW header assert.h, which |
x FILENAME, N bytes, B tape blocks |
|
defines the `assert' macro with a trailing semi-colon. The following |
|
|
patch to assert.h should solve this: |
|
194 |
|
|
195 |
*** include/assert.h.orig Sun Nov 7 02:41:36 1999 |
If your tar has this problem, install GNU tar--if you can manage to |
196 |
--- include/assert.h Mon Jan 29 11:49:10 2001 |
untar it :-). |
|
*************** |
|
|
*** 41,47 **** |
|
|
/* |
|
|
* If not debugging, assert does nothing. |
|
|
*/ |
|
|
! #define assert(x) ((void)0); |
|
197 |
|
|
198 |
#else /* debugging enabled */ |
** Crashes when displaying GIF images in Emacs built with version |
199 |
|
libungif-4.1.0 are resolved by using version libungif-4.1.0b1. |
200 |
|
Configure checks for the correct version, but this problem could occur |
201 |
|
if a binary built against a shared libungif is run on a system with an |
202 |
|
older version. |
203 |
|
|
204 |
--- 41,47 ---- |
** Emacs aborts inside the function `tparam1'. |
|
/* |
|
|
* If not debugging, assert does nothing. |
|
|
*/ |
|
|
! #define assert(x) ((void)0) |
|
205 |
|
|
206 |
#else /* debugging enabled */ |
This can happen if Emacs was built without terminfo support, but the |
207 |
|
terminal's capabilities use format that is only supported by terminfo. |
208 |
|
If your system has ncurses installed, this might happen if your |
209 |
|
version of ncurses is broken; upgrading to a newer version of ncurses |
210 |
|
and reconfiguring and rebuilding Emacs should solve this. |
211 |
|
|
212 |
|
All modern systems support terminfo, so even if ncurses is not the |
213 |
|
problem, you should look for a way to configure Emacs so that it uses |
214 |
|
terminfo when built. |
215 |
|
|
216 |
|
** Emacs crashes when using the Exceed 6.0 X server. |
217 |
|
|
218 |
* Improving performance with slow X connections |
If you are using Exceed 6.1, upgrade to a later version. This was |
219 |
|
reported to prevent the crashes. |
220 |
|
|
221 |
There are several ways to improve this performance, any subset of which can |
** Emacs crashes with SIGSEGV in XtInitializeWidgetClass. |
|
be carried out at the same time: |
|
222 |
|
|
223 |
1) If you don't need X Input Methods (XIM) for entering text in some |
It crashes on X, but runs fine when called with option "-nw". |
|
language you use, you can improve performance on WAN links by using |
|
|
the X resource useXIM to turn off use of XIM. This does not affect |
|
|
the use of Emacs' own input methods, which are part of the Leim |
|
|
package. |
|
224 |
|
|
225 |
2) If the connection is very slow, you might also want to consider |
This has been observed when Emacs is linked with GNU ld but without passing |
226 |
switching off scroll bars, menu bar, and tool bar. |
the -z nocombreloc flag. Emacs normally knows to pass the -z nocombreloc |
227 |
|
flag when needed, so if you come across a situation where the flag is |
228 |
|
necessary but missing, please report it via M-x report-emacs-bug. |
229 |
|
|
230 |
3) Use ssh to forward the X connection, and enable compression on this |
On platforms such as Solaris, you can also work around this problem by |
231 |
forwarded X connection (ssh -XC remotehostname emacs ...). |
configuring your compiler to use the native linker instead of GNU ld. |
232 |
|
|
233 |
4) Use lbxproxy on the remote end of the connection. This is an interface |
* General runtime problems |
|
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.3.0/lbxproxy.1.html |
|
234 |
|
|
235 |
* Getting a Meta key on the FreeBSD console |
** Lisp problems |
236 |
|
|
237 |
By default, neither Alt nor any other key acts as a Meta key on |
*** Changes made to .el files do not take effect. |
|
FreeBSD, but this can be changed using kbdcontrol(1). Dump the |
|
|
current keymap to a file with the command |
|
238 |
|
|
239 |
$ kbdcontrol -d >emacs.kbd |
You may have forgotten to recompile them into .elc files. |
240 |
|
Then the old .elc files will be loaded, and your changes |
241 |
|
will not be seen. To fix this, do M-x byte-recompile-directory |
242 |
|
and specify the directory that contains the Lisp files. |
243 |
|
|
244 |
Edit emacs.kbd, and give the key you want to be the Meta key the |
Emacs should print a warning when loading a .elc file which is older |
245 |
definition `meta'. For instance, if your keyboard has a ``Windows'' |
than the corresponding .el file. |
|
key with scan code 105, change the line for scan code 105 in emacs.kbd |
|
|
to look like this |
|
246 |
|
|
247 |
105 meta meta meta meta meta meta meta meta O |
*** Watch out for .emacs files and EMACSLOADPATH environment vars. |
248 |
|
|
249 |
to make the Windows key the Meta key. Load the new keymap with |
These control the actions of Emacs. |
250 |
|
~/.emacs is your Emacs init file. |
251 |
|
EMACSLOADPATH overrides which directories the function |
252 |
|
"load" will search. |
253 |
|
|
254 |
$ kbdcontrol -l emacs.kbd |
If you observe strange problems, check for these and get rid |
255 |
|
of them, then try again. |
256 |
|
|
257 |
* Emacs' xterm-mouse-mode doesn't work on the Gnome terminal. |
*** Using epop3.el package causes Emacs to signal an error. |
258 |
|
|
259 |
A symptom of this bug is that double-clicks insert a control sequence |
The error message might be something like this: |
|
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. |
|
260 |
|
|
261 |
* Emacs pauses for several seconds when changing the default font |
"Lisp nesting exceeds max-lisp-eval-depth" |
262 |
|
|
263 |
This has been reported for fvwm 2.2.5 and the window manager of KDE |
This happens because epop3 redefines the function gethash, which is a |
264 |
2.1. The reason for the pause is Xt waiting for a ConfigureNotify |
built-in primitive beginning with Emacs 21.1. We don't have a patch |
265 |
event from the window manager, which the window manager doesn't send. |
for epop3 that fixes this, but perhaps a newer version of epop3 |
266 |
Xt stops waiting after a default timeout of usually 5 seconds. |
corrects that. |
267 |
|
|
268 |
A workaround for this is to add something like |
*** Buffers from `with-output-to-temp-buffer' get set up in Help mode. |
269 |
|
|
270 |
emacs.waitForWM: false |
Changes in Emacs 20.4 to the hooks used by that function cause |
271 |
|
problems for some packages, specifically BBDB. See the function's |
272 |
|
documentation for the hooks involved. BBDB 2.00.06 fixes the problem. |
273 |
|
|
274 |
to your X resources. Alternatively, add `(wait-for-wm . nil)' to a |
*** The Hyperbole package causes *Help* buffers not to be displayed in |
275 |
frame's parameter list, like this: |
Help mode due to setting `temp-buffer-show-hook' rather than using |
276 |
|
`add-hook'. Using `(add-hook 'temp-buffer-show-hook |
277 |
|
'help-mode-maybe)' after loading Hyperbole should fix this. |
278 |
|
|
279 |
(modify-frame-parameters nil '((wait-for-wm . nil))) |
** Keyboard problems |
280 |
|
|
281 |
(this should go into your `.emacs' file). |
*** "Compose Character" key does strange things when used as a Meta key. |
282 |
|
|
283 |
* Underlines appear at the wrong position. |
If you define one key to serve as both Meta and Compose Character, you |
284 |
|
will get strange results. In previous Emacs versions, this "worked" |
285 |
|
in that the key acted as Meta--that's because the older Emacs versions |
286 |
|
did not try to support Compose Character. Now Emacs tries to do |
287 |
|
character composition in the standard X way. This means that you |
288 |
|
must pick one meaning or the other for any given key. |
289 |
|
|
290 |
This is caused by fonts having a wrong UNDERLINE_POSITION property. |
You can use both functions (Meta, and Compose Character) if you assign |
291 |
Examples are the font 7x13 on XFree prior to version 4.1, or the jmk |
them to two different keys. |
|
neep font from the Debian xfonts-jmk package. To circumvent this |
|
|
problem, set x-use-underline-position-properties to nil in your |
|
|
`.emacs'. |
|
292 |
|
|
293 |
To see what is the value of UNDERLINE_POSITION defined by the font, |
*** C-z just refreshes the screen instead of suspending Emacs. |
|
type `xlsfonts -lll FONT' and look at the font's UNDERLINE_POSITION |
|
|
property. |
|
294 |
|
|
295 |
* When using Xaw3d scroll bars without arrows, the very first mouse |
You are probably using a shell that doesn't support job control, even |
296 |
click in a scroll bar might be ignored by the scroll bar widget. This |
though the system itself is capable of it. Either use a different shell, |
297 |
is probably a bug in Xaw3d; when Xaw3d is compiled with arrows, the |
or set the variable `cannot-suspend' to a non-nil value. |
|
problem disappears. |
|
298 |
|
|
299 |
* There are known binary incompatibilities between Xaw, Xaw3d, neXtaw, |
*** With M-x enable-flow-control, you need to type C-\ twice |
300 |
XawM and the few other derivatives of Xaw. So when you compile with |
to do incremental search--a single C-\ gets no response. |
|
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. |
|
301 |
|
|
302 |
The solution is to rebuild Emacs with the toolkit version you actually |
This has been traced to communicating with your machine via kermit, |
303 |
want to use, or set LD_PRELOAD to preload the same toolkit version you |
with C-\ as the kermit escape character. One solution is to use |
304 |
built Emacs with. |
another escape character in kermit. One user did |
305 |
|
|
306 |
* Clicking C-mouse-2 in the scroll bar doesn't split the window. |
set escape-character 17 |
307 |
|
|
308 |
This currently doesn't work with scroll-bar widgets (and we don't know |
in his .kermrc file, to make C-q the kermit escape character. |
|
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. |
|
309 |
|
|
310 |
* Emacs aborts inside the function `tparam1'. |
** Mailers and other helper programs |
311 |
|
|
312 |
This can happen if Emacs was built without terminfo support, but the |
*** movemail compiled with POP support can't connect to the POP server. |
|
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. |
|
313 |
|
|
314 |
All modern systems support terminfo, so even if ncurses is not the |
Make sure that the `pop' entry in /etc/services, or in the services |
315 |
problem, you should look for a way to configure Emacs so that it uses |
NIS map if your machine uses NIS, has the same port number as the |
316 |
terminfo when built. |
entry on the POP server. A common error is for the POP server to be |
317 |
|
listening on port 110, the assigned port for the POP3 protocol, while |
318 |
|
the client is trying to connect on port 109, the assigned port for the |
319 |
|
old POP protocol. |
320 |
|
|
321 |
* Error messages about undefined colors on X. |
*** RMAIL gets error getting new mail. |
322 |
|
|
323 |
The messages might say something like this: |
RMAIL gets new mail from /usr/spool/mail/$USER using a program |
324 |
|
called `movemail'. This program interlocks with /bin/mail using |
325 |
|
the protocol defined by /bin/mail. |
326 |
|
|
327 |
Unable to load color "grey95" |
There are two different protocols in general use. One of them uses |
328 |
|
the `flock' system call. The other involves creating a lock file; |
329 |
|
`movemail' must be able to write in /usr/spool/mail in order to do |
330 |
|
this. You control which one is used by defining, or not defining, |
331 |
|
the macro MAIL_USE_FLOCK in config.h or the m- or s- file it includes. |
332 |
|
IF YOU DON'T USE THE FORM OF INTERLOCKING THAT IS NORMAL ON YOUR |
333 |
|
SYSTEM, YOU CAN LOSE MAIL! |
334 |
|
|
335 |
(typically, in the `*Messages*' buffer), or something like this: |
If your system uses the lock file protocol, and fascist restrictions |
336 |
|
prevent ordinary users from writing the lock files in /usr/spool/mail, |
337 |
|
you may need to make `movemail' setgid to a suitable group such as |
338 |
|
`mail'. You can use these commands (as root): |
339 |
|
|
340 |
Error while displaying tooltip: (error Undefined color lightyellow) |
chgrp mail movemail |
341 |
|
chmod 2755 movemail |
342 |
|
|
343 |
These problems could happen if some other X program has used up too |
If your system uses the lock file protocol, and fascist restrictions |
344 |
many colors of the X palette, leaving Emacs with insufficient system |
prevent ordinary users from writing the lock files in /usr/spool/mail, |
345 |
resources to load all the colors it needs. |
you may need to make `movemail' setgid to a suitable group such as |
346 |
|
`mail'. To do this, use the following commands (as root) after doing the |
347 |
|
make install. |
348 |
|
|
349 |
A solution is to exit the offending X programs before starting Emacs. |
chgrp mail movemail |
350 |
|
chmod 2755 movemail |
351 |
|
|
352 |
* Colors are not available on a tty or in xterm. |
Installation normally copies movemail from the build directory to an |
353 |
|
installation directory which is usually under /usr/local/lib. The |
354 |
|
installed copy of movemail is usually in the directory |
355 |
|
/usr/local/lib/emacs/VERSION/TARGET. You must change the group and |
356 |
|
mode of the installed copy; changing the group and mode of the build |
357 |
|
directory copy is ineffective. |
358 |
|
|
359 |
Emacs 21 supports colors on character terminals and terminal |
*** rcs2log gives you the awk error message "too many fields". |
|
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". |
|
360 |
|
|
361 |
In addition to the "Co" capability, Emacs needs the "op" (for |
This is due to an arbitrary limit in certain versions of awk. |
362 |
``original pair'') capability, which tells how to switch the terminal |
The solution is to use gawk (GNU awk). |
|
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). |
|
363 |
|
|
364 |
Finally, the "NC" capability (terminfo name: "ncv") tells Emacs which |
** Problems with hostname resolution |
|
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. |
|
365 |
|
|
366 |
Emacs uses the database entry for the terminal whose name is the value |
*** Emacs fails to understand most Internet host names, even though |
367 |
of the environment variable TERM. With `xterm', a common terminal |
the names work properly with other programs on the same system. |
368 |
entry that supports color is `xterm-color', so setting TERM's value to |
*** Emacs won't work with X-windows if the value of DISPLAY is HOSTNAME:0. |
369 |
`xterm-color' might activate the color support on an xterm-compatible |
*** GNUs can't make contact with the specified host for nntp. |
|
emulator. |
|
370 |
|
|
371 |
Beginning with version 21.4, Emacs supports the --color command-line |
This typically happens on Suns and other systems that use shared |
372 |
option which may be used to force Emacs to use one of a few popular |
libraries. The cause is that the site has installed a version of the |
373 |
modes for getting colors on a tty. For example, --color=ansi8 sets up |
shared library which uses a name server--but has not installed a |
374 |
for using the ANSI-standard escape sequences that support 8 colors. |
similar version of the unshared library which Emacs uses. |
375 |
|
|
376 |
Some modes do not use colors unless you turn on the Font-lock mode. |
The result is that most programs, using the shared library, work with |
377 |
Some people have long ago set their `~/.emacs' files to turn on |
the nameserver, but Emacs does not. |
|
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'. |
|
378 |
|
|
379 |
* Emacs on a tty switches the cursor to large blinking block. |
The fix is to install an unshared library that corresponds to what you |
380 |
|
installed in the shared library, and then relink Emacs. |
381 |
|
|
382 |
This was reported to happen on some GNU/Linux systems which use |
On SunOS 4.1, simply define HAVE_RES_INIT. |
|
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. |
|
383 |
|
|
384 |
A work-around is to redefine the "cvvis" capability so that it |
If you have already installed the name resolver in the file libresolv.a, |
385 |
enables a *software* cursor. The software cursor works by inverting |
then you need to compile Emacs to use that library. The easiest way to |
386 |
the colors of the character at point, so what you see is a block |
do this is to add to config.h a definition of LIBS_SYSTEM, LIBS_MACHINE |
387 |
cursor that doesn't blink. For this to work, you need to redefine |
or LIB_STANDARD which uses -lresolv. Watch out! If you redefine a macro |
388 |
the "cnorm" capability as well, so that it operates on the software |
that is already in use in your configuration to supply some other libraries, |
389 |
cursor instead of the hardware cursor. |
be careful not to lose the others. |
390 |
|
|
391 |
To this end, run "infocmp linux > linux-term", edit the file |
Thus, you could start by adding this to config.h: |
|
`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. |
|
392 |
|
|
393 |
Alternatively, if you want a blinking underscore as your Emacs cursor, |
#define LIBS_SYSTEM -lresolv |
|
change the "cvvis" capability to send the "\E[?25h\E[?0c" command. |
|
394 |
|
|
395 |
* Problems in Emacs built with LessTif. |
Then if this gives you an error for redefining a macro, and you see that |
396 |
|
the s- file defines LIBS_SYSTEM as -lfoo -lbar, you could change config.h |
397 |
|
again to say this: |
398 |
|
|
399 |
The problems seem to depend on the version of LessTif and the Motif |
#define LIBS_SYSTEM -lresolv -lfoo -lbar |
|
emulation for which it is set up. |
|
400 |
|
|
401 |
Only the Motif 1.2 emulation seems to be stable enough in LessTif. |
*** Emacs does not know your host's fully-qualified domain name. |
|
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. |
|
402 |
|
|
403 |
On some systems, even with Motif 1.2 emulation, Emacs occasionally |
You need to configure your machine with a fully qualified domain name, |
404 |
locks up, grabbing all mouse and keyboard events. We still don't know |
either in /etc/hosts, /etc/hostname, the NIS, or wherever your system |
405 |
what causes these problems; they are not reproducible by Emacs |
calls for specifying this. |
|
developers. |
|
406 |
|
|
407 |
* Known problems with the MS-Windows port of Emacs 21.2. |
If you cannot fix the configuration, you can set the Lisp variable |
408 |
|
mail-host-address to the value you want. |
409 |
|
|
410 |
Frames are not refreshed while the File or Font dialog or a pop-up menu |
** NFS and RFS |
|
is displayed. This also means help text for pop-up menus 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. |
|
411 |
|
|
412 |
Windows 95 and Windows NT up to version 4.0 do not support help text |
*** Emacs says it has saved a file, but the file does not actually |
413 |
for menus. Help text is only available in later versions of Windows. |
appear on disk. |
414 |
|
|
415 |
There are problems with display if mouse-tracking is enabled and the |
This can happen on certain systems when you are using NFS, if the |
416 |
mouse is moved off a frame, over another frame then back over the first |
remote disk is full. It is due to a bug in NFS (or certain NFS |
417 |
frame. A workaround is to click the left mouse button inside the frame |
implementations), and there is apparently nothing Emacs can do to |
418 |
after moving back into it. |
detect the problem. Emacs checks the failure codes of all the system |
419 |
|
calls involved in writing a file, including `close'; but in the case |
420 |
|
where the problem occurs, none of those system calls fails. |
421 |
|
|
422 |
Some minor flickering still persists during mouse-tracking, although |
*** Editing files through RFS gives spurious "file has changed" warnings. |
423 |
not as severely as in 21.1. |
It is possible that a change in Emacs 18.37 gets around this problem, |
424 |
|
but in case not, here is a description of how to fix the RFS bug that |
425 |
|
causes it. |
426 |
|
|
427 |
Emacs can sometimes abort when non-ASCII text, possibly with null |
There was a serious pair of bugs in the handling of the fsync() system |
428 |
characters, is copied and pasted into a buffer. |
call in the RFS server. |
429 |
|
|
430 |
An inactive cursor remains in an active window after the Windows |
The first is that the fsync() call is handled as another name for the |
431 |
Manager driven switch of the focus, until a key is pressed. |
close() system call (!!). It appears that fsync() is not used by very |
432 |
|
many programs; Emacs version 18 does an fsync() before closing files |
433 |
|
to make sure that the bits are on the disk. |
434 |
|
|
435 |
Windows input methods are not recognized by Emacs (as of v21.2). Some |
This is fixed by the enclosed patch to the RFS server. |
|
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.) |
|
436 |
|
|
437 |
The %b specifier for format-time-string does not produce abbreviated |
The second, more serious problem, is that fsync() is treated as a |
438 |
month names with consistent widths for some locales on some versions |
non-blocking system call (i.e., it's implemented as a message that |
439 |
of Windows. This is caused by a deficiency in the underlying system |
gets sent to the remote system without waiting for a reply). Fsync is |
440 |
library function. |
a useful tool for building atomic file transactions. Implementing it |
441 |
|
as a non-blocking RPC call (when the local call blocks until the sync |
442 |
|
is done) is a bad idea; unfortunately, changing it will break the RFS |
443 |
|
protocol. No fix was supplied for this problem. |
444 |
|
|
445 |
* The `configure' script doesn't find the jpeg library. |
(as always, your line numbers may vary) |
446 |
|
|
447 |
There are reports that this happens on some systems because the linker |
% rcsdiff -c -r1.2 serversyscall.c |
448 |
by default only looks for shared libraries, but jpeg distribution by |
RCS file: RCS/serversyscall.c,v |
449 |
default only installs a nonshared version of the library, `libjpeg.a'. |
retrieving revision 1.2 |
450 |
|
diff -c -r1.2 serversyscall.c |
451 |
|
*** /tmp/,RCSt1003677 Wed Jan 28 15:15:02 1987 |
452 |
|
--- serversyscall.c Wed Jan 28 15:14:48 1987 |
453 |
|
*************** |
454 |
|
*** 163,169 **** |
455 |
|
/* |
456 |
|
* No return sent for close or fsync! |
457 |
|
*/ |
458 |
|
! if (syscall == RSYS_close || syscall == RSYS_fsync) |
459 |
|
proc->p_returnval = deallocate_fd(proc, msg->m_args[0]); |
460 |
|
else |
461 |
|
{ |
462 |
|
--- 166,172 ---- |
463 |
|
/* |
464 |
|
* No return sent for close or fsync! |
465 |
|
*/ |
466 |
|
! if (syscall == RSYS_close) |
467 |
|
proc->p_returnval = deallocate_fd(proc, msg->m_args[0]); |
468 |
|
else |
469 |
|
{ |
470 |
|
|
471 |
If this is the problem, you can configure the jpeg library with the |
** PSGML |
|
`--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, and edit src/config.h to define HAVE_JPEG. |
|
472 |
|
|
473 |
* Building Emacs over NFS fails with ``Text file busy''. |
*** Old versions of the PSGML package use the obsolete variables |
474 |
|
`before-change-function' and `after-change-function', which are no |
475 |
|
longer used by Emacs. Please use PSGML 1.2.3 or later. |
476 |
|
|
477 |
This was reported to happen when building Emacs on a GNU/Linux system |
*** PSGML conflicts with sgml-mode. |
|
(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 executable to fail with the above message. |
|
478 |
|
|
479 |
In some of these cases, a time skew between the NFS server and the |
PSGML package uses the same names of some variables (like keymap) |
480 |
machine where Emacs is built is detected and reported by GNU Make |
as built-in sgml-mode.el because it was created as a replacement |
481 |
(it says that some of the files have modification time in the future). |
of that package. The conflict will be shown if you load |
482 |
This might be a symptom of NFS-related problems. |
sgml-mode.el before psgml.el. E.g. this could happen if you edit |
483 |
|
HTML page and then start to work with SGML or XML file. html-mode |
484 |
|
(from sgml-mode.el) is used for HTML file and loading of psgml.el |
485 |
|
(for sgml-mode or xml-mode) will cause an error. |
486 |
|
|
487 |
If the NFS server runs on Solaris, apply the Solaris patch 105379-05 |
*** Versions of the PSGML package earlier than 1.0.3 (stable) or 1.1.2 |
488 |
(Sunos 5.6: /kernel/misc/nfssrv patch). If that doesn't work, or if |
(alpha) fail to parse DTD files correctly in Emacs 20.3 and later. |
489 |
you have a different version of the OS or the NFS server, you can |
Here is a patch for psgml-parse.el from PSGML 1.0.1 and, probably, |
490 |
force the NFS server to use 1KB blocks, which was reported to fix the |
earlier versions. |
|
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'. |
|
491 |
|
|
492 |
Alternatively, when Make fails due to this problem, you could wait for |
--- psgml-parse.el 1998/08/21 19:18:18 1.1 |
493 |
a few seconds and then invoke Make again. In one particular case, |
+++ psgml-parse.el 1998/08/21 19:20:00 |
494 |
waiting for 10 or more seconds between the two Make invocations seemed |
@@ -2383,7 +2383,7 @@ (defun sgml-push-to-entity (entity &opti |
495 |
to work around the problem. |
(setq sgml-buffer-parse-state nil)) |
496 |
|
(cond |
497 |
|
((stringp entity) ; a file name |
498 |
|
- (save-excursion (insert-file-contents entity)) |
499 |
|
+ (insert-file-contents entity) |
500 |
|
(setq default-directory (file-name-directory entity))) |
501 |
|
((consp (sgml-entity-text entity)) ; external id? |
502 |
|
(let* ((extid (sgml-entity-text entity)) |
503 |
|
|
504 |
Similar problems can happen if your machine NFS-mounts a directory |
** AUCTeX |
|
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: |
|
505 |
|
|
506 |
marvin:/usr/local/src /usr/local/src ...options.omitted... |
You should not be using a version older than 11.52 if you can avoid |
507 |
|
it. |
508 |
|
|
509 |
The solution is to remove this line from `etc/fstab'. |
*** Emacs 21 freezes when visiting a TeX file with AUCTeX installed. |
510 |
|
|
511 |
* Emacs binary is not in executable format, and cannot be run. |
Emacs 21 needs version 10 or later of AUCTeX; upgrading should solve |
512 |
|
these problems. |
513 |
|
|
514 |
This was reported to happen when Emacs is built in a directory mounted |
*** No colors in AUCTeX with Emacs 21. |
|
via NFS, for some combinations of NFS client and NFS server. |
|
|
Usually, the file `emacs' produced in these cases is full of |
|
|
binary null characters, and the `file' utility says: |
|
515 |
|
|
516 |
emacs: ASCII text, with no line terminators |
Upgrade to AUC TeX version 10 or later, and make sure it is |
517 |
|
byte-compiled with Emacs 21. |
518 |
|
|
519 |
We don't know what exactly causes this failure. A work-around is to |
** Miscellaneous problems |
|
build Emacs in a directory on a local disk. |
|
520 |
|
|
521 |
* Accented ISO-8859-1 characters are displayed as | or _. |
*** Self-documentation messages are garbled. |
522 |
|
|
523 |
Try other font set sizes (S-mouse-1). If the problem persists with |
This means that the file `etc/DOC-...' doesn't properly correspond |
524 |
other sizes as well, your text is corrupted, probably through software |
with the Emacs executable. Redumping Emacs and then installing the |
525 |
that is not 8-bit clean. If the problem goes away with another font |
corresponding pair of files should fix the problem. |
|
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. |
|
526 |
|
|
527 |
To see what glyphs are included in a font, use `xfd', like this: |
*** Programs running under terminal emulator do not recognize `emacs' |
528 |
|
terminal type. |
529 |
|
|
530 |
xfd -fn -schumacher-clean-medium-r-normal--12-120-75-75-c-60-iso8859-1 |
The cause of this is a shell startup file that sets the TERMCAP |
531 |
|
environment variable. The terminal emulator uses that variable to |
532 |
|
provide the information on the special terminal type that Emacs |
533 |
|
emulates. |
534 |
|
|
535 |
If this shows only ASCII glyphs, the font is indeed the source of the |
Rewrite your shell startup file so that it does not change TERMCAP |
536 |
problem. |
in such a case. You could use the following conditional which sets |
537 |
|
it only if it is undefined. |
538 |
|
|
539 |
The solution is to remove the corresponding lines from the appropriate |
if ( ! ${?TERMCAP} ) setenv TERMCAP ~/my-termcap-file |
|
`fonts.alias' file, then run `mkfontdir' in that directory, and then run |
|
|
`xset fp rehash'. |
|
540 |
|
|
541 |
* Large file support is disabled on HP-UX. See the comments in |
Or you could set TERMCAP only when you set TERM--which should not |
542 |
src/s/hpux10.h. |
happen in a non-login shell. |
543 |
|
|
544 |
* Crashes when displaying GIF images in Emacs built with version |
*** In Shell mode, you get a ^M at the end of every line. |
|
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. |
|
545 |
|
|
546 |
* Font Lock displays portions of the buffer in incorrect faces. |
This happens to people who use tcsh, because it is trying to be too |
547 |
|
smart. It sees that the Shell uses terminal type `unknown' and turns |
548 |
|
on the flag to output ^M at the end of each line. You can fix the |
549 |
|
problem by adding this to your .cshrc file: |
550 |
|
|
551 |
By far the most frequent cause of this is a parenthesis `(' or a brace |
if ($?EMACS) then |
552 |
`{' in column zero. Font Lock assumes that such a paren is outside of |
if ($EMACS == "t") then |
553 |
any comment or string. This is of course not true in general, but the |
unset edit |
554 |
vast majority of well-formatted program source files don't have such |
stty -icrnl -onlcr -echo susp ^Z |
555 |
parens, and therefore this assumption is used to allow optimizations |
endif |
556 |
in Font Lock's syntactical analysis. These optimizations avoid some |
endif |
|
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. |
|
557 |
|
|
558 |
Beginning with version 21.4, a parenthesis or a brace in column zero |
*** Emacs startup on GNU/Linux systems (and possibly other systems) is slow. |
|
is highlighted in bold-red face if it is inside a string or a comment, |
|
|
to indicate that it could interfere with Font Lock (and also with |
|
|
indentation) and should be moved or escaped with a backslash. |
|
559 |
|
|
560 |
If you don't use large buffers, or have a very fast machine which |
This can happen if the system is misconfigured and Emacs can't get the |
561 |
makes the delays insignificant, you can avoid the incorrect |
full qualified domain name, FQDN. You should have your FQDN in the |
562 |
fontification by setting the variable |
/etc/hosts file, something like this: |
|
`font-lock-beginning-of-syntax-function' to a nil value. (This must |
|
|
be done _after_ turning on Font Lock.) |
|
563 |
|
|
564 |
Another alternative is to avoid a paren in column zero. For example, |
127.0.0.1 localhost |
565 |
in a Lisp string you could precede the paren with a backslash. |
129.187.137.82 nuc04.t30.physik.tu-muenchen.de nuc04 |
566 |
|
|
567 |
* When running on KDE, colors or fonts are not as specified for Emacs, |
The way to set this up may vary on non-GNU systems. |
|
or messed up. |
|
568 |
|
|
569 |
For example, you could see background you set for Emacs only in the |
*** Attempting to visit remote files via ange-ftp fails. |
|
empty portions of the Emacs display, while characters have some other |
|
|
background. |
|
570 |
|
|
571 |
This happens because KDE's defaults apply its color and font |
If the error message is "ange-ftp-file-modtime: Specified time is not |
572 |
definitions even to applications that weren't compiled for KDE. The |
representable", then this could happen when `lukemftp' is used as the |
573 |
solution is to uncheck the "Apply fonts and colors to non-KDE apps" |
ftp client. This was reported to happen on Debian GNU/Linux, kernel |
574 |
option in Preferences->Look&Feel->Style (KDE 2). In KDE 3, this option |
version 2.4.3, with `lukemftp' 1.5-5, but might happen on other |
575 |
is in the "Colors" section, rather than "Style". |
systems as well. To avoid this problem, switch to using the standard |
576 |
|
ftp client. On a Debian system, type |
577 |
|
|
578 |
Alternatively, if you do want the KDE defaults to apply to other |
update-alternatives --config ftp |
|
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: |
|
579 |
|
|
580 |
Emacs.default.attributeForeground |
and then choose /usr/bin/netkit-ftp. |
|
Emacs.default.attributeBackground |
|
|
Emacs*Foreground |
|
|
Emacs*Background |
|
581 |
|
|
582 |
* Interrupting Cygwin port of Bash from Emacs doesn't work. |
*** JPEG images aren't displayed. |
583 |
|
|
584 |
Cygwin 1.x builds of the ported Bash cannot be interrupted from the |
This has been reported when Emacs is built with jpeg-6a library. |
585 |
MS-Windows version of Emacs. This is due to some change in the Bash |
Upgrading to jpeg-6b solves the problem. Configure checks for the |
586 |
port or in the Cygwin library which apparently make Bash ignore the |
correct version, but this problem could occur if a binary built |
587 |
keyboard interrupt event sent by Emacs to Bash. (Older Cygwin ports |
against a shared libjpeg is run on a system with an older version. |
|
of Bash, up to b20.1, did receive SIGINT from Emacs.) |
|
588 |
|
|
589 |
* Dired is very slow. |
*** Dired is very slow. |
590 |
|
|
591 |
This could happen if invocation of the `df' program takes a long |
This could happen if invocation of the `df' program takes a long |
592 |
time. Possible reasons for this include: |
time. Possible reasons for this include: |
603 |
invoking `df'; (b) use `df' from the GNU Fileutils package; or |
invoking `df'; (b) use `df' from the GNU Fileutils package; or |
604 |
(c) use CVS, which is Free Software, instead of ClearCase. |
(c) use CVS, which is Free Software, instead of ClearCase. |
605 |
|
|
606 |
* Accessing remote files with ange-ftp hangs the MS-Windows version of Emacs. |
*** Versions of the W3 package released before Emacs 21.1 don't run |
|
|
|
|
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") |
|
|
|
|
|
If you want to stick with the Cygwin FTP client, you can work around |
|
|
this problem by putting this in your `.emacs' file: |
|
|
|
|
|
(setq ange-ftp-ftp-program-args '("-i" "-n" "-g" "-v" "--prompt" "") |
|
|
|
|
|
* Versions of the W3 package released before Emacs 21.1 don't run |
|
607 |
under Emacs 21. This fixed in W3 version 4.0pre.47. |
under Emacs 21. This fixed in W3 version 4.0pre.47. |
608 |
|
|
609 |
* On AIX, if linking fails because libXbsd isn't found, check if you |
*** The LDAP support rely on ldapsearch program from OpenLDAP version 2. |
|
are compiling with the system's `cc' and CFLAGS containing `-O5'. If |
|
|
so, you have hit a compiler bug. Please make sure to re-configure |
|
|
Emacs so that it isn't compiled with `-O5'. |
|
|
|
|
|
* Compiling on AIX 4.3.x or 4.4 fails. |
|
|
|
|
|
This could happen if you use /bin/c89 as your compiler, instead of |
|
|
the default `cc'. /bin/c89 treats certain warnings, such as benign |
|
|
redefinitions of macros, as errors, and fails the build. A solution |
|
|
is to use the default compiler `cc'. |
|
|
|
|
|
* Old versions of the PSGML package use the obsolete variables |
|
|
`before-change-function' and `after-change-function', which are no |
|
|
longer used by Emacs. Please use PSGML 1.2.3 or later. |
|
|
|
|
|
* PSGML conflicts with sgml-mode. |
|
|
|
|
|
PSGML package uses the same names of some variables (like keymap) |
|
|
as built-in sgml-mode.el because it was created as a replacement |
|
|
of that package. The conflict will be shown if you load |
|
|
sgml-mode.el before psgml.el. E.g. this could happen if you edit |
|
|
HTML page and then start to work with SGML or XML file. html-mode |
|
|
(from sgml-mode.el) is used for HTML file and loading of psgml.el |
|
|
(for sgml-mode or xml-mode) will cause an error. |
|
|
|
|
|
* The LDAP support rely on ldapsearch program from OpenLDAP version 2. |
|
610 |
|
|
611 |
It can fail to work with ldapsearch program from OpenLDAP version 1. |
It can fail to work with ldapsearch program from OpenLDAP version 1. |
612 |
Version 1 of OpenLDAP is now deprecated. If you are still using it, |
Version 1 of OpenLDAP is now deprecated. If you are still using it, |
613 |
please upgrade to version 2. As a temporary workaround, remove |
please upgrade to version 2. As a temporary workaround, remove |
614 |
argument "-x" from the variable `ldap-ldapsearch-args'. |
argument "-x" from the variable `ldap-ldapsearch-args'. |
615 |
|
|
616 |
* The `oc-unicode' package doesn't work with Emacs 21. |
*** ps-print commands fail to find prologue files ps-prin*.ps. |
|
|
|
|
This package tries to define more private charsets than there are free |
|
|
slots now. The current built-in Unicode support is actually more |
|
|
flexible. (Use option `utf-translate-cjk-mode' if you need CJK |
|
|
support.) Files encoded as emacs-mule using oc-unicode aren't |
|
|
generally read correctly by Emacs 21. |
|
|
|
|
|
* Using epop3.el package causes Emacs to signal an error. |
|
|
|
|
|
The error message might be something like this: |
|
|
|
|
|
"Lisp nesting exceeds max-lisp-eval-depth" |
|
|
|
|
|
This happens because epop3 redefines the function gethash, which is a |
|
|
built-in primitive beginning with Emacs 21.1. We don't have a patch |
|
|
for epop3 that fixes this, but perhaps a newer version of epop3 |
|
|
corrects that. |
|
|
|
|
|
* ps-print commands fail to find prologue files ps-prin*.ps. |
|
617 |
|
|
618 |
This can happen if you use an old version of X-Symbol package: it |
This can happen if you use an old version of X-Symbol package: it |
619 |
defines compatibility functions which trick ps-print into thinking it |
defines compatibility functions which trick ps-print into thinking it |
621 |
|
|
622 |
The solution is to upgrade X-Symbol to a later version. |
The solution is to upgrade X-Symbol to a later version. |
623 |
|
|
624 |
* lpr commands don't work on MS-Windows with some cheap printers. |
*** On systems with shared libraries you might encounter run-time errors |
|
|
|
|
This problem may also strike other platforms, but the solution is |
|
|
likely to be a global one, and not Emacs specific. |
|
|
|
|
|
Many cheap inkjet, and even some cheap laser printers, do not |
|
|
print plain text anymore, they will only print through graphical |
|
|
printer drivers. A workaround on MS-Windows is to use Windows' basic |
|
|
built in editor to print (this is possibly the only useful purpose it |
|
|
has): |
|
|
|
|
|
(setq printer-name "") ;; notepad takes the default |
|
|
(setq lpr-command "notepad") ;; notepad |
|
|
(setq lpr-switches nil) ;; not needed |
|
|
(setq lpr-printer-switch "/P") ;; run notepad as batch printer |
|
|
|
|
|
* On systems with shared libraries you might encounter run-time errors |
|
625 |
from the dynamic linker telling you that it is unable to find some |
from the dynamic linker telling you that it is unable to find some |
626 |
shared libraries, for instance those for Xaw3d or image support. |
shared libraries, for instance those for Xaw3d or image support. |
627 |
These errors mean Emacs has been linked with a library whose shared |
These errors mean Emacs has been linked with a library whose shared |
660 |
|
|
661 |
Please refer to the documentation of your dynamic linker for details. |
Please refer to the documentation of your dynamic linker for details. |
662 |
|
|
663 |
* On Solaris 2.7, building Emacs with WorkShop Compilers 5.0 98/12/15 |
*** You request inverse video, and the first Emacs frame is in inverse |
664 |
C 5.0 failed, apparently with non-default CFLAGS, most probably due to |
video, but later frames are not in inverse video. |
|
compiler bugs. Using Sun Solaris 2.7 Sun WorkShop 6 update 1 C |
|
|
release was reported to work without problems. It worked OK on |
|
|
another system with Solaris 8 using apparently the same 5.0 compiler |
|
|
and the default CFLAGS. |
|
|
|
|
|
* Compiling syntax.c with the OPENSTEP 4.2 compiler gcc 2.7.2.1 fails. |
|
|
|
|
|
The compiler was reported to crash while compiling syntax.c with the |
|
|
following message: |
|
|
|
|
|
cc: Internal compiler error: program cc1obj got fatal signal 11 |
|
|
|
|
|
To work around this, replace the macros UPDATE_SYNTAX_TABLE_FORWARD, |
|
|
INC_BOTH, and INC_FROM with functions. To this end, first define 3 |
|
|
functions, one each for every macro. Here's an example: |
|
|
|
|
|
static int update_syntax_table_forward(int from) |
|
|
{ |
|
|
return(UPDATE_SYNTAX_TABLE_FORWARD(from)); |
|
|
}/*update_syntax_table_forward*/ |
|
665 |
|
|
666 |
Then replace all references to UPDATE_SYNTAX_TABLE_FORWARD in syntax.c |
This can happen if you have an old version of the custom library in |
667 |
with a call to the function update_syntax_table_forward. |
your search path for Lisp packages. Use M-x list-load-path-shadows to |
668 |
|
check whether this is true. If it is, delete the old custom library. |
669 |
|
|
670 |
* Emacs fails to start, complaining about missing fonts. |
*** When you run Ispell from Emacs, it reports a "misalignment" error. |
671 |
|
|
672 |
A typical error message might be something like |
This can happen if you compiled the Ispell program to use ASCII |
673 |
|
characters only and then try to use it from Emacs with non-ASCII |
674 |
|
characters, like Latin-1. The solution is to recompile Ispell with |
675 |
|
support for 8-bit characters. |
676 |
|
|
677 |
No fonts match `-*-fixed-medium-r-*--6-*-*-*-*-*-iso8859-1' |
To see whether your Ispell program supports 8-bit characters, type |
678 |
|
this at your shell's prompt: |
679 |
|
|
680 |
This happens because some X resource specifies a bad font family for |
ispell -vv |
|
Emacs to use. The possible places where this specification might be |
|
|
are: |
|
681 |
|
|
682 |
- in your ~/.Xdefaults file |
and look in the output for the string "NO8BIT". If Ispell says |
683 |
|
"!NO8BIT (8BIT)", your speller supports 8-bit characters; otherwise it |
684 |
|
does not. |
685 |
|
|
686 |
- client-side X resource file, such as ~/Emacs or |
To rebuild Ispell with 8-bit character support, edit the local.h file |
687 |
/usr/X11R6/lib/app-defaults/Emacs or |
in the Ispell distribution and make sure it does _not_ define NO8BIT. |
688 |
/usr/X11R6/lib/X11/app-defaults/Emacs |
Then rebuild the speller. |
689 |
|
|
690 |
One of these files might have bad or malformed specification of a |
Another possible cause for "misalignment" error messages is that the |
691 |
fontset that Emacs should use. To fix the problem, you need to find |
version of Ispell installed on your machine is old. Upgrade. |
|
the problematic line(s) and correct them. |
|
692 |
|
|
693 |
* Emacs 20 and later fails to load Lisp files at startup. |
Yet another possibility is that you are trying to spell-check a word |
694 |
|
in a language that doesn't fit the dictionary you choose for use by |
695 |
|
Ispell. (Ispell can only spell-check one language at a time, because |
696 |
|
it uses a single dictionary.) Make sure that the text you are |
697 |
|
spelling and the dictionary used by Ispell conform to each other. |
698 |
|
|
699 |
The typical error message might be like this: |
If your spell-checking program is Aspell, it has been reported that if |
700 |
|
you have a personal configuration file (normally ~/.aspell.conf), it |
701 |
|
can cause this error. Remove that file, execute `ispell-kill-ispell' |
702 |
|
in Emacs, and then try spell-checking again. |
703 |
|
|
704 |
"Cannot open load file: fontset" |
* Runtime problems related to font handling |
705 |
|
|
706 |
This could happen if you compress the file lisp/subdirs.el. That file |
** Under X11, some characters appear as hollow boxes. |
|
tells Emacs what are the directories where it should look for Lisp |
|
|
files. Emacs cannot work with subdirs.el compressed, since the |
|
|
Auto-compress mode it needs for this will not be loaded until later, |
|
|
when your .emacs file is processed. (The package `fontset.el' is |
|
|
required to set up fonts used to display text on window systems, and |
|
|
it's loaded very early in the startup procedure.) |
|
707 |
|
|
708 |
Similarly, any other .el file for which there's no corresponding .elc |
Each X11 font covers just a fraction of the characters that Emacs |
709 |
file could fail to load if it is compressed. |
supports. To display the whole range of Emacs characters requires |
710 |
|
many different fonts, collected into a fontset. |
711 |
|
|
712 |
The solution is to uncompress all .el files which don't have a .elc |
If some of the fonts called for in your fontset do not exist on your X |
713 |
file. |
server, then the characters that have no font appear as hollow boxes. |
714 |
|
You can remedy the problem by installing additional fonts. |
715 |
|
|
716 |
Another possible reason for such failures is stale *.elc files |
The intlfonts distribution includes a full spectrum of fonts that can |
717 |
lurking somewhere on your load-path. The following command will |
display all the characters Emacs supports. |
|
print any duplicate Lisp files that are present in load-path: |
|
718 |
|
|
719 |
emacs -q -batch -f list-load-path-shadows |
Another cause of this for specific characters is fonts which have a |
720 |
|
missing glyph and no default character. This is known to occur for |
721 |
|
character number 160 (no-break space) in some fonts, such as Lucida |
722 |
|
but Emacs sets the display table for the unibyte and Latin-1 version |
723 |
|
of this character to display a space. |
724 |
|
|
725 |
If this command prints any file names, some of these files are stale, |
** Under X11, some characters appear improperly aligned in their lines. |
|
and should be deleted or their directories removed from your |
|
|
load-path. |
|
726 |
|
|
727 |
* Emacs prints an error at startup after upgrading from an earlier version. |
You may have bad X11 fonts; try installing the intlfonts distribution. |
728 |
|
|
729 |
An example of such an error is: |
** Certain fonts make each line take one pixel more than it "should". |
730 |
|
|
731 |
x-complement-fontset-spec: "Wrong type argument: stringp, nil" |
This is because these fonts contain characters a little taller |
732 |
|
than the font's nominal height. Emacs needs to make sure that |
733 |
|
lines do not overlap. |
734 |
|
|
735 |
This can be another symptom of stale *.elc files in your load-path. |
** Loading fonts is very slow. |
|
The following command will print any duplicate Lisp files that are |
|
|
present in load-path: |
|
736 |
|
|
737 |
emacs -q -batch -f list-load-path-shadows |
You might be getting scalable fonts instead of precomputed bitmaps. |
738 |
|
Known scalable font directories are "Type1" and "Speedo". A font |
739 |
|
directory contains scalable fonts if it contains the file |
740 |
|
"fonts.scale". |
741 |
|
|
742 |
If this command prints any file names, some of these files are stale, |
If this is so, re-order your X windows font path to put the scalable |
743 |
and should be deleted or their directories removed from your |
font directories last. See the documentation of `xset' for details. |
|
load-path. |
|
744 |
|
|
745 |
* Attempting to visit remote files via ange-ftp fails. |
With some X servers, it may be necessary to take the scalable font |
746 |
|
directories out of your path entirely, at least for Emacs 19.26. |
747 |
|
Changes in the future may make this unnecessary. |
748 |
|
|
749 |
If the error message is "ange-ftp-file-modtime: Specified time is not |
** Font Lock displays portions of the buffer in incorrect faces. |
|
representable", then this could happen when `lukemftp' is used as the |
|
|
ftp client. This was reported to happen on Debian GNU/Linux, kernel |
|
|
version 2.4.3, with `lukemftp' 1.5-5, but might happen on other |
|
|
systems as well. To avoid this problem, switch to using the standard |
|
|
ftp client. On a Debian system, type |
|
750 |
|
|
751 |
update-alternatives --config ftp |
By far the most frequent cause of this is a parenthesis `(' or a brace |
752 |
|
`{' in column zero. Font Lock assumes that such a paren is outside of |
753 |
|
any comment or string. This is of course not true in general, but the |
754 |
|
vast majority of well-formatted program source files don't have such |
755 |
|
parens, and therefore this assumption is used to allow optimizations |
756 |
|
in Font Lock's syntactical analysis. These optimizations avoid some |
757 |
|
pathological cases where jit-lock, the Just-in-Time fontification |
758 |
|
introduced with Emacs 21.1, could significantly slow down scrolling |
759 |
|
through the buffer, especially scrolling backwards, and also jumping |
760 |
|
to the end of a very large buffer. |
761 |
|
|
762 |
and then choose /usr/bin/netkit-ftp. |
Beginning with version 21.4, a parenthesis or a brace in column zero |
763 |
|
is highlighted in bold-red face if it is inside a string or a comment, |
764 |
|
to indicate that it could interfere with Font Lock (and also with |
765 |
|
indentation) and should be moved or escaped with a backslash. |
766 |
|
|
767 |
* Antivirus software interacts badly with the MS-Windows version of Emacs. |
If you don't use large buffers, or have a very fast machine which |
768 |
|
makes the delays insignificant, you can avoid the incorrect |
769 |
|
fontification by setting the variable |
770 |
|
`font-lock-beginning-of-syntax-function' to a nil value. (This must |
771 |
|
be done _after_ turning on Font Lock.) |
772 |
|
|
773 |
The usual manifestation of these problems is that subprocesses don't |
Another alternative is to avoid a paren in column zero. For example, |
774 |
work or even wedge the entire system. In particular, "M-x shell RET" |
in a Lisp string you could precede the paren with a backslash. |
|
was reported to fail to work. But other commands also sometimes don't |
|
|
work when an antivirus package is installed. |
|
775 |
|
|
776 |
The solution is to switch the antivirus software to a less aggressive |
** With certain fonts, when the cursor appears on a character, the |
777 |
mode (e.g., disable the ``auto-protect'' feature), or even uninstall |
character doesn't appear--you get a solid box instead. |
|
or disable it entirely. |
|
778 |
|
|
779 |
* On MS-Windows 95/98/ME, subprocesses do not terminate properly. |
One user on a Linux-based GNU system reported that this problem went |
780 |
|
away with installation of a new X server. The failing server was |
781 |
|
XFree86 3.1.1. XFree86 3.1.2 works. |
782 |
|
|
783 |
This is a limitation of the Operating System, and can cause problems |
** Characters are displayed as empty boxes or with wrong font under X. |
|
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/. |
|
784 |
|
|
785 |
* MS-Windows 95/98/ME crashes when Emacs invokes non-existent programs. |
This can occur when two different versions of FontConfig are used. |
786 |
|
For example, XFree86 4.3.0 has one version and Gnome usually comes |
787 |
|
with a newer version. Emacs compiled with --with-gtk will then use |
788 |
|
the newer version. In most cases the problem can be temporarily |
789 |
|
fixed by stopping the application that has the error (it can be |
790 |
|
Emacs or any other application), removing ~/.fonts.cache-1, |
791 |
|
and then start the application again. |
792 |
|
If removing ~/.fonts.cache-1 and restarting doesn't help, the |
793 |
|
application with problem must be recompiled with the same version |
794 |
|
of FontConfig as the rest of the system uses. For KDE, it is |
795 |
|
sufficient to recompile Qt. |
796 |
|
|
797 |
When a program you are trying to run is not found on the PATH, |
** Emacs pauses for several seconds when changing the default font. |
|
Windows might respond by crashing or locking up your system. In |
|
|
particular, this has been reported when trying to compile a Java |
|
|
program in JDEE when javac.exe is installed, but not on the system |
|
|
PATH. |
|
798 |
|
|
799 |
* Pressing the mouse button on MS-Windows does not give a mouse-2 event. |
This has been reported for fvwm 2.2.5 and the window manager of KDE |
800 |
|
2.1. The reason for the pause is Xt waiting for a ConfigureNotify |
801 |
|
event from the window manager, which the window manager doesn't send. |
802 |
|
Xt stops waiting after a default timeout of usually 5 seconds. |
803 |
|
|
804 |
This is usually a problem with the mouse driver. Because most Windows |
A workaround for this is to add something like |
|
programs do not do anything useful with the middle mouse button, many |
|
|
mouse drivers allow you to define the wheel press to do something |
|
|
different. Some drivers do not even have the option to generate a |
|
|
middle button press. In such cases, setting the wheel press to |
|
|
"scroll" sometimes works if you press the button twice. Trying a |
|
|
generic mouse driver might help. |
|
805 |
|
|
806 |
* Scrolling the mouse wheel on MS-Windows always scrolls the top window. |
emacs.waitForWM: false |
807 |
|
|
808 |
This is another common problem with mouse drivers. Instead of |
to your X resources. Alternatively, add `(wait-for-wm . nil)' to a |
809 |
generating scroll events, some mouse drivers try to fake scroll bar |
frame's parameter list, like this: |
|
movement. But they are not intelligent enough to handle multiple |
|
|
scroll bars within a frame. Trying a generic mouse driver might help. |
|
810 |
|
|
811 |
* Mail sent through Microsoft Exchange in some encodings appears to be |
(modify-frame-parameters nil '((wait-for-wm . nil))) |
|
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. |
|
812 |
|
|
813 |
* After upgrading to a newer version of Emacs, the Meta key stops working. |
(this should go into your `.emacs' file). |
814 |
|
|
815 |
This was reported to happen on a GNU/Linux system distributed by |
** Underlines appear at the wrong position. |
|
Mandrake. The reason is that the previous version of Emacs was |
|
|
modified by Mandrake to make the Alt key act as the Meta key, on a |
|
|
keyboard where the Windows key is the one which produces the Meta |
|
|
modifier. A user who started using a newer version of Emacs, which |
|
|
was not hacked by Mandrake, expected the Alt key to continue to act as |
|
|
Meta, and was astonished when that didn't happen. |
|
816 |
|
|
817 |
The solution is to find out what key on your keyboard produces the Meta |
This is caused by fonts having a wrong UNDERLINE_POSITION property. |
818 |
modifier, and use that key instead. Try all of the keys to the left |
Examples are the font 7x13 on XFree prior to version 4.1, or the jmk |
819 |
and to the right of the space bar, together with the `x' key, and see |
neep font from the Debian xfonts-jmk package. To circumvent this |
820 |
which combination produces "M-x" in the echo area. You can also use |
problem, set x-use-underline-position-properties to nil in your |
821 |
the `xmodmap' utility to show all the keys which produce a Meta |
`.emacs'. |
|
modifier: |
|
822 |
|
|
823 |
xmodmap -pk | egrep -i "meta|alt" |
To see what is the value of UNDERLINE_POSITION defined by the font, |
824 |
|
type `xlsfonts -lll FONT' and look at the font's UNDERLINE_POSITION |
825 |
|
property. |
826 |
|
|
827 |
A more convenient way of finding out which keys produce a Meta modifier |
** When using Exceed, fonts sometimes appear too tall. |
|
is to use the `xkbprint' utility, if it's available on your system: |
|
828 |
|
|
829 |
xkbprint 0:0 /tmp/k.ps |
When the display is set to an Exceed X-server and fonts are specified |
830 |
|
(either explicitly with the -fn option or implicitly with X resources) |
831 |
|
then the fonts may appear "too tall". The actual character sizes are |
832 |
|
correct but there is too much vertical spacing between rows, which |
833 |
|
gives the appearance of "double spacing". |
834 |
|
|
835 |
This produces a PostScript file `/tmp/k.ps' with a picture of your |
To prevent this, turn off the Exceed's "automatic font substitution" |
836 |
keyboard; printing that file on a PostScript printer will show what |
feature (in the font part of the configuration window). |
|
keys can serve as Meta. |
|
837 |
|
|
838 |
The `xkeycaps' also shows a visual representation of the current |
* Internationalization problems |
|
keyboard settings. It also allows to modify them. |
|
839 |
|
|
840 |
* On OSF/Dec Unix/Tru64/<whatever it is this year> under X locally or |
** Characters from the mule-unicode charsets aren't displayed under X. |
|
remotely, M-SPC acts as a `compose' key with strange results. See |
|
|
keyboard(5). |
|
841 |
|
|
842 |
Changing Alt_L to Meta_L fixes it: |
XFree86 4 contains many fonts in iso10646-1 encoding which have |
843 |
% xmodmap -e 'keysym Alt_L = Meta_L Alt_L' |
minimal character repertoires (whereas the encoding part of the font |
844 |
% xmodmap -e 'keysym Alt_R = Meta_R Alt_R' |
name is meant to be a reasonable indication of the repertoire |
845 |
|
according to the XLFD spec). Emacs may choose one of these to display |
846 |
|
characters from the mule-unicode charsets and then typically won't be |
847 |
|
able to find the glyphs to display many characters. (Check with C-u |
848 |
|
C-x = .) To avoid this, you may need to use a fontset which sets the |
849 |
|
font for the mule-unicode sets explicitly. E.g. to use GNU unifont, |
850 |
|
include in the fontset spec: |
851 |
|
|
852 |
* Error "conflicting types for `initstate'" compiling with GCC on Irix 6. |
mule-unicode-2500-33ff:-gnu-unifont-*-iso10646-1,\ |
853 |
|
mule-unicode-e000-ffff:-gnu-unifont-*-iso10646-1,\ |
854 |
|
mule-unicode-0100-24ff:-gnu-unifont-*-iso10646-1 |
855 |
|
|
856 |
Install GCC 2.95 or a newer version, and this problem should go away. |
** The UTF-8/16/7 coding systems don't encode CJK (Far Eastern) characters. |
|
It is possible that this problem results from upgrading the operating |
|
|
system without reinstalling GCC; so you could also try reinstalling |
|
|
the same version of GCC, and telling us whether that fixes the problem. |
|
857 |
|
|
858 |
* Emacs dumps core on Solaris in function IMCheckWindow. |
Emacs by default only supports the parts of the Unicode BMP whose code |
859 |
|
points are in the ranges 0000-33ff and e000-ffff. This excludes: most |
860 |
|
of CJK, Yi and Hangul, as well as everything outside the BMP. |
861 |
|
|
862 |
This was reported to happen when Emacs runs with more than one frame, |
If you read UTF-8 data with code points outside these ranges, the |
863 |
and one of them is closed, either with "C-x 5 0" or from the window |
characters appear in the buffer as raw bytes of the original UTF-8 |
864 |
manager. |
(composed into a single quasi-character) and they will be written back |
865 |
|
correctly as UTF-8, assuming you don't break the composed sequences. |
866 |
|
If you read such characters from UTF-16 or UTF-7 data, they are |
867 |
|
substituted with the Unicode `replacement character', and you lose |
868 |
|
information. |
869 |
|
|
870 |
This bug was reported to Sun as |
To edit such UTF data, turn on Utf-Translate-Cjk mode, which makes |
871 |
|
many common CJK characters available for encoding and decoding and can |
872 |
|
be extended by updating the tables it uses. This also allows you to |
873 |
|
save as UTF buffers containing characters decoded by the chinese-, |
874 |
|
japanese- and korean- coding systems, e.g. cut and pasted from |
875 |
|
elsewhere. |
876 |
|
|
877 |
Gtk apps dump core in ximlocal.so.2:IMCheckIMWindow() |
** Mule-UCS loads very slowly. |
|
Bug Reports: 4463537 |
|
878 |
|
|
879 |
Installing Solaris 8 patch 108773-12 for Sparc and 108774-12 for x86 |
Changes to Emacs internals interact badly with Mule-UCS's `un-define' |
880 |
reportedly fixes the bug, which appears to be inside the shared |
library, which is the usual interface to Mule-UCS. Apply the |
881 |
library xiiimp.so. |
following patch to Mule-UCS 0.84 and rebuild it. That will help, |
882 |
|
though loading will still be slower than in Emacs 20. (Some |
883 |
|
distributions, such as Debian, may already have applied such a patch.) |
884 |
|
|
885 |
Alternatively, you can configure Emacs with `--with-xim=no' to prevent |
--- lisp/un-define.el 6 Mar 2001 22:41:38 -0000 1.30 |
886 |
the core dump, but will loose X input method support, of course. (You |
+++ lisp/un-define.el 19 Apr 2002 18:34:26 -0000 |
887 |
can use Emacs's own input methods instead, if you install Leim.) |
@@ -610,13 +624,21 @@ by calling post-read-conversion and pre- |
888 |
|
|
889 |
* On Solaris 7, Emacs gets a segmentation fault when starting up using X. |
(mapcar |
890 |
|
(lambda (x) |
891 |
|
- (mapcar |
892 |
|
- (lambda (y) |
893 |
|
- (mucs-define-coding-system |
894 |
|
- (nth 0 y) (nth 1 y) (nth 2 y) |
895 |
|
- (nth 3 y) (nth 4 y) (nth 5 y) (nth 6 y)) |
896 |
|
- (coding-system-put (car y) 'alias-coding-systems (list (car x)))) |
897 |
|
- (cdr x))) |
898 |
|
+ (if (fboundp 'register-char-codings) |
899 |
|
+ ;; Mule 5, where we don't need the eol-type specified and |
900 |
|
+ ;; register-char-codings may be very slow for these coding |
901 |
|
+ ;; system definitions. |
902 |
|
+ (let ((y (cadr x))) |
903 |
|
+ (mucs-define-coding-system |
904 |
|
+ (car x) (nth 1 y) (nth 2 y) |
905 |
|
+ (nth 3 y) (nth 4 y) (nth 5 y))) |
906 |
|
+ (mapcar |
907 |
|
+ (lambda (y) |
908 |
|
+ (mucs-define-coding-system |
909 |
|
+ (nth 0 y) (nth 1 y) (nth 2 y) |
910 |
|
+ (nth 3 y) (nth 4 y) (nth 5 y) (nth 6 y)) |
911 |
|
+ (coding-system-put (car y) 'alias-coding-systems (list (car x))))) |
912 |
|
+ (cdr x))) |
913 |
|
`((utf-8 |
914 |
|
(utf-8-unix |
915 |
|
?u "UTF-8 coding system" |
916 |
|
|
917 |
This results from Sun patch 107058-01 (SunOS 5.7: Patch for |
Note that Emacs has native support for Unicode, roughly equivalent to |
918 |
assembler) if you use GCC version 2.7 or later. |
Mule-UCS's, so you may not need it. |
|
To work around it, either install patch 106950-03 or later, |
|
|
or uninstall patch 107058-01, or install the GNU Binutils. |
|
|
Then recompile Emacs, and it should work. |
|
919 |
|
|
920 |
* With X11R6.4, public-patch-3, Emacs crashes at startup. |
** Accented ISO-8859-1 characters are displayed as | or _. |
921 |
|
|
922 |
Reportedly this patch in X fixes the problem. |
Try other font set sizes (S-mouse-1). If the problem persists with |
923 |
|
other sizes as well, your text is corrupted, probably through software |
924 |
|
that is not 8-bit clean. If the problem goes away with another font |
925 |
|
size, it's probably because some fonts pretend to be ISO-8859-1 fonts |
926 |
|
when they are really ASCII fonts. In particular the schumacher-clean |
927 |
|
fonts have this bug in some versions of X. |
928 |
|
|
929 |
--- xc/lib/X11/imInt.c~ Wed Jun 30 13:31:56 1999 |
To see what glyphs are included in a font, use `xfd', like this: |
|
+++ xc/lib/X11/imInt.c Thu Jul 1 15:10:27 1999 |
|
|
@@ -1,4 +1,4 @@ |
|
|
-/* $TOG: imInt.c /main/5 1998/05/30 21:11:16 kaleb $ */ |
|
|
+/* $TOG: imInt.c /main/5 1998/05/30 21:11:16 kaleb $ */ |
|
|
/****************************************************************** |
|
930 |
|
|
931 |
Copyright 1992, 1993, 1994 by FUJITSU LIMITED |
xfd -fn -schumacher-clean-medium-r-normal--12-120-75-75-c-60-iso8859-1 |
|
@@ -166,8 +166,8 @@ |
|
|
_XimMakeImName(lcd) |
|
|
XLCd lcd; |
|
|
{ |
|
|
- char* begin; |
|
|
- char* end; |
|
|
+ char* begin = NULL; |
|
|
+ char* end = NULL; |
|
|
char* ret; |
|
|
int i = 0; |
|
|
char* ximmodifier = XIMMODIFIER; |
|
|
@@ -182,7 +182,11 @@ |
|
|
} |
|
|
ret = Xmalloc(end - begin + 2); |
|
|
if (ret != NULL) { |
|
|
- (void)strncpy(ret, begin, end - begin + 1); |
|
|
+ if (begin != NULL) { |
|
|
+ (void)strncpy(ret, begin, end - begin + 1); |
|
|
+ } else { |
|
|
+ ret[0] = '\0'; |
|
|
+ } |
|
|
ret[end - begin + 1] = '\0'; |
|
|
} |
|
|
return ret; |
|
932 |
|
|
933 |
|
If this shows only ASCII glyphs, the font is indeed the source of the |
934 |
|
problem. |
935 |
|
|
936 |
* Emacs crashes on Irix 6.5 on the SGI R10K, when compiled with GCC. |
The solution is to remove the corresponding lines from the appropriate |
937 |
|
`fonts.alias' file, then run `mkfontdir' in that directory, and then run |
938 |
|
`xset fp rehash'. |
939 |
|
|
940 |
This seems to be fixed in GCC 2.95. |
** The `oc-unicode' package doesn't work with Emacs 21. |
941 |
|
|
942 |
* Emacs crashes in utmpname on Irix 5.3. |
This package tries to define more private charsets than there are free |
943 |
|
slots now. The current built-in Unicode support is actually more |
944 |
|
flexible. (Use option `utf-translate-cjk-mode' if you need CJK |
945 |
|
support.) Files encoded as emacs-mule using oc-unicode aren't |
946 |
|
generally read correctly by Emacs 21. |
947 |
|
|
948 |
This problem is fixed in Patch 3175 for Irix 5.3. |
** After a while, Emacs slips into unibyte mode. |
|
It is also fixed in Irix versions 6.2 and up. |
|
949 |
|
|
950 |
* The S-C-t key combination doesn't get passed to Emacs on X. |
The VM mail package, which is not part of Emacs, sometimes does |
951 |
|
(standard-display-european t) |
952 |
|
That should be changed to |
953 |
|
(standard-display-european 1 t) |
954 |
|
|
955 |
This happens because some X configurations assign the Ctrl-Shift-t |
* X runtime problems |
|
combination the same meaning as the Multi_key. The offending |
|
|
definition is in the file `...lib/X11/locale/iso8859-1/Compose'; there |
|
|
might be other similar combinations which are grabbed by X for similar |
|
|
purposes. |
|
956 |
|
|
957 |
We think that this can be countermanded with the `xmodmap' utility, if |
** X keyboard problems |
|
you want to be able to bind one of these key sequences within Emacs. |
|
958 |
|
|
959 |
* On Solaris, CTRL-t is ignored by Emacs when you use |
*** You "lose characters" after typing Compose Character key. |
|
the fr.ISO-8859-15 locale (and maybe other related locales). |
|
960 |
|
|
961 |
You can fix this by editing the file: |
This is because the Compose Character key is defined as the keysym |
962 |
|
Multi_key, and Emacs (seeing that) does the proper X11 |
963 |
|
character-composition processing. If you don't want your Compose key |
964 |
|
to do that, you can redefine it with xmodmap. |
965 |
|
|
966 |
/usr/openwin/lib/locale/iso8859-15/Compose |
For example, here's one way to turn it into a Meta key: |
967 |
|
|
968 |
Near the bottom there is a line that reads: |
xmodmap -e "keysym Multi_key = Meta_L" |
969 |
|
|
970 |
Ctrl<t> <quotedbl> <Y> : "\276" threequarters |
If all users at your site of a particular keyboard prefer Meta to |
971 |
|
Compose, you can make the remapping happen automatically by adding the |
972 |
|
xmodmap command to the xdm setup script for that display. |
973 |
|
|
974 |
that should read: |
*** Using X Windows, control-shift-leftbutton makes Emacs hang. |
975 |
|
|
976 |
Ctrl<T> <quotedbl> <Y> : "\276" threequarters |
Use the shell command `xset bc' to make the old X Menu package work. |
977 |
|
|
978 |
Note the lower case <t>. Changing this line should make C-t work. |
*** M-SPC seems to be ignored as input. |
979 |
|
|
980 |
* Emacs on Digital Unix 4.0 fails to build, giving error message |
See if your X server is set up to use this as a command |
981 |
Invalid dimension for the charset-ID 160 |
for character composition. |
982 |
|
|
983 |
This is due to a bug or an installation problem in GCC 2.8.0. |
*** The S-C-t key combination doesn't get passed to Emacs on X. |
|
Installing a more recent version of GCC fixes the problem. |
|
984 |
|
|
985 |
* Buffers from `with-output-to-temp-buffer' get set up in Help mode. |
This happens because some X configurations assign the Ctrl-Shift-t |
986 |
|
combination the same meaning as the Multi_key. The offending |
987 |
|
definition is in the file `...lib/X11/locale/iso8859-1/Compose'; there |
988 |
|
might be other similar combinations which are grabbed by X for similar |
989 |
|
purposes. |
990 |
|
|
991 |
Changes in Emacs 20.4 to the hooks used by that function cause |
We think that this can be countermanded with the `xmodmap' utility, if |
992 |
problems for some packages, specifically BBDB. See the function's |
you want to be able to bind one of these key sequences within Emacs. |
|
documentation for the hooks involved. BBDB 2.00.06 fixes the problem. |
|
993 |
|
|
994 |
* Under X, C-v and/or other keys don't work. |
*** Under X, C-v and/or other keys don't work. |
995 |
|
|
996 |
These may have been intercepted by your window manager. In |
These may have been intercepted by your window manager. In |
997 |
particular, AfterStep 1.6 is reported to steal C-v in its default |
particular, AfterStep 1.6 is reported to steal C-v in its default |
999 |
configuration of the `feel'. See the WM's documentation for how to |
configuration of the `feel'. See the WM's documentation for how to |
1000 |
change this. |
change this. |
1001 |
|
|
1002 |
* When using Exceed, fonts sometimes appear too tall. |
*** Clicking C-mouse-2 in the scroll bar doesn't split the window. |
|
|
|
|
When the display is set to an Exceed X-server and fonts are specified |
|
|
(either explicitly with the -fn option or implicitly with X resources) |
|
|
then the fonts may appear "too tall". The actual character sizes are |
|
|
correct but there is too much vertical spacing between rows, which |
|
|
gives the appearance of "double spacing". |
|
|
|
|
|
To prevent this, turn off the Exceed's "automatic font substitution" |
|
|
feature (in the font part of the configuration window). |
|
|
|
|
|
* Failure in unexec while dumping emacs on Digital Unix 4.0 |
|
|
|
|
|
This problem manifests itself as an error message |
|
|
|
|
|
unexec: Bad address, writing data section to ... |
|
|
|
|
|
The user suspects that this happened because his X libraries |
|
|
were built for an older system version, |
|
|
|
|
|
./configure --x-includes=/usr/include --x-libraries=/usr/shlib |
|
|
|
|
|
made the problem go away. |
|
|
|
|
|
* No visible display on mips-sgi-irix6.2 when compiling with GCC 2.8.1. |
|
|
|
|
|
This problem went away after installing the latest IRIX patches |
|
|
as of 8 Dec 1998. |
|
|
|
|
|
The same problem has been reported on Irix 6.3. |
|
|
|
|
|
* As of version 20.4, Emacs doesn't work properly if configured for |
|
|
the Motif toolkit and linked against the free LessTif library. The |
|
|
next Emacs release is expected to work with LessTif. |
|
|
|
|
|
* Emacs gives the error, Couldn't find per display information. |
|
|
|
|
|
This can result if the X server runs out of memory because Emacs uses |
|
|
a large number of fonts. On systems where this happens, C-h h is |
|
|
likely to cause it. |
|
|
|
|
|
We do not know of a way to prevent the problem. |
|
|
|
|
|
* Emacs makes HPUX 11.0 crash. |
|
1003 |
|
|
1004 |
This is a bug in HPUX; HPUX patch PHKL_16260 is said to fix it. |
This currently doesn't work with scroll-bar widgets (and we don't know |
1005 |
|
a good way of implementing it with widgets). If Emacs is configured |
1006 |
* Emacs crashes during dumping on the HPPA machine (HPUX 10.20). |
--without-toolkit-scroll-bars, C-mouse-2 on the scroll bar does work. |
|
|
|
|
This seems to be due to a GCC bug; it is fixed in GCC 2.8.1. |
|
|
|
|
|
* The Hyperbole package causes *Help* buffers not to be displayed in |
|
|
Help mode due to setting `temp-buffer-show-hook' rather than using |
|
|
`add-hook'. Using `(add-hook 'temp-buffer-show-hook |
|
|
'help-mode-maybe)' after loading Hyperbole should fix this. |
|
|
|
|
|
* Versions of the PSGML package earlier than 1.0.3 (stable) or 1.1.2 |
|
|
(alpha) fail to parse DTD files correctly in Emacs 20.3 and later. |
|
|
Here is a patch for psgml-parse.el from PSGML 1.0.1 and, probably, |
|
|
earlier versions. |
|
|
|
|
|
--- psgml-parse.el 1998/08/21 19:18:18 1.1 |
|
|
+++ psgml-parse.el 1998/08/21 19:20:00 |
|
|
@@ -2383,7 +2383,7 @@ (defun sgml-push-to-entity (entity &opti |
|
|
(setq sgml-buffer-parse-state nil)) |
|
|
(cond |
|
|
((stringp entity) ; a file name |
|
|
- (save-excursion (insert-file-contents entity)) |
|
|
+ (insert-file-contents entity) |
|
|
(setq default-directory (file-name-directory entity))) |
|
|
((consp (sgml-entity-text entity)) ; external id? |
|
|
(let* ((extid (sgml-entity-text entity)) |
|
|
|
|
|
* Emacs 21 freezes when visiting a TeX file with AUC TeX installed. |
|
1007 |
|
|
1008 |
Emacs 21 needs version 10 or later of AUC TeX; upgrading should solve |
*** Inability to send an Alt-modified key, when Emacs is communicating |
1009 |
these problems. |
directly with an X server. |
1010 |
|
|
1011 |
* No colors in AUC TeX with Emacs 21. |
If you have tried to bind an Alt-modified key as a command, and it |
1012 |
|
does not work to type the command, the first thing you should check is |
1013 |
|
whether the key is getting through to Emacs. To do this, type C-h c |
1014 |
|
followed by the Alt-modified key. C-h c should say what kind of event |
1015 |
|
it read. If it says it read an Alt-modified key, then make sure you |
1016 |
|
have made the key binding correctly. |
1017 |
|
|
1018 |
Upgrade to AUC TeX version 10 or later, and make sure it is |
If C-h c reports an event that doesn't have the Alt modifier, it may |
1019 |
byte-compiled with Emacs 21. |
be because your X server has no key for the Alt modifier. The X |
1020 |
|
server that comes from MIT does not set up the Alt modifier by |
1021 |
|
default. |
1022 |
|
|
1023 |
* Running TeX from AUC TeX package with Emacs 20.3 gives a Lisp error |
If your keyboard has keys named Alt, you can enable them as follows: |
|
about a read-only tex output buffer. |
|
1024 |
|
|
1025 |
This problem appeared for AUC TeX version 9.9j and some earlier |
xmodmap -e 'add mod2 = Alt_L' |
1026 |
versions. Here is a patch for the file tex-buf.el in the AUC TeX |
xmodmap -e 'add mod2 = Alt_R' |
|
package. |
|
|
|
|
|
diff -c auctex/tex-buf.el~ auctex/tex-buf.el |
|
|
*** auctex/tex-buf.el~ Wed Jul 29 18:35:32 1998 |
|
|
--- auctex/tex-buf.el Sat Sep 5 15:20:38 1998 |
|
|
*************** |
|
|
*** 545,551 **** |
|
|
(dir (TeX-master-directory))) |
|
|
(TeX-process-check file) ; Check that no process is running |
|
|
(setq TeX-command-buffer (current-buffer)) |
|
|
! (with-output-to-temp-buffer buffer) |
|
|
(set-buffer buffer) |
|
|
(if dir (cd dir)) |
|
|
(insert "Running `" name "' on `" file "' with ``" command "''\n") |
|
|
- --- 545,552 ---- |
|
|
(dir (TeX-master-directory))) |
|
|
(TeX-process-check file) ; Check that no process is running |
|
|
(setq TeX-command-buffer (current-buffer)) |
|
|
! (let (temp-buffer-show-function temp-buffer-show-hook) |
|
|
! (with-output-to-temp-buffer buffer)) |
|
|
(set-buffer buffer) |
|
|
(if dir (cd dir)) |
|
|
(insert "Running `" name "' on `" file "' with ``" command "''\n") |
|
1027 |
|
|
1028 |
* On Irix 6.3, substituting environment variables in file names |
If the keyboard has just one key named Alt, then only one of those |
1029 |
in the minibuffer gives peculiar error messages such as |
commands is needed. The modifier `mod2' is a reasonable choice if you |
1030 |
|
are using an unmodified MIT version of X. Otherwise, choose any |
1031 |
|
modifier bit not otherwise used. |
1032 |
|
|
1033 |
Substituting nonexistent environment variable "" |
If your keyboard does not have keys named Alt, you can use some other |
1034 |
|
keys. Use the keysym command in xmodmap to turn a function key (or |
1035 |
|
some other 'spare' key) into Alt_L or into Alt_R, and then use the |
1036 |
|
commands show above to make them modifier keys. |
1037 |
|
|
1038 |
This is not an Emacs bug; it is caused by something in SGI patch |
Note that if you have Alt keys but no Meta keys, Emacs translates Alt |
1039 |
003082 August 11, 1998. |
into Meta. This is because of the great importance of Meta in Emacs. |
1040 |
|
|
1041 |
* After a while, Emacs slips into unibyte mode. |
** Window-manager and toolkit-related problems |
1042 |
|
|
1043 |
The VM mail package, which is not part of Emacs, sometimes does |
*** Gnome: Emacs' xterm-mouse-mode doesn't work on the Gnome terminal. |
|
(standard-display-european t) |
|
|
That should be changed to |
|
|
(standard-display-european 1 t) |
|
1044 |
|
|
1045 |
* Installing Emacs gets an error running `install-info'. |
A symptom of this bug is that double-clicks insert a control sequence |
1046 |
|
into the buffer. The reason this happens is an apparent |
1047 |
|
incompatibility of the Gnome terminal with Xterm, which also affects |
1048 |
|
other programs using the Xterm mouse interface. A problem report has |
1049 |
|
been filed. |
1050 |
|
|
1051 |
You need to install a recent version of Texinfo; that package |
*** KDE: When running on KDE, colors or fonts are not as specified for Emacs, |
1052 |
supplies the `install-info' command. |
or messed up. |
1053 |
|
|
1054 |
* Emacs does not recognize the AltGr key, on HPUX. |
For example, you could see background you set for Emacs only in the |
1055 |
|
empty portions of the Emacs display, while characters have some other |
1056 |
|
background. |
1057 |
|
|
1058 |
To fix this, set up a file ~/.dt/sessions/sessionetc with executable |
This happens because KDE's defaults apply its color and font |
1059 |
rights, containing this text: |
definitions even to applications that weren't compiled for KDE. The |
1060 |
|
solution is to uncheck the "Apply fonts and colors to non-KDE apps" |
1061 |
|
option in Preferences->Look&Feel->Style (KDE 2). In KDE 3, this option |
1062 |
|
is in the "Colors" section, rather than "Style". |
1063 |
|
|
1064 |
-------------------------------- |
Alternatively, if you do want the KDE defaults to apply to other |
1065 |
xmodmap 2> /dev/null - << EOF |
applications, but not to Emacs, you could modify the file `Emacs.ad' |
1066 |
keysym Alt_L = Meta_L |
(should be in the `/usr/share/apps/kdisplay/app-defaults/' directory) |
1067 |
keysym Alt_R = Meta_R |
so that it doesn't set the default background and foreground only for |
1068 |
EOF |
Emacs. For example, make sure the following resources are either not |
1069 |
|
present or commented out: |
1070 |
|
|
1071 |
xmodmap - << EOF |
Emacs.default.attributeForeground |
1072 |
clear mod1 |
Emacs.default.attributeBackground |
1073 |
keysym Mode_switch = NoSymbol |
Emacs*Foreground |
1074 |
add mod1 = Meta_L |
Emacs*Background |
|
keysym Meta_R = Mode_switch |
|
|
add mod2 = Mode_switch |
|
|
EOF |
|
|
-------------------------------- |
|
1075 |
|
|
1076 |
* Emacs hangs on KDE when a large portion of text is killed. |
*** KDE: Emacs hangs on KDE when a large portion of text is killed. |
1077 |
|
|
1078 |
This is caused by a bug in the KDE applet `klipper' which periodically |
This is caused by a bug in the KDE applet `klipper' which periodically |
1079 |
requests the X clipboard contents from applications. Early versions |
requests the X clipboard contents from applications. Early versions |
1085 |
|
|
1086 |
A workaround is to not use `klipper'. |
A workaround is to not use `klipper'. |
1087 |
|
|
1088 |
* Emacs compiled with DJGPP for MS-DOS/MS-Windows cannot access files |
*** CDE: Frames may cover dialogs they created when using CDE. |
|
in the directory with the special name `dev' under the root of any |
|
|
drive, e.g. `c:/dev'. |
|
|
|
|
|
This is an unfortunate side-effect of the support for Unix-style |
|
|
device names such as /dev/null in the DJGPP runtime library. A |
|
|
work-around is to rename the problem directory to another name. |
|
|
|
|
|
* M-SPC seems to be ignored as input. |
|
|
|
|
|
See if your X server is set up to use this as a command |
|
|
for character composition. |
|
|
|
|
|
* Emacs startup on GNU/Linux systems (and possibly other systems) is slow. |
|
1089 |
|
|
1090 |
This can happen if the system is misconfigured and Emacs can't get the |
This can happen if you have "Allow Primary Windows On Top" enabled which |
1091 |
full qualified domain name, FQDN. You should have your FQDN in the |
seems to be the default in the Common Desktop Environment. |
1092 |
/etc/hosts file, something like this: |
To change, go in to "Desktop Controls" -> "Window Style Manager" |
1093 |
|
and uncheck "Allow Primary Windows On Top". |
|
127.0.0.1 localhost |
|
|
129.187.137.82 nuc04.t30.physik.tu-muenchen.de nuc04 |
|
1094 |
|
|
1095 |
The way to set this up may vary on non-GNU systems. |
*** Xaw3d : When using Xaw3d scroll bars without arrows, the very first mouse |
1096 |
|
click in a scroll bar might be ignored by the scroll bar widget. This |
1097 |
|
is probably a bug in Xaw3d; when Xaw3d is compiled with arrows, the |
1098 |
|
problem disappears. |
1099 |
|
|
1100 |
* Garbled display on non-X terminals when Emacs runs on Digital Unix 4.0. |
*** Xaw: There are known binary incompatibilities between Xaw, Xaw3d, neXtaw, |
1101 |
|
XawM and the few other derivatives of Xaw. So when you compile with |
1102 |
|
one of these, it may not work to dynamically link with another one. |
1103 |
|
For example, strange problems, such as Emacs exiting when you type |
1104 |
|
"C-x 1", were reported when Emacs compiled with Xaw3d and libXaw was |
1105 |
|
used with neXtaw at run time. |
1106 |
|
|
1107 |
So far it appears that running `tset' triggers this problem (when TERM |
The solution is to rebuild Emacs with the toolkit version you actually |
1108 |
is vt100, at least). If you do not run `tset', then Emacs displays |
want to use, or set LD_PRELOAD to preload the same toolkit version you |
1109 |
properly. If someone can tell us precisely which effect of running |
built Emacs with. |
|
`tset' actually causes the problem, we may be able to implement a fix |
|
|
in Emacs. |
|
1110 |
|
|
1111 |
* When you run Ispell from Emacs, it reports a "misalignment" error. |
*** Open Motif: Problems with file dialogs in Emacs built with Open Motif. |
1112 |
|
|
1113 |
This can happen if you compiled the Ispell program to use ASCII |
When Emacs 21 is built with Open Motif 2.1, it can happen that the |
1114 |
characters only and then try to use it from Emacs with non-ASCII |
graphical file dialog boxes do not work properly. The "OK", "Filter" |
1115 |
characters, like Latin-1. The solution is to recompile Ispell with |
and "Cancel" buttons do not respond to mouse clicks. Dragging the |
1116 |
support for 8-bit characters. |
file dialog window usually causes the buttons to work again. |
1117 |
|
|
1118 |
To see whether your Ispell program supports 8-bit characters, type |
The solution is to use LessTif instead. LessTif is a free replacement |
1119 |
this at your shell's prompt: |
for Motif. See the file INSTALL for information on how to do this. |
1120 |
|
|
1121 |
ispell -vv |
Another workaround is not to use the mouse to trigger file prompts, |
1122 |
|
but to use the keyboard. This way, you will be prompted for a file in |
1123 |
|
the minibuffer instead of a graphical file dialog. |
1124 |
|
|
1125 |
and look in the output for the string "NO8BIT". If Ispell says |
*** LessTif: Problems in Emacs built with LessTif. |
|
"!NO8BIT (8BIT)", your speller supports 8-bit characters; otherwise it |
|
|
does not. |
|
1126 |
|
|
1127 |
To rebuild Ispell with 8-bit character support, edit the local.h file |
The problems seem to depend on the version of LessTif and the Motif |
1128 |
in the Ispell distribution and make sure it does _not_ define NO8BIT. |
emulation for which it is set up. |
|
Then rebuild the speller. |
|
1129 |
|
|
1130 |
Another possible cause for "misalignment" error messages is that the |
Only the Motif 1.2 emulation seems to be stable enough in LessTif. |
1131 |
version of Ispell installed on your machine is old. Upgrade. |
Lesstif 0.92-17's Motif 1.2 emulation seems to work okay on FreeBSD. |
1132 |
|
On GNU/Linux systems, lesstif-0.92.6 configured with "./configure |
1133 |
|
--enable-build-12 --enable-default-12" is reported to be the most |
1134 |
|
successful. The binary GNU/Linux package |
1135 |
|
lesstif-devel-0.92.0-1.i386.rpm was reported to have problems with |
1136 |
|
menu placement. |
1137 |
|
|
1138 |
Yet another possibility is that you are trying to spell-check a word |
On some systems, even with Motif 1.2 emulation, Emacs occasionally |
1139 |
in a language that doesn't fit the dictionary you choose for use by |
locks up, grabbing all mouse and keyboard events. We still don't know |
1140 |
Ispell. (Ispell can only spell-check one language at a time, because |
what causes these problems; they are not reproducible by Emacs |
1141 |
it uses a single dictionary.) Make sure that the text you are |
developers. |
|
spelling and the dictionary used by Ispell conform to each other. |
|
1142 |
|
|
1143 |
If your spell-checking program is Aspell, it has been reported that if |
*** Motif: The Motif version of Emacs paints the screen a solid color. |
|
you have a personal configuration file (normally ~/.aspell.conf), it |
|
|
can cause this error. Remove that file, execute `ispell-kill-ispell' |
|
|
in Emacs, and then try spell-checking again. |
|
1144 |
|
|
1145 |
* On Linux-based GNU systems using libc versions 5.4.19 through |
This has been observed to result from the following X resource: |
|
5.4.22, Emacs crashes at startup with a segmentation fault. |
|
1146 |
|
|
1147 |
This problem happens if libc defines the symbol __malloc_initialized. |
Emacs*default.attributeFont: -*-courier-medium-r-*-*-*-140-*-*-*-*-iso8859-* |
|
One known solution is to upgrade to a newer libc version. 5.4.33 is |
|
|
known to work. |
|
1148 |
|
|
1149 |
* On MS-Windows, you cannot use the right-hand ALT key and the left-hand |
That the resource has this effect indicates a bug in something, but we |
1150 |
CTRL key together to type a Control-Meta character. |
do not yet know what. If it is an Emacs bug, we hope someone can |
1151 |
|
explain what the bug is so we can fix it. In the mean time, removing |
1152 |
|
the resource prevents the problem. |
1153 |
|
|
1154 |
This is a consequence of a misfeature beyond Emacs's control. |
** General X problems |
1155 |
|
|
1156 |
Under Windows, the AltGr key on international keyboards generates key |
*** Redisplay using X11 is much slower than previous Emacs versions. |
|
events with the modifiers Right-Alt and Left-Ctrl. Since Emacs cannot |
|
|
distinguish AltGr from an explicit Right-Alt and Left-Ctrl |
|
|
combination, whenever it sees Right-Alt and Left-Ctrl it assumes that |
|
|
AltGr has been pressed. The variable `w32-recognize-altgr' can be set |
|
|
to nil to tell Emacs that AltGr is really Ctrl and Alt. |
|
1157 |
|
|
1158 |
* Emacs crashes when using the Exceed 6.0 X server |
We've noticed that certain X servers draw the text much slower when |
1159 |
|
scroll bars are on the left. We don't know why this happens. If this |
1160 |
|
happens to you, you can work around it by putting the scroll bars |
1161 |
|
on the right (as they were in Emacs 19). |
1162 |
|
|
1163 |
If you are using Exceed 6.1, upgrade to a later version. This was |
Here's how to do this: |
|
reported to prevent the crashes. |
|
1164 |
|
|
1165 |
* Under some X-servers running on MS-Windows, Emacs' display is incorrect |
(set-scroll-bar-mode 'right) |
1166 |
|
|
1167 |
The symptoms are that Emacs does not completely erase blank areas of the |
If you're not sure whether (or how much) this problem affects you, |
1168 |
screen during scrolling or some other screen operations (e.g., selective |
try that and see how much difference it makes. To set things back |
1169 |
display or when killing a region). M-x recenter will cause the screen |
to normal, do |
|
to be completely redisplayed and the "extra" characters will disappear. |
|
1170 |
|
|
1171 |
This is known to occur under Exceed 6, and possibly earlier versions |
(set-scroll-bar-mode 'left) |
|
as well; it is reportedly solved in version 6.2.0.16 and later. The |
|
|
problem lies in the X-server settings. |
|
1172 |
|
|
1173 |
There are reports that you can solve the problem with Exceed by |
*** Error messages about undefined colors on X. |
|
running `Xconfig' from within NT, choosing "X selection", then |
|
|
un-checking the boxes "auto-copy X selection" and "auto-paste to X |
|
|
selection". |
|
1174 |
|
|
1175 |
Of this does not work, please inform bug-gnu-emacs@gnu.org. Then |
The messages might say something like this: |
|
please call support for your X-server and see if you can get a fix. |
|
|
If you do, please send it to bug-gnu-emacs@gnu.org so we can list it |
|
|
here. |
|
1176 |
|
|
1177 |
* On Solaris 2, Emacs dumps core when built with Motif. |
Unable to load color "grey95" |
1178 |
|
|
1179 |
The Solaris Motif libraries are buggy, at least up through Solaris 2.5.1. |
(typically, in the `*Messages*' buffer), or something like this: |
|
Install the current Motif runtime library patch appropriate for your host. |
|
|
(Make sure the patch is current; some older patch versions still have the bug.) |
|
|
You should install the other patches recommended by Sun for your host, too. |
|
|
You can obtain Sun patches from ftp://sunsolve.sun.com/pub/patches/; |
|
|
look for files with names ending in `.PatchReport' to see which patches |
|
|
are currently recommended for your host. |
|
1180 |
|
|
1181 |
On Solaris 2.6, Emacs is said to work with Motif when Solaris patch |
Error while displaying tooltip: (error Undefined color lightyellow) |
|
105284-12 is installed, but fail when 105284-15 is installed. |
|
|
105284-18 might fix it again. |
|
1182 |
|
|
1183 |
* On Solaris 2.6 and 7, the Compose key does not work. |
These problems could happen if some other X program has used up too |
1184 |
|
many colors of the X palette, leaving Emacs with insufficient system |
1185 |
|
resources to load all the colors it needs. |
1186 |
|
|
1187 |
This is a bug in Motif in Solaris. Supposedly it has been fixed for |
A solution is to exit the offending X programs before starting Emacs. |
|
the next major release of Solaris. However, if someone with Sun |
|
|
support complains to Sun about the bug, they may release a patch. |
|
|
If you do this, mention Sun bug #4188711. |
|
1188 |
|
|
1189 |
One workaround is to use a locale that allows non-ASCII characters. |
*** Improving performance with slow X connections. |
|
For example, before invoking emacs, set the LC_ALL environment |
|
|
variable to "en_US" (American English). The directory /usr/lib/locale |
|
|
lists the supported locales; any locale other than "C" or "POSIX" |
|
|
should do. |
|
1190 |
|
|
1191 |
pen@lysator.liu.se says (Feb 1998) that the Compose key does work |
There are several ways to improve this performance, any subset of which can |
1192 |
if you link with the MIT X11 libraries instead of the Solaris X11 |
be carried out at the same time: |
|
libraries. |
|
1193 |
|
|
1194 |
* Frames may cover dialogs they created when using CDE. |
1) If you don't need X Input Methods (XIM) for entering text in some |
1195 |
|
language you use, you can improve performance on WAN links by using |
1196 |
|
the X resource useXIM to turn off use of XIM. This does not affect |
1197 |
|
the use of Emacs' own input methods, which are part of the Leim |
1198 |
|
package. |
1199 |
|
|
1200 |
This can happen if you have "Allow Primary Windows On Top" enabled which |
2) If the connection is very slow, you might also want to consider |
1201 |
seems to be the default in the Common Desktop Environment. |
switching off scroll bars, menu bar, and tool bar. |
|
To change, go in to "Desktop Controls" -> "Window Style Manager" |
|
|
and uncheck "Allow Primary Windows On Top". |
|
1202 |
|
|
1203 |
* Emacs does not know your host's fully-qualified domain name. |
3) Use ssh to forward the X connection, and enable compression on this |
1204 |
|
forwarded X connection (ssh -XC remotehostname emacs ...). |
1205 |
|
|
1206 |
You need to configure your machine with a fully qualified domain name, |
4) Use lbxproxy on the remote end of the connection. This is an interface |
1207 |
either in /etc/hosts, /etc/hostname, the NIS, or wherever your system |
to the low bandwidth X extension in most modern X servers, which |
1208 |
calls for specifying this. |
improves performance dramatically, at the slight expense of correctness |
1209 |
|
of the X protocol. lbxproxy acheives the performance gain by grouping |
1210 |
|
several X requests in one TCP packet and sending them off together, |
1211 |
|
instead of requiring a round-trip for each X request in a seperate |
1212 |
|
packet. The switches that seem to work best for emacs are: |
1213 |
|
-noatomsfile -nowinattr -cheaterrors -cheatevents |
1214 |
|
Note that the -nograbcmap option is known to cause problems. |
1215 |
|
For more about lbxproxy, see: |
1216 |
|
http://www.xfree86.org/4.3.0/lbxproxy.1.html |
1217 |
|
|
1218 |
If you cannot fix the configuration, you can set the Lisp variable |
*** Emacs gives the error, Couldn't find per display information. |
|
mail-host-address to the value you want. |
|
1219 |
|
|
1220 |
* Error 12 (virtual memory exceeded) when dumping Emacs, on UnixWare 2.1 |
This can result if the X server runs out of memory because Emacs uses |
1221 |
|
a large number of fonts. On systems where this happens, C-h h is |
1222 |
|
likely to cause it. |
1223 |
|
|
1224 |
Paul Abrahams (abrahams@acm.org) reports that with the installed |
We do not know of a way to prevent the problem. |
|
virtual memory settings for UnixWare 2.1.2, an Error 12 occurs during |
|
|
the "make" that builds Emacs, when running temacs to dump emacs. That |
|
|
error indicates that the per-process virtual memory limit has been |
|
|
exceeded. The default limit is probably 32MB. Raising the virtual |
|
|
memory limit to 40MB should make it possible to finish building Emacs. |
|
1225 |
|
|
1226 |
You can do this with the command `ulimit' (sh) or `limit' (csh). |
*** Emacs does not notice when you release the mouse. |
|
But you have to be root to do it. |
|
1227 |
|
|
1228 |
According to Martin Sohnius, you can also retune this in the kernel: |
There are reports that this happened with (some) Microsoft mice and |
1229 |
|
that replacing the mouse made it stop. |
1230 |
|
|
1231 |
# /etc/conf/bin/idtune SDATLIM 33554432 ## soft data size limit |
*** You can't select from submenus (in the X toolkit version). |
|
# /etc/conf/bin/idtune HDATLIM 33554432 ## hard " |
|
|
# /etc/conf/bin/idtune SVMMSIZE unlimited ## soft process size limit |
|
|
# /etc/conf/bin/idtune HVMMSIZE unlimited ## hard " |
|
|
# /etc/conf/bin/idbuild -B |
|
1232 |
|
|
1233 |
(He recommends you not change the stack limit, though.) |
On certain systems, mouse-tracking and selection in top-level menus |
1234 |
These changes take effect when you reboot. |
works properly with the X toolkit, but neither of them works when you |
1235 |
|
bring up a submenu (such as Bookmarks or Compare or Apply Patch, in |
1236 |
|
the Files menu). |
1237 |
|
|
1238 |
* Redisplay using X11 is much slower than previous Emacs versions. |
This works on most systems. There is speculation that the failure is |
1239 |
|
due to bugs in old versions of X toolkit libraries, but no one really |
1240 |
|
knows. If someone debugs this and finds the precise cause, perhaps a |
1241 |
|
workaround can be found. |
1242 |
|
|
1243 |
We've noticed that certain X servers draw the text much slower when |
*** An error message such as `X protocol error: BadMatch (invalid |
1244 |
scroll bars are on the left. We don't know why this happens. If this |
parameter attributes) on protocol request 93'. |
|
happens to you, you can work around it by putting the scroll bars |
|
|
on the right (as they were in Emacs 19). |
|
1245 |
|
|
1246 |
Here's how to do this: |
This comes from having an invalid X resource, such as |
1247 |
|
emacs*Cursor: black |
1248 |
|
(which is invalid because it specifies a color name for something |
1249 |
|
that isn't a color.) |
1250 |
|
|
1251 |
(set-scroll-bar-mode 'right) |
The fix is to correct your X resources. |
1252 |
|
|
1253 |
If you're not sure whether (or how much) this problem affects you, |
*** Slow startup on X11R6 with X windows. |
|
try that and see how much difference it makes. To set things back |
|
|
to normal, do |
|
1254 |
|
|
1255 |
(set-scroll-bar-mode 'left) |
If Emacs takes two minutes to start up on X11R6, see if your X |
1256 |
|
resources specify any Adobe fonts. That causes the type-1 font |
1257 |
|
renderer to start up, even if the font you asked for is not a type-1 |
1258 |
|
font. |
1259 |
|
|
1260 |
* Under X11, some characters appear as hollow boxes. |
One way to avoid this problem is to eliminate the type-1 fonts from |
1261 |
|
your font path, like this: |
1262 |
|
|
1263 |
Each X11 font covers just a fraction of the characters that Emacs |
xset -fp /usr/X11R6/lib/X11/fonts/Type1/ |
|
supports. To display the whole range of Emacs characters requires |
|
|
many different fonts, collected into a fontset. |
|
1264 |
|
|
1265 |
If some of the fonts called for in your fontset do not exist on your X |
*** Pull-down menus appear in the wrong place, in the toolkit version of Emacs. |
|
server, then the characters that have no font appear as hollow boxes. |
|
|
You can remedy the problem by installing additional fonts. |
|
1266 |
|
|
1267 |
The intlfonts distribution includes a full spectrum of fonts that can |
An X resource of this form can cause the problem: |
|
display all the characters Emacs supports. |
|
1268 |
|
|
1269 |
Another cause of this for specific characters is fonts which have a |
Emacs*geometry: 80x55+0+0 |
|
missing glyph and no default character. This is known ot occur for |
|
|
character number 160 (no-break space) in some fonts, such as Lucida |
|
|
but Emacs sets the display table for the unibyte and Latin-1 version |
|
|
of this character to display a space. |
|
1270 |
|
|
1271 |
* Under X11, some characters appear improperly aligned in their lines. |
This resource is supposed to apply, and does apply, to the menus |
1272 |
|
individually as well as to Emacs frames. If that is not what you |
1273 |
|
want, rewrite the resource. |
1274 |
|
|
1275 |
You may have bad X11 fonts; try installing the intlfonts distribution. |
To check thoroughly for such resource specifications, use `xrdb |
1276 |
|
-query' to see what resources the X server records, and also look at |
1277 |
|
the user's ~/.Xdefaults and ~/.Xdefaults-* files. |
1278 |
|
|
1279 |
* Certain fonts make each line take one pixel more than it "should". |
*** --with-x-toolkit version crashes when used with shared libraries. |
1280 |
|
|
1281 |
This is because these fonts contain characters a little taller |
On some systems, including Sunos 4 and DGUX 5.4.2 and perhaps others, |
1282 |
than the font's nominal height. Emacs needs to make sure that |
unexec doesn't work properly with the shared library for the X |
1283 |
lines do not overlap. |
toolkit. You might be able to work around this by using a nonshared |
1284 |
|
libXt.a library. The real fix is to upgrade the various versions of |
1285 |
|
unexec and/or ralloc. We think this has been fixed on Sunos 4 |
1286 |
|
and Solaris in version 19.29. |
1287 |
|
|
1288 |
* You request inverse video, and the first Emacs frame is in inverse |
*** Emacs running under X Windows does not handle mouse clicks. |
1289 |
video, but later frames are not in inverse video. |
*** `emacs -geometry 80x20' finds a file named `80x20'. |
1290 |
|
|
1291 |
This can happen if you have an old version of the custom library in |
One cause of such problems is having (setq term-file-prefix nil) in |
1292 |
your search path for Lisp packages. Use M-x list-load-path-shadows to |
your .emacs file. Another cause is a bad value of EMACSLOADPATH in |
1293 |
check whether this is true. If it is, delete the old custom library. |
the environment. |
1294 |
|
|
1295 |
* In FreeBSD 2.1.5, useless symbolic links remain in /tmp or other |
*** Emacs fails to get default settings from X Windows server. |
|
directories that have the +t bit. |
|
1296 |
|
|
1297 |
This is because of a kernel bug in FreeBSD 2.1.5 (fixed in 2.2). |
The X library in X11R4 has a bug; it interchanges the 2nd and 3rd |
1298 |
Emacs uses symbolic links to implement file locks. In a directory |
arguments to XGetDefaults. Define the macro XBACKWARDS in config.h to |
1299 |
with +t bit, the directory owner becomes the owner of the symbolic |
tell Emacs to compensate for this. |
|
link, so that it cannot be removed by anyone else. |
|
1300 |
|
|
1301 |
If you don't like those useless links, you can let Emacs not to using |
I don't believe there is any way Emacs can determine for itself |
1302 |
file lock by adding #undef CLASH_DETECTION to config.h. |
whether this problem is present on a given system. |
1303 |
|
|
1304 |
* When using M-x dbx with the SparcWorks debugger, the `up' and `down' |
*** X Windows doesn't work if DISPLAY uses a hostname. |
|
commands do not move the arrow in Emacs. |
|
1305 |
|
|
1306 |
You can fix this by adding the following line to `~/.dbxinit': |
People have reported kernel bugs in certain systems that cause Emacs |
1307 |
|
not to work with X Windows if DISPLAY is set using a host name. But |
1308 |
|
the problem does not occur if DISPLAY is set to `unix:0.0'. I think |
1309 |
|
the bug has to do with SIGIO or FIONREAD. |
1310 |
|
|
1311 |
dbxenv output_short_file_name off |
You may be able to compensate for the bug by doing (set-input-mode nil nil). |
1312 |
|
However, that has the disadvantage of turning off interrupts, so that |
1313 |
|
you are unable to quit out of a Lisp program by typing C-g. |
1314 |
|
|
1315 |
* Emacs says it has saved a file, but the file does not actually |
The easy way to do this is to put |
|
appear on disk. |
|
1316 |
|
|
1317 |
This can happen on certain systems when you are using NFS, if the |
(setq x-sigio-bug t) |
|
remote disk is full. It is due to a bug in NFS (or certain NFS |
|
|
implementations), and there is apparently nothing Emacs can do to |
|
|
detect the problem. Emacs checks the failure codes of all the system |
|
|
calls involved in writing a file, including `close'; but in the case |
|
|
where the problem occurs, none of those system calls fails. |
|
1318 |
|
|
1319 |
* "Compose Character" key does strange things when used as a Meta key. |
in your site-init.el file. |
1320 |
|
|
1321 |
If you define one key to serve as both Meta and Compose Character, you |
* Runtime problems on character termunals |
|
will get strange results. In previous Emacs versions, this "worked" |
|
|
in that the key acted as Meta--that's because the older Emacs versions |
|
|
did not try to support Compose Character. Now Emacs tries to do |
|
|
character composition in the standard X way. This means that you |
|
|
must pick one meaning or the other for any given key. |
|
1322 |
|
|
1323 |
You can use both functions (Meta, and Compose Character) if you assign |
** Emacs spontaneously displays "I-search: " at the bottom of the screen. |
|
them to two different keys. |
|
1324 |
|
|
1325 |
* Emacs gets a segmentation fault at startup, on AIX4.2. |
This means that Control-S/Control-Q (XON/XOFF) "flow control" is being |
1326 |
|
used. C-s/C-q flow control is bad for Emacs editors because it takes |
1327 |
|
away C-s and C-q as user commands. Since editors do not output long |
1328 |
|
streams of text without user commands, there is no need for a |
1329 |
|
user-issuable "stop output" command in an editor; therefore, a |
1330 |
|
properly designed flow control mechanism would transmit all possible |
1331 |
|
input characters without interference. Designing such a mechanism is |
1332 |
|
easy, for a person with at least half a brain. |
1333 |
|
|
1334 |
If you are using IBM's xlc compiler, compile emacs.c |
There are three possible reasons why flow control could be taking place: |
|
without optimization; that should avoid the problem. |
|
1335 |
|
|
1336 |
* movemail compiled with POP support can't connect to the POP server. |
1) Terminal has not been told to disable flow control |
1337 |
|
2) Insufficient padding for the terminal in use |
1338 |
|
3) Some sort of terminal concentrator or line switch is responsible |
1339 |
|
|
1340 |
Make sure that the `pop' entry in /etc/services, or in the services |
First of all, many terminals have a set-up mode which controls whether |
1341 |
NIS map if your machine uses NIS, has the same port number as the |
they generate XON/XOFF flow control characters. This must be set to |
1342 |
entry on the POP server. A common error is for the POP server to be |
"no XON/XOFF" in order for Emacs to work. Sometimes there is an |
1343 |
listening on port 110, the assigned port for the POP3 protocol, while |
escape sequence that the computer can send to turn flow control off |
1344 |
the client is trying to connect on port 109, the assigned port for the |
and on. If so, perhaps the termcap `ti' string should turn flow |
1345 |
old POP protocol. |
control off, and the `te' string should turn it on. |
1346 |
|
|
1347 |
* Emacs crashes in x-popup-dialog. |
Once the terminal has been told "no flow control", you may find it |
1348 |
|
needs more padding. The amount of padding Emacs sends is controlled |
1349 |
|
by the termcap entry for the terminal in use, and by the output baud |
1350 |
|
rate as known by the kernel. The shell command `stty' will print |
1351 |
|
your output baud rate; `stty' with suitable arguments will set it if |
1352 |
|
it is wrong. Setting to a higher speed causes increased padding. If |
1353 |
|
the results are wrong for the correct speed, there is probably a |
1354 |
|
problem in the termcap entry. You must speak to a local Unix wizard |
1355 |
|
to fix this. Perhaps you are just using the wrong terminal type. |
1356 |
|
|
1357 |
This can happen if the dialog widget cannot find the font it wants to |
For terminals that lack a "no flow control" mode, sometimes just |
1358 |
use. You can work around the problem by specifying another font with |
giving lots of padding will prevent actual generation of flow control |
1359 |
an X resource--for example, `Emacs.dialog*.font: 9x15' (or any font that |
codes. You might as well try it. |
|
happens to exist on your X server). |
|
1360 |
|
|
1361 |
* Emacs crashes when you use Bibtex mode. |
If you are really unlucky, your terminal is connected to the computer |
1362 |
|
through a concentrator which sends XON/XOFF flow control to the |
1363 |
|
computer, or it insists on sending flow control itself no matter how |
1364 |
|
much padding you give it. Unless you can figure out how to turn flow |
1365 |
|
control off on this concentrator (again, refer to your local wizard), |
1366 |
|
you are screwed! You should have the terminal or concentrator |
1367 |
|
replaced with a properly designed one. In the mean time, some drastic |
1368 |
|
measures can make Emacs semi-work. |
1369 |
|
|
1370 |
This happens if your system puts a small limit on stack size. You can |
You can make Emacs ignore C-s and C-q and let the operating system |
1371 |
prevent the problem by using a suitable shell command (often `ulimit') |
handle them. To do this on a per-session basis, just type M-x |
1372 |
to raise the stack size limit before you run Emacs. |
enable-flow-control RET. You will see a message that C-\ and C-^ are |
1373 |
|
now translated to C-s and C-q. (Use the same command M-x |
1374 |
|
enable-flow-control to turn *off* this special mode. It toggles flow |
1375 |
|
control handling.) |
1376 |
|
|
1377 |
Patches to raise the stack size limit automatically in `main' |
If C-\ and C-^ are inconvenient for you (for example, if one of them |
1378 |
(src/emacs.c) on various systems would be greatly appreciated. |
is the escape character of your terminal concentrator), you can choose |
1379 |
|
other characters by setting the variables flow-control-c-s-replacement |
1380 |
|
and flow-control-c-q-replacement. But choose carefully, since all |
1381 |
|
other control characters are already used by emacs. |
1382 |
|
|
1383 |
* Emacs crashes with SIGBUS or SIGSEGV on HPUX 9 after you delete a frame. |
IMPORTANT: if you type C-s by accident while flow control is enabled, |
1384 |
|
Emacs output will freeze, and you will have to remember to type C-q in |
1385 |
|
order to continue. |
1386 |
|
|
1387 |
We think this is due to a bug in the X libraries provided by HP. With |
If you work in an environment where a majority of terminals of a |
1388 |
the alternative X libraries in /usr/contrib/mitX11R5/lib, the problem |
certain type are flow control hobbled, you can use the function |
1389 |
does not happen. |
`enable-flow-control-on' to turn on this flow control avoidance scheme |
1390 |
|
automatically. Here is an example: |
1391 |
|
|
1392 |
* Emacs crashes with SIGBUS or SIGSEGV on Solaris after you delete a frame. |
(enable-flow-control-on "vt200" "vt300" "vt101" "vt131") |
1393 |
|
|
1394 |
We suspect that this is a similar bug in the X libraries provided by |
If this isn't quite correct (e.g. you have a mixture of flow-control hobbled |
1395 |
Sun. There is a report that one of these patches fixes the bug and |
and good vt200 terminals), you can still run enable-flow-control |
1396 |
makes the problem stop: |
manually. |
1397 |
|
|
1398 |
105216-01 105393-01 105518-01 105621-01 105665-01 105615-02 105216-02 |
I have no intention of ever redesigning the Emacs command set for the |
1399 |
105667-01 105401-08 105615-03 105621-02 105686-02 105736-01 105755-03 |
assumption that terminals use C-s/C-q flow control. XON/XOFF flow |
1400 |
106033-01 105379-01 105786-01 105181-04 105379-03 105786-04 105845-01 |
control technique is a bad design, and terminals that need it are bad |
1401 |
105284-05 105669-02 105837-01 105837-02 105558-01 106125-02 105407-01 |
merchandise and should not be purchased. Now that X is becoming |
1402 |
|
widespread, XON/XOFF seems to be on the way out. If you can get some |
1403 |
|
use out of GNU Emacs on inferior terminals, more power to you, but I |
1404 |
|
will not make Emacs worse for properly designed systems for the sake |
1405 |
|
of inferior systems. |
1406 |
|
|
1407 |
Another person using a newer system (kernel patch level Generic_105181-06) |
** Control-S and Control-Q commands are ignored completely. |
|
suspects that the bug was fixed by one of these more recent patches: |
|
1408 |
|
|
1409 |
106040-07 SunOS 5.6: X Input & Output Method patch |
For some reason, your system is using brain-damaged C-s/C-q flow |
1410 |
106222-01 OpenWindows 3.6: filemgr (ff.core) fixes |
control despite Emacs's attempts to turn it off. Perhaps your |
1411 |
105284-12 Motif 1.2.7: sparc Runtime library patch |
terminal is connected to the computer through a concentrator |
1412 |
|
that wants to use flow control. |
1413 |
|
|
1414 |
* Problems running Perl under Emacs on MS-Windows NT/95. |
You should first try to tell the concentrator not to use flow control. |
1415 |
|
If you succeed in this, try making the terminal work without |
1416 |
|
flow control, as described in the preceding section. |
1417 |
|
|
1418 |
`perl -de 0' just hangs when executed in an Emacs subshell. |
If that line of approach is not successful, map some other characters |
1419 |
The fault lies with Perl (indirectly with Windows NT/95). |
into C-s and C-q using keyboard-translate-table. The example above |
1420 |
|
shows how to do this with C-^ and C-\. |
1421 |
|
|
1422 |
The problem is that the Perl debugger explicitly opens a connection to |
** Screen is updated wrong, but only on one kind of terminal. |
|
"CON", which is the DOS/NT equivalent of "/dev/tty", for interacting |
|
|
with the user. |
|
1423 |
|
|
1424 |
On Unix, this is okay, because Emacs (or the shell?) creates a |
This could mean that the termcap entry you are using for that |
1425 |
pseudo-tty so that /dev/tty is really the pipe Emacs is using to |
terminal is wrong, or it could mean that Emacs has a bug handing |
1426 |
communicate with the subprocess. |
the combination of features specified for that terminal. |
1427 |
|
|
1428 |
On NT, this fails because CON always refers to the handle for the |
The first step in tracking this down is to record what characters |
1429 |
relevant console (approximately equivalent to a tty), and cannot be |
Emacs is sending to the terminal. Execute the Lisp expression |
1430 |
redirected to refer to the pipe Emacs assigned to the subprocess as |
(open-termscript "./emacs-script") to make Emacs write all |
1431 |
stdin. |
terminal output into the file ~/emacs-script as well; then do |
1432 |
|
what makes the screen update wrong, and look at the file |
1433 |
|
and decode the characters using the manual for the terminal. |
1434 |
|
There are several possibilities: |
1435 |
|
|
1436 |
A workaround is to modify perldb.pl to use STDIN/STDOUT instead of CON. |
1) The characters sent are correct, according to the terminal manual. |
1437 |
|
|
1438 |
For Perl 4: |
In this case, there is no obvious bug in Emacs, and most likely you |
1439 |
|
need more padding, or possibly the terminal manual is wrong. |
1440 |
|
|
1441 |
*** PERL/LIB/PERLDB.PL.orig Wed May 26 08:24:18 1993 |
2) The characters sent are incorrect, due to an obscure aspect |
1442 |
--- PERL/LIB/PERLDB.PL Mon Jul 01 15:28:16 1996 |
of the terminal behavior not described in an obvious way |
1443 |
*************** |
by termcap. |
|
*** 68,74 **** |
|
|
$rcfile=".perldb"; |
|
|
} |
|
|
else { |
|
|
! $console = "con"; |
|
|
$rcfile="perldb.ini"; |
|
|
} |
|
1444 |
|
|
1445 |
--- 68,74 ---- |
This case is hard. It will be necessary to think of a way for |
1446 |
$rcfile=".perldb"; |
Emacs to distinguish between terminals with this kind of behavior |
1447 |
} |
and other terminals that behave subtly differently but are |
1448 |
else { |
classified the same by termcap; or else find an algorithm for |
1449 |
! $console = ""; |
Emacs to use that avoids the difference. Such changes must be |
1450 |
$rcfile="perldb.ini"; |
tested on many kinds of terminals. |
|
} |
|
1451 |
|
|
1452 |
|
3) The termcap entry is wrong. |
1453 |
|
|
1454 |
For Perl 5: |
See the file etc/TERMS for information on changes |
1455 |
*** perl/5.001/lib/perl5db.pl.orig Sun Jun 04 21:13:40 1995 |
that are known to be needed in commonly used termcap entries |
1456 |
--- perl/5.001/lib/perl5db.pl Mon Jul 01 17:00:08 1996 |
for certain terminals. |
|
*************** |
|
|
*** 22,28 **** |
|
|
$rcfile=".perldb"; |
|
|
} |
|
|
elsif (-e "con") { |
|
|
! $console = "con"; |
|
|
$rcfile="perldb.ini"; |
|
|
} |
|
|
else { |
|
|
--- 22,28 ---- |
|
|
$rcfile=".perldb"; |
|
|
} |
|
|
elsif (-e "con") { |
|
|
! $console = ""; |
|
|
$rcfile="perldb.ini"; |
|
|
} |
|
|
else { |
|
1457 |
|
|
1458 |
* Problems on MS-DOG if DJGPP v2.0 is used to compile Emacs: |
4) The characters sent are incorrect, and clearly cannot be |
1459 |
|
right for any terminal with the termcap entry you were using. |
1460 |
|
|
1461 |
There are two DJGPP library bugs which cause problems: |
This is unambiguously an Emacs bug, and can probably be fixed |
1462 |
|
in termcap.c, tparam.c, term.c, scroll.c, cm.c or dispnew.c. |
1463 |
|
|
1464 |
* Running `shell-command' (or `compile', or `grep') you get |
** Control-S and Control-Q commands are ignored completely on a net connection. |
|
`Searching for program: permission denied (EACCES), c:/command.com'; |
|
|
* After you shell to DOS, Ctrl-Break kills Emacs. |
|
1465 |
|
|
1466 |
To work around these bugs, you can use two files in the msdos |
Some versions of rlogin (and possibly telnet) do not pass flow |
1467 |
subdirectory: `is_exec.c' and `sigaction.c'. Compile them and link |
control characters to the remote system to which they connect. |
1468 |
them into the Emacs executable `temacs'; then they will replace the |
On such systems, emacs on the remote system cannot disable flow |
1469 |
incorrect library functions. |
control on the local system. |
1470 |
|
|
1471 |
* When compiling with DJGPP on MS-Windows NT, "config msdos" fails. |
One way to cure this is to disable flow control on the local host |
1472 |
|
(the one running rlogin, not the one running rlogind) using the |
1473 |
|
stty command, before starting the rlogin process. On many systems, |
1474 |
|
"stty start u stop u" will do this. |
1475 |
|
|
1476 |
If the error message is "VDM has been already loaded", this is because |
Some versions of tcsh will prevent even this from working. One way |
1477 |
Windows has a program called `redir.exe' that is incompatible with a |
around this is to start another shell before starting rlogin, and |
1478 |
program by the same name supplied with DJGPP, which is used by |
issue the stty command to disable flow control from that shell. |
|
config.bat. To resolve this, move the DJGPP's `bin' subdirectory to |
|
|
the front of your PATH environment variable. |
|
1479 |
|
|
1480 |
* When compiling with DJGPP on MS-Windows 95, Make fails for some targets |
If none of these methods work, the best solution is to type |
1481 |
like make-docfile. |
M-x enable-flow-control at the beginning of your emacs session, or |
1482 |
|
if you expect the problem to continue, add a line such as the |
1483 |
|
following to your .emacs (on the host running rlogind): |
1484 |
|
|
1485 |
This can happen if long file name support (the setting of environment |
(enable-flow-control-on "vt200" "vt300" "vt101" "vt131") |
|
variable LFN) when Emacs distribution was unpacked and during |
|
|
compilation are not the same. See the MSDOG section of INSTALL for |
|
|
the explanation of how to avoid this problem. |
|
1486 |
|
|
1487 |
* Emacs compiled for MSDOS cannot find some Lisp files, or other |
See the entry about spontaneous display of I-search (above) for more |
1488 |
run-time support files, when long filename support is enabled. |
info. |
1489 |
|
|
1490 |
Usually, this problem will manifest itself when Emacs exits |
** Output from Control-V is slow. |
|
immediately after flashing the startup screen, because it cannot find |
|
|
the Lisp files it needs to load at startup. Redirect Emacs stdout |
|
|
and stderr to a file to see the error message printed by Emacs. |
|
1491 |
|
|
1492 |
Another manifestation of this problem is that Emacs is unable to load |
On many bit-map terminals, scrolling operations are fairly slow. |
1493 |
the support for editing program sources in languages such as C and |
Often the termcap entry for the type of terminal in use fails |
1494 |
Lisp. |
to inform Emacs of this. The two lines at the bottom of the screen |
1495 |
|
before a Control-V command are supposed to appear at the top after |
1496 |
|
the Control-V command. If Emacs thinks scrolling the lines is fast, |
1497 |
|
it will scroll them to the top of the screen. |
1498 |
|
|
1499 |
This can happen if the Emacs distribution was unzipped without LFN |
If scrolling is slow but Emacs thinks it is fast, the usual reason is |
1500 |
support, thus causing long filenames to be truncated to the first 6 |
that the termcap entry for the terminal you are using does not |
1501 |
characters and a numeric tail that Windows 95 normally attaches to it. |
specify any padding time for the `al' and `dl' strings. Emacs |
1502 |
You should unzip the files again with a utility that supports long |
concludes that these operations take only as much time as it takes to |
1503 |
filenames (such as djtar from DJGPP or InfoZip's UnZip program |
send the commands at whatever line speed you are using. You must |
1504 |
compiled with DJGPP v2). The MSDOG section of the file INSTALL |
fix the termcap entry to specify, for the `al' and `dl', as much |
1505 |
explains this issue in more detail. |
time as the operations really take. |
1506 |
|
|
1507 |
Another possible reason for such failures is that Emacs compiled for |
Currently Emacs thinks in terms of serial lines which send characters |
1508 |
MSDOS is used on Windows NT, where long file names are not supported |
at a fixed rate, so that any operation which takes time for the |
1509 |
by this version of Emacs, but the distribution was unpacked by an |
terminal to execute must also be padded. With bit-map terminals |
1510 |
unzip program that preserved the long file names instead of truncating |
operated across networks, often the network provides some sort of |
1511 |
them to DOS 8+3 limits. To be useful on NT, the MSDOS port of Emacs |
flow control so that padding is never needed no matter how slow |
1512 |
must be unzipped by a DOS utility, so that long file names are |
an operation is. You must still specify a padding time if you want |
1513 |
properly truncated. |
Emacs to realize that the operation takes a long time. This will |
1514 |
|
cause padding characters to be sent unnecessarily, but they do |
1515 |
|
not really cost much. They will be transmitted while the scrolling |
1516 |
|
is happening and then discarded quickly by the terminal. |
1517 |
|
|
1518 |
* Emacs compiled with DJGPP complains at startup: |
Most bit-map terminals provide commands for inserting or deleting |
1519 |
|
multiple lines at once. Define the `AL' and `DL' strings in the |
1520 |
|
termcap entry to say how to do these things, and you will have |
1521 |
|
fast output without wasted padding characters. These strings should |
1522 |
|
each contain a single %-spec saying how to send the number of lines |
1523 |
|
to be scrolled. These %-specs are like those in the termcap |
1524 |
|
`cm' string. |
1525 |
|
|
1526 |
"Wrong type of argument: internal-facep, msdos-menu-active-face" |
You should also define the `IC' and `DC' strings if your terminal |
1527 |
|
has a command to insert or delete multiple characters. These |
1528 |
|
take the number of positions to insert or delete as an argument. |
1529 |
|
|
1530 |
This can happen if you define an environment variable `TERM'. Emacs |
A `cs' string to set the scrolling region will reduce the amount |
1531 |
on MSDOS uses an internal terminal emulator which is disabled if the |
of motion you see on the screen when part of the screen is scrolled. |
|
value of `TERM' is anything but the string "internal". Emacs then |
|
|
works as if its terminal were a dumb glass teletype that doesn't |
|
|
support faces. To work around this, arrange for `TERM' to be |
|
|
undefined when Emacs runs. The best way to do that is to add an |
|
|
[emacs] section to the DJGPP.ENV file which defines an empty value for |
|
|
`TERM'; this way, only Emacs gets the empty value, while the rest of |
|
|
your system works as before. |
|
1532 |
|
|
1533 |
* On MS-Windows 95, Alt-f6 does not get through to Emacs. |
** You type Control-H (Backspace) expecting to delete characters. |
1534 |
|
|
1535 |
This character seems to be trapped by the kernel in Windows 95. |
Put `stty dec' in your .login file and your problems will disappear |
1536 |
You can enter M-f6 by typing ESC f6. |
after a day or two. |
1537 |
|
|
1538 |
* Typing Alt-Shift has strange effects on MS-Windows. |
The choice of Backspace for erasure was based on confusion, caused by |
1539 |
|
the fact that backspacing causes erasure (later, when you type another |
1540 |
|
character) on most display terminals. But it is a mistake. Deletion |
1541 |
|
of text is not the same thing as backspacing followed by failure to |
1542 |
|
overprint. I do not wish to propagate this confusion by conforming |
1543 |
|
to it. |
1544 |
|
|
1545 |
This combination of keys is a command to change keyboard layout. If |
For this reason, I believe `stty dec' is the right mode to use, |
1546 |
you proceed to type another non-modifier key before you let go of Alt |
and I have designed Emacs to go with that. If there were a thousand |
1547 |
and Shift, the Alt and Shift act as modifiers in the usual way. A |
other control characters, I would define Control-h to delete as well; |
1548 |
more permanent work around is to change it to another key combination, |
but there are not very many other control characters, and I think |
1549 |
or disable it in the keyboard control panel. |
that providing the most mnemonic possible Help character is more |
1550 |
|
important than adapting to people who don't use `stty dec'. |
1551 |
|
|
1552 |
* `tparam' reported as a multiply-defined symbol when linking with ncurses. |
If you are obstinate about confusing buggy overprinting with deletion, |
1553 |
|
you can redefine Backspace in your .emacs file: |
1554 |
|
(global-set-key "\b" 'delete-backward-char) |
1555 |
|
You can probably access help-command via f1. |
1556 |
|
|
1557 |
This problem results from an incompatible change in ncurses, in |
** Colors are not available on a tty or in xterm. |
|
version 1.9.9e approximately. This version is unable to provide a |
|
|
definition of tparm without also defining tparam. This is also |
|
|
incompatible with Terminfo; as a result, the Emacs Terminfo support |
|
|
does not work with this version of ncurses. |
|
1558 |
|
|
1559 |
The fix is to install a newer version of ncurses, such as version 4.2. |
Emacs 21 supports colors on character terminals and terminal |
1560 |
|
emulators, but this support relies on the terminfo or termcap database |
1561 |
|
entry to specify that the display supports color. Emacs looks at the |
1562 |
|
"Co" capability for the terminal to find out how many colors are |
1563 |
|
supported; it should be non-zero to activate the color support within |
1564 |
|
Emacs. (Most color terminals support 8 or 16 colors.) If your system |
1565 |
|
uses terminfo, the name of the capability equivalent to "Co" is |
1566 |
|
"colors". |
1567 |
|
|
1568 |
* Emacs does not start, complaining that it cannot open termcap database file. |
In addition to the "Co" capability, Emacs needs the "op" (for |
1569 |
|
``original pair'') capability, which tells how to switch the terminal |
1570 |
|
back to the default foreground and background colors. Emacs will not |
1571 |
|
use colors if this capability is not defined. If your terminal entry |
1572 |
|
doesn't provide such a capability, try using the ANSI standard escape |
1573 |
|
sequence \E[00m (that is, define a new termcap/terminfo entry and make |
1574 |
|
it use your current terminal's entry plus \E[00m for the "op" |
1575 |
|
capability). |
1576 |
|
|
1577 |
If your system uses Terminfo rather than termcap (most modern |
Finally, the "NC" capability (terminfo name: "ncv") tells Emacs which |
1578 |
systems do), this could happen if the proper version of |
attributes cannot be used with colors. Setting this capability |
1579 |
ncurses is not visible to the Emacs configure script (i.e. it |
incorrectly might have the effect of disabling colors; try setting |
1580 |
cannot be found along the usual path the linker looks for |
this capability to `0' (zero) and see if that helps. |
|
libraries). It can happen because your version of ncurses is |
|
|
obsolete, or is available only in form of binaries. |
|
1581 |
|
|
1582 |
The solution is to install an up-to-date version of ncurses in |
Emacs uses the database entry for the terminal whose name is the value |
1583 |
the developer's form (header files, static libraries and |
of the environment variable TERM. With `xterm', a common terminal |
1584 |
symbolic links); in some GNU/Linux distributions (e.g. Debian) |
entry that supports color is `xterm-color', so setting TERM's value to |
1585 |
it constitutes a separate package. |
`xterm-color' might activate the color support on an xterm-compatible |
1586 |
|
emulator. |
1587 |
|
|
1588 |
* Strange results from format %d in a few cases, on a Sun. |
Beginning with version 21.4, Emacs supports the --color command-line |
1589 |
|
option which may be used to force Emacs to use one of a few popular |
1590 |
|
modes for getting colors on a tty. For example, --color=ansi8 sets up |
1591 |
|
for using the ANSI-standard escape sequences that support 8 colors. |
1592 |
|
|
1593 |
Sun compiler version SC3.0 has been found to miscompile part of |
Some modes do not use colors unless you turn on the Font-lock mode. |
1594 |
editfns.c. The workaround is to compile with some other compiler such |
Some people have long ago set their `~/.emacs' files to turn on |
1595 |
as GCC. |
Font-lock on X only, so they won't see colors on a tty. The |
1596 |
|
recommended way of turning on Font-lock is by typing "M-x |
1597 |
|
global-font-lock-mode RET" or by customizing the variable |
1598 |
|
`global-font-lock-mode'. |
1599 |
|
|
1600 |
* Output from subprocess (such as man or diff) is randomly truncated |
* Runtime problems specific to individual Unix variants |
|
on GNU/Linux systems. |
|
1601 |
|
|
1602 |
This is due to a kernel bug which seems to be fixed in Linux version |
** GNU/Linux |
|
1.3.75. |
|
1603 |
|
|
1604 |
* Error messages `internal facep []' happen on GNU/Linux systems. |
*** GNU/Linux: On Linux-based GNU systems using libc versions 5.4.19 through |
1605 |
|
5.4.22, Emacs crashes at startup with a segmentation fault. |
1606 |
|
|
1607 |
There is a report that replacing libc.so.5.0.9 with libc.so.5.2.16 |
This problem happens if libc defines the symbol __malloc_initialized. |
1608 |
caused this to start happening. People are not sure why, but the |
One known solution is to upgrade to a newer libc version. 5.4.33 is |
1609 |
problem seems unlikely to be in Emacs itself. Some suspect that it |
known to work. |
|
is actually Xlib which won't work with libc.so.5.2.16. |
|
1610 |
|
|
1611 |
Using the old library version is a workaround. |
*** GNU/Linux: After upgrading to a newer version of Emacs, |
1612 |
|
the Meta key stops working. |
1613 |
|
|
1614 |
* On Solaris, Emacs crashes if you use (display-time). |
This was reported to happen on a GNU/Linux system distributed by |
1615 |
|
Mandrake. The reason is that the previous version of Emacs was |
1616 |
|
modified by Mandrake to make the Alt key act as the Meta key, on a |
1617 |
|
keyboard where the Windows key is the one which produces the Meta |
1618 |
|
modifier. A user who started using a newer version of Emacs, which |
1619 |
|
was not hacked by Mandrake, expected the Alt key to continue to act as |
1620 |
|
Meta, and was astonished when that didn't happen. |
1621 |
|
|
1622 |
This can happen if you configure Emacs without specifying the precise |
The solution is to find out what key on your keyboard produces the Meta |
1623 |
version of Solaris that you are using. |
modifier, and use that key instead. Try all of the keys to the left |
1624 |
|
and to the right of the space bar, together with the `x' key, and see |
1625 |
|
which combination produces "M-x" in the echo area. You can also use |
1626 |
|
the `xmodmap' utility to show all the keys which produce a Meta |
1627 |
|
modifier: |
1628 |
|
|
1629 |
* Emacs dumps core on startup, on Solaris. |
xmodmap -pk | egrep -i "meta|alt" |
1630 |
|
|
1631 |
Bill Sebok says that the cause of this is Solaris 2.4 vendor patch |
A more convenient way of finding out which keys produce a Meta modifier |
1632 |
102303-05, which extends the Solaris linker to deal with the Solaris |
is to use the `xkbprint' utility, if it's available on your system: |
|
Common Desktop Environment's linking needs. You can fix the problem |
|
|
by removing this patch and installing patch 102049-02 instead. |
|
|
However, that linker version won't work with CDE. |
|
1633 |
|
|
1634 |
Solaris 2.5 comes with a linker that has this bug. It is reported that if |
xkbprint 0:0 /tmp/k.ps |
|
you install all the latest patches (as of June 1996), the bug is fixed. |
|
|
We suspect the crucial patch is one of these, but we don't know |
|
|
for certain. |
|
1635 |
|
|
1636 |
103093-03: [README] SunOS 5.5: kernel patch (2140557 bytes) |
This produces a PostScript file `/tmp/k.ps' with a picture of your |
1637 |
102832-01: [README] OpenWindows 3.5: Xview Jumbo Patch (4181613 bytes) |
keyboard; printing that file on a PostScript printer will show what |
1638 |
103242-04: [README] SunOS 5.5: linker patch (595363 bytes) |
keys can serve as Meta. |
1639 |
|
|
1640 |
(One user reports that the bug was fixed by those patches together |
The `xkeycaps' also shows a visual representation of the current |
1641 |
with patches 102980-04, 103279-01, 103300-02, and 103468-01.) |
keyboard settings. It also allows to modify them. |
1642 |
|
|
1643 |
If you can determine which patch does fix the bug, please tell |
*** GNU/Linux: low startup on Linux-based GNU systems. |
|
bug-gnu-emacs@gnu.org. |
|
1644 |
|
|
1645 |
Meanwhile, the GNU linker links Emacs properly on both Solaris 2.4 and |
People using systems based on the Linux kernel sometimes report that |
1646 |
Solaris 2.5. |
startup takes 10 to 15 seconds longer than `usual'. |
1647 |
|
|
1648 |
* Emacs dumps core if lisp-complete-symbol is called, on Solaris. |
This is because Emacs looks up the host name when it starts. |
1649 |
|
Normally, this takes negligible time; the extra delay is due to |
1650 |
|
improper system configuration. This problem can occur for both |
1651 |
|
networked and non-networked machines. |
1652 |
|
|
1653 |
If you compile Emacs with the -fast or -xO4 option with version 3.0.2 |
Here is how to fix the configuration. It requires being root. |
|
of the Sun C compiler, Emacs dumps core when lisp-complete-symbol is |
|
|
called. The problem does not happen if you compile with GCC. |
|
1654 |
|
|
1655 |
* "Cannot find callback list" messages from dialog boxes on HPUX, in |
**** Networked Case. |
|
Emacs built with Motif. |
|
1656 |
|
|
1657 |
This problem resulted from a bug in GCC 2.4.5. Newer GCC versions |
First, make sure the files `/etc/hosts' and `/etc/host.conf' both |
1658 |
such as 2.7.0 fix the problem. |
exist. The first line in the `/etc/hosts' file should look like this |
1659 |
|
(replace HOSTNAME with your host name): |
1660 |
|
|
1661 |
* On Irix 6.0, make tries (and fails) to build a program named unexelfsgi |
127.0.0.1 HOSTNAME |
1662 |
|
|
1663 |
A compiler bug inserts spaces into the string "unexelfsgi . o" |
Also make sure that the `/etc/host.conf' files contains the following |
1664 |
in src/Makefile. Edit src/Makefile, after configure is run, |
lines: |
|
find that string, and take out the spaces. |
|
1665 |
|
|
1666 |
Compiler fixes in Irix 6.0.1 should eliminate this problem. |
order hosts, bind |
1667 |
|
multi on |
1668 |
|
|
1669 |
* "out of virtual swap space" on Irix 5.3 |
Any changes, permanent and temporary, to the host name should be |
1670 |
|
indicated in the `/etc/hosts' file, since it acts a limited local |
1671 |
|
database of addresses and names (e.g., some SLIP connections |
1672 |
|
dynamically allocate ip addresses). |
1673 |
|
|
1674 |
This message occurs when the system runs out of swap space due to too |
**** Non-Networked Case. |
|
many large programs running. The solution is either to provide more |
|
|
swap space or to reduce the number of large programs being run. You |
|
|
can check the current status of the swap space by executing the |
|
|
command `swap -l'. |
|
1675 |
|
|
1676 |
You can increase swap space by changing the file /etc/fstab. Adding a |
The solution described in the networked case applies here as well. |
1677 |
line like this: |
However, if you never intend to network your machine, you can use a |
1678 |
|
simpler solution: create an empty `/etc/host.conf' file. The command |
1679 |
|
`touch /etc/host.conf' suffices to create the file. The `/etc/hosts' |
1680 |
|
file is not necessary with this approach. |
1681 |
|
|
1682 |
/usr/swap/swap.more swap swap pri=3 0 0 |
*** GNU/Linux: Emacs on a tty switches the cursor to large blinking block. |
1683 |
|
|
1684 |
where /usr/swap/swap.more is a file previously created (for instance |
This was reported to happen on some GNU/Linux systems which use |
1685 |
by using /etc/mkfile), will increase the swap space by the size of |
ncurses version 5.0, but could be relevant for other versions as well. |
1686 |
that file. Execute `swap -m' or reboot the machine to activate the |
These versions of ncurses come with a `linux' terminfo entry, where |
1687 |
new swap area. See the manpages for `swap' and `fstab' for further |
the "cvvis" capability (termcap "vs") is defined as "\E[?25h\E[?8c" |
1688 |
information. |
(show cursor, change size). This escape sequence switches on a |
1689 |
|
blinking hardware text-mode cursor whose size is a full character |
1690 |
|
cell. This blinking cannot be stopped, since a hardware cursor |
1691 |
|
always blinks. |
1692 |
|
|
1693 |
The objectserver daemon can use up lots of memory because it can be |
A work-around is to redefine the "cvvis" capability so that it |
1694 |
swamped with NIS information. It collects information about all users |
enables a *software* cursor. The software cursor works by inverting |
1695 |
on the network that can log on to the host. |
the colors of the character at point, so what you see is a block |
1696 |
|
cursor that doesn't blink. For this to work, you need to redefine |
1697 |
|
the "cnorm" capability as well, so that it operates on the software |
1698 |
|
cursor instead of the hardware cursor. |
1699 |
|
|
1700 |
If you want to disable the objectserver completely, you can execute |
To this end, run "infocmp linux > linux-term", edit the file |
1701 |
the command `chkconfig objectserver off' and reboot. That may disable |
`linux-term' to make both the "cnorm" and "cvvis" capabilities send |
1702 |
some of the window system functionality, such as responding CDROM |
the sequence "\E[?25h\E[?17;0;64c", and then run "tic linux-term" to |
1703 |
icons. |
produce a modified terminfo entry. |
1704 |
|
|
1705 |
You can also remove NIS support from the objectserver. The SGI `admin' |
Alternatively, if you want a blinking underscore as your Emacs cursor, |
1706 |
FAQ has a detailed description on how to do that; see question 35 |
change the "cvvis" capability to send the "\E[?25h\E[?0c" command. |
|
("Why isn't the objectserver working?"). The admin FAQ can be found at |
|
|
ftp://viz.tamu.edu/pub/sgi/faq/. |
|
1707 |
|
|
1708 |
* With certain fonts, when the cursor appears on a character, the |
*** GNU/Linux: Error messages `internal facep []' happen on GNU/Linux systems. |
|
character doesn't appear--you get a solid box instead. |
|
1709 |
|
|
1710 |
One user on a Linux-based GNU system reported that this problem went |
There is a report that replacing libc.so.5.0.9 with libc.so.5.2.16 |
1711 |
away with installation of a new X server. The failing server was |
caused this to start happening. People are not sure why, but the |
1712 |
XFree86 3.1.1. XFree86 3.1.2 works. |
problem seems unlikely to be in Emacs itself. Some suspect that it |
1713 |
|
is actually Xlib which won't work with libc.so.5.2.16. |
1714 |
|
|
1715 |
* On SunOS 4.1.3, Emacs unpredictably crashes in _yp_dobind_soft. |
Using the old library version is a workaround. |
1716 |
|
|
1717 |
This happens if you configure Emacs specifying just `sparc-sun-sunos4' |
** Mac OS X |
|
on a system that is version 4.1.3. You must specify the precise |
|
|
version number (or let configure figure out the configuration, which |
|
|
it can do perfectly well for SunOS). |
|
1718 |
|
|
1719 |
* On SunOS 4, Emacs processes keep going after you kill the X server |
*** Mac OS X (Carbon): Environment Variables from dotfiles are ignored. |
|
(or log out, if you logged in using X). |
|
1720 |
|
|
1721 |
Someone reported that recompiling with GCC 2.7.0 fixed this problem. |
When starting Emacs from the Dock or the Finder on Mac OS X, the |
1722 |
|
environment variables that are set up in dotfiles, such as .cshrc or |
1723 |
|
.profile, are ignored. This is because the Finder and Dock are not |
1724 |
|
started from a shell, but instead from the Window Manager itself. |
1725 |
|
|
1726 |
* On AIX 4, some programs fail when run in a Shell buffer |
The workaround for this is to create a .MacOSX/environment.plist file to |
1727 |
with an error message like No terminfo entry for "unknown". |
setup these environment variables. These environment variables will |
1728 |
|
apply to all processes regardless of where they are started. |
1729 |
|
For me information, see http://developer.apple.com/qa/qa2001/qa1067.html. |
1730 |
|
|
1731 |
On AIX, many terminal type definitions are not installed by default. |
*** Mac OS X (Carbon): Process output truncated when using ptys. |
|
`unknown' is one of them. Install the "Special Generic Terminal |
|
|
Definitions" to make them defined. |
|
1732 |
|
|
1733 |
* On SunOS, you get linker errors |
There appears to be a problem with the implementation of pty's on the |
1734 |
ld: Undefined symbol |
Mac OS X that causes process output to be truncated. To avoid this, |
1735 |
_get_wmShellWidgetClass |
leave process-connection-type set to its default value of nil. |
|
_get_applicationShellWidgetClass |
|
1736 |
|
|
1737 |
The fix to this is to install patch 100573 for OpenWindows 3.0 |
** FreeBSD |
|
or link libXmu statically. |
|
1738 |
|
|
1739 |
* On AIX 4.1.2, linker error messages such as |
*** FreeBSD 2.1.5: useless symbolic links remain in /tmp or other |
1740 |
ld: 0711-212 SEVERE ERROR: Symbol .__quous, found in the global symbol table |
directories that have the +t bit. |
|
of archive /usr/lib/libIM.a, was not defined in archive member shr.o. |
|
1741 |
|
|
1742 |
This is a problem in libIM.a. You can work around it by executing |
This is because of a kernel bug in FreeBSD 2.1.5 (fixed in 2.2). |
1743 |
these shell commands in the src subdirectory of the directory where |
Emacs uses symbolic links to implement file locks. In a directory |
1744 |
you build Emacs: |
with +t bit, the directory owner becomes the owner of the symbolic |
1745 |
|
link, so that it cannot be removed by anyone else. |
1746 |
|
|
1747 |
cp /usr/lib/libIM.a . |
If you don't like those useless links, you can let Emacs not to using |
1748 |
chmod 664 libIM.a |
file lock by adding #undef CLASH_DETECTION to config.h. |
|
ranlib libIM.a |
|
1749 |
|
|
1750 |
Then change -lIM to ./libIM.a in the command to link temacs (in |
*** FreeBSD: Getting a Meta key on the console. |
|
Makefile). |
|
1751 |
|
|
1752 |
* Unpredictable segmentation faults on Solaris 2.3 and 2.4. |
By default, neither Alt nor any other key acts as a Meta key on |
1753 |
|
FreeBSD, but this can be changed using kbdcontrol(1). Dump the |
1754 |
|
current keymap to a file with the command |
1755 |
|
|
1756 |
A user reported that this happened in 19.29 when it was compiled with |
$ kbdcontrol -d >emacs.kbd |
|
the Sun compiler, but not when he recompiled with GCC 2.7.0. |
|
1757 |
|
|
1758 |
We do not know whether something in Emacs is partly to blame for this. |
Edit emacs.kbd, and give the key you want to be the Meta key the |
1759 |
|
definition `meta'. For instance, if your keyboard has a ``Windows'' |
1760 |
|
key with scan code 105, change the line for scan code 105 in emacs.kbd |
1761 |
|
to look like this |
1762 |
|
|
1763 |
* Emacs exits with "X protocol error" when run with an X server for |
105 meta meta meta meta meta meta meta meta O |
|
MS-Windows. |
|
1764 |
|
|
1765 |
A certain X server for Windows had a bug which caused this. |
to make the Windows key the Meta key. Load the new keymap with |
|
Supposedly the newer 32-bit version of this server doesn't have the |
|
|
problem. |
|
1766 |
|
|
1767 |
* Emacs crashes at startup on MSDOS. |
$ kbdcontrol -l emacs.kbd |
1768 |
|
|
1769 |
Some users report that Emacs 19.29 requires dpmi memory management, |
** HP-UX |
|
and crashes on startup if the system does not have it. We don't yet |
|
|
know why this happens--perhaps these machines don't have enough real |
|
|
memory, or perhaps something is wrong in Emacs or the compiler. |
|
|
However, arranging to use dpmi support is a workaround. |
|
1770 |
|
|
1771 |
You can find out if you have a dpmi host by running go32 without |
*** HP/UX : Shell mode gives the message, "`tty`: Ambiguous". |
|
arguments; it will tell you if it uses dpmi memory. For more |
|
|
information about dpmi memory, consult the djgpp FAQ. (djgpp |
|
|
is the GNU C compiler as packaged for MSDOS.) |
|
1772 |
|
|
1773 |
Compiling Emacs under MSDOS is extremely sensitive for proper memory |
christos@theory.tn.cornell.edu says: |
|
configuration. If you experience problems during compilation, consider |
|
|
removing some or all memory resident programs (notably disk caches) |
|
|
and make sure that your memory managers are properly configured. See |
|
|
the djgpp faq for configuration hints. |
|
1774 |
|
|
1775 |
* A position you specified in .Xdefaults is ignored, using twm. |
The problem is that in your .cshrc you have something that tries to |
1776 |
|
execute `tty`. If you are not running the shell on a real tty then |
1777 |
|
tty will print "not a tty". Csh expects one word in some places, |
1778 |
|
but tty is giving it back 3. |
1779 |
|
|
1780 |
twm normally ignores "program-specified" positions. |
The solution is to add a pair of quotes around `tty` to make it a single |
1781 |
You can tell it to obey them with this command in your `.twmrc' file: |
word: |
1782 |
|
|
1783 |
UsePPosition "on" #allow clients to request a position |
if (`tty` == "/dev/console") |
1784 |
|
|
1785 |
* Compiling lib-src says there is no rule to make test-distrib.c. |
should be changed to: |
1786 |
|
|
1787 |
This results from a bug in a VERY old version of GNU Sed. To solve |
if ("`tty`" == "/dev/console") |
|
the problem, install the current version of GNU Sed, then rerun |
|
|
Emacs's configure script. |
|
1788 |
|
|
1789 |
* Compiling wakeup, in lib-src, says it can't make wakeup.c. |
Even better, move things that set up terminal sections out of .cshrc |
1790 |
|
and into .login. |
1791 |
|
|
1792 |
This results from a bug in GNU Sed version 2.03. To solve the |
*** HP/UX: `Pid xxx killed due to text modification or page I/O error'. |
|
problem, install the current version of GNU Sed, then rerun Emacs's |
|
|
configure script. |
|
1793 |
|
|
1794 |
* On Sunos 4.1.1, there are errors compiling sysdep.c. |
On HP/UX, you can get that error when the Emacs executable is on an NFS |
1795 |
|
file system. HP/UX responds this way if it tries to swap in a page and |
1796 |
|
does not get a response from the server within a timeout whose default |
1797 |
|
value is just ten seconds. |
1798 |
|
|
1799 |
If you get errors such as |
If this happens to you, extend the timeout period. |
1800 |
|
|
1801 |
"sysdep.c", line 2017: undefined structure or union |
*** HP/UX: Emacs is slow using X11R5. |
|
"sysdep.c", line 2017: undefined structure or union |
|
|
"sysdep.c", line 2019: nodename undefined |
|
1802 |
|
|
1803 |
This can result from defining LD_LIBRARY_PATH. It is very tricky |
This happens if you use the MIT versions of the X libraries--it |
1804 |
to use that environment variable with Emacs. The Emacs configure |
doesn't run as fast as HP's version. People sometimes use the version |
1805 |
script links many test programs with the system libraries; you must |
because they see the HP version doesn't have the libraries libXaw.a, |
1806 |
make sure that the libraries available to configure are the same |
libXmu.a, libXext.a and others. HP/UX normally doesn't come with |
1807 |
ones available when you build Emacs. |
those libraries installed. To get good performance, you need to |
1808 |
|
install them and rebuild Emacs. |
1809 |
|
|
1810 |
* The right Alt key works wrong on German HP keyboards (and perhaps |
*** HP/UX: The right Alt key works wrong on German HP keyboards (and perhaps |
1811 |
other non-English HP keyboards too). |
other non-English HP keyboards too). |
1812 |
|
|
1813 |
This is because HPUX defines the modifiers wrong in X. Here is a |
This is because HP-UX defines the modifiers wrong in X. Here is a |
1814 |
shell script to fix the problem; be sure that it is run after VUE |
shell script to fix the problem; be sure that it is run after VUE |
1815 |
configures the X server. |
configures the X server. |
1816 |
|
|
1827 |
add mod2 = Mode_switch |
add mod2 = Mode_switch |
1828 |
EOF |
EOF |
1829 |
|
|
1830 |
* The Emacs window disappears when you type M-q. |
*** HP/UX: "Cannot find callback list" messages from dialog boxes in |
1831 |
|
Emacs built with Motif. |
1832 |
|
|
1833 |
Some versions of the Open Look window manager interpret M-q as a quit |
This problem resulted from a bug in GCC 2.4.5. Newer GCC versions |
1834 |
command for whatever window you are typing at. If you want to use |
such as 2.7.0 fix the problem. |
|
Emacs with that window manager, you should try to configure the window |
|
|
manager to use some other command. You can disable the |
|
|
shortcut keys entirely by adding this line to ~/.OWdefaults: |
|
1835 |
|
|
1836 |
OpenWindows.WindowMenuAccelerators: False |
*** HP/UX: Emacs does not recognize the AltGr key. |
1837 |
|
|
1838 |
* Emacs does not notice when you release the mouse. |
To fix this, set up a file ~/.dt/sessions/sessionetc with executable |
1839 |
|
rights, containing this text: |
1840 |
|
|
1841 |
There are reports that this happened with (some) Microsoft mice and |
-------------------------------- |
1842 |
that replacing the mouse made it stop. |
xmodmap 2> /dev/null - << EOF |
1843 |
|
keysym Alt_L = Meta_L |
1844 |
|
keysym Alt_R = Meta_R |
1845 |
|
EOF |
1846 |
|
|
1847 |
* Trouble using ptys on IRIX, or running out of ptys. |
xmodmap - << EOF |
1848 |
|
clear mod1 |
1849 |
|
keysym Mode_switch = NoSymbol |
1850 |
|
add mod1 = Meta_L |
1851 |
|
keysym Meta_R = Mode_switch |
1852 |
|
add mod2 = Mode_switch |
1853 |
|
EOF |
1854 |
|
-------------------------------- |
1855 |
|
|
1856 |
The program mkpts (which may be in `/usr/adm' or `/usr/sbin') needs to |
*** HP/UX: Large file support is disabled. |
|
be set-UID to root, or non-root programs like Emacs will not be able |
|
|
to allocate ptys reliably. |
|
1857 |
|
|
1858 |
* On Irix 5.2, unexelfsgi.c can't find cmplrs/stsupport.h. |
See the comments in src/s/hpux10.h. |
1859 |
|
|
1860 |
The file cmplrs/stsupport.h was included in the wrong file set in the |
*** HP/UX 11.0: Emacs makes HP/UX 11.0 crash. |
|
Irix 5.2 distribution. You can find it in the optional fileset |
|
|
compiler_dev, or copy it from some other Irix 5.2 system. A kludgy |
|
|
workaround is to change unexelfsgi.c to include sym.h instead of |
|
|
syms.h. |
|
1861 |
|
|
1862 |
* Slow startup on Linux-based GNU systems. |
This is a bug in HPUX; HPUX patch PHKL_16260 is said to fix it. |
1863 |
|
|
1864 |
People using systems based on the Linux kernel sometimes report that |
** AIX |
|
startup takes 10 to 15 seconds longer than `usual'. |
|
1865 |
|
|
1866 |
This is because Emacs looks up the host name when it starts. |
*** AIX: Trouble using ptys. |
|
Normally, this takes negligible time; the extra delay is due to |
|
|
improper system configuration. This problem can occur for both |
|
|
networked and non-networked machines. |
|
1867 |
|
|
1868 |
Here is how to fix the configuration. It requires being root. |
People often install the pty devices on AIX incorrectly. |
1869 |
|
Use `smit pty' to reinstall them properly. |
1870 |
|
|
1871 |
** Networked Case |
*** AIXterm: Your Delete key sends a Backspace to the terminal. |
1872 |
|
|
1873 |
First, make sure the files `/etc/hosts' and `/etc/host.conf' both |
The solution is to include in your .Xdefaults the lines: |
|
exist. The first line in the `/etc/hosts' file should look like this |
|
|
(replace HOSTNAME with your host name): |
|
1874 |
|
|
1875 |
127.0.0.1 HOSTNAME |
*aixterm.Translations: #override <Key>BackSpace: string(0x7f) |
1876 |
|
aixterm*ttyModes: erase ^? |
1877 |
|
|
1878 |
Also make sure that the `/etc/host.conf' files contains the following |
This makes your Backspace key send DEL (ASCII 127). |
|
lines: |
|
1879 |
|
|
1880 |
order hosts, bind |
*** AIX: You get this message when running Emacs: |
|
multi on |
|
1881 |
|
|
1882 |
Any changes, permanent and temporary, to the host name should be |
Could not load program emacs |
1883 |
indicated in the `/etc/hosts' file, since it acts a limited local |
Symbol smtcheckinit in csh is undefined |
1884 |
database of addresses and names (e.g., some SLIP connections |
Error was: Exec format error |
|
dynamically allocate ip addresses). |
|
1885 |
|
|
1886 |
** Non-Networked Case |
or this one: |
1887 |
|
|
1888 |
The solution described in the networked case applies here as well. |
Could not load program .emacs |
1889 |
However, if you never intend to network your machine, you can use a |
Symbol _system_con in csh is undefined |
1890 |
simpler solution: create an empty `/etc/host.conf' file. The command |
Symbol _fp_trapsta in csh is undefined |
1891 |
`touch /etc/host.conf' suffices to create the file. The `/etc/hosts' |
Error was: Exec format error |
|
file is not necessary with this approach. |
|
1892 |
|
|
1893 |
* On Solaris 2.4, Dired hangs and C-g does not work. Or Emacs hangs |
These can happen when you try to run on AIX 3.2.5 a program that was |
1894 |
forever waiting for termination of a subprocess that is a zombie. |
compiled with 3.2.4. The fix is to recompile. |
1895 |
|
|
1896 |
casper@fwi.uva.nl says the problem is in X11R6. Rebuild libX11.so |
*** AIX 3.2.4: Releasing Ctrl/Act key has no effect, if Shift is down. |
|
after changing the file xc/config/cf/sunLib.tmpl. Change the lines |
|
1897 |
|
|
1898 |
#if ThreadedX |
Due to a feature of AIX, pressing or releasing the Ctrl/Act key is |
1899 |
#define SharedX11Reqs -lthread |
ignored when the Shift, Alt or AltGr keys are held down. This can |
1900 |
#endif |
lead to the keyboard being "control-locked"--ordinary letters are |
1901 |
|
treated as control characters. |
1902 |
|
|
1903 |
to: |
You can get out of this "control-locked" state by pressing and |
1904 |
|
releasing Ctrl/Act while not pressing or holding any other keys. |
1905 |
|
|
1906 |
#if OSMinorVersion < 4 |
*** AIX 4.2: Emacs gets a segmentation fault at startup. |
|
#if ThreadedX |
|
|
#define SharedX11Reqs -lthread |
|
|
#endif |
|
|
#endif |
|
1907 |
|
|
1908 |
Be sure also to edit x/config/cf/sun.cf so that OSMinorVersion is 4 |
If you are using IBM's xlc compiler, compile emacs.c |
1909 |
(as it should be for Solaris 2.4). The file has three definitions for |
without optimization; that should avoid the problem. |
|
OSMinorVersion: the first is for x86, the second for SPARC under |
|
|
Solaris, and the third for SunOS 4. Make sure to update the |
|
|
definition for your type of machine and system. |
|
1910 |
|
|
1911 |
Then do `make Everything' in the top directory of X11R6, to rebuild |
*** AIX: If linking fails because libXbsd isn't found, check if you |
1912 |
the makefiles and rebuild X. The X built this way work only on |
are compiling with the system's `cc' and CFLAGS containing `-O5'. If |
1913 |
Solaris 2.4, not on 2.3. |
so, you have hit a compiler bug. Please make sure to re-configure |
1914 |
|
Emacs so that it isn't compiled with `-O5'. |
1915 |
|
|
1916 |
For multithreaded X to work it is necessary to install patch |
*** AIX 4.3.x or 4.4: Compiling fails. |
|
101925-02 to fix problems in header files [2.4]. You need |
|
|
to reinstall gcc or re-run just-fixinc after installing that |
|
|
patch. |
|
1917 |
|
|
1918 |
However, Frank Rust <frust@iti.cs.tu-bs.de> used a simpler solution: |
This could happen if you use /bin/c89 as your compiler, instead of |
1919 |
he changed |
the default `cc'. /bin/c89 treats certain warnings, such as benign |
1920 |
#define ThreadedX YES |
redefinitions of macros, as errors, and fails the build. A solution |
1921 |
to |
is to use the default compiler `cc'. |
|
#define ThreadedX NO |
|
|
in sun.cf and did `make World' to rebuild X11R6. Removing all |
|
|
`-DXTHREAD*' flags and `-lthread' entries from lib/X11/Makefile and |
|
|
typing 'make install' in that directory also seemed to work. |
|
1922 |
|
|
1923 |
* With M-x enable-flow-control, you need to type C-\ twice |
*** AIX 4: Some programs fail when run in a Shell buffer |
1924 |
to do incremental search--a single C-\ gets no response. |
with an error message like No terminfo entry for "unknown". |
1925 |
|
|
1926 |
This has been traced to communicating with your machine via kermit, |
On AIX, many terminal type definitions are not installed by default. |
1927 |
with C-\ as the kermit escape character. One solution is to use |
`unknown' is one of them. Install the "Special Generic Terminal |
1928 |
another escape character in kermit. One user did |
Definitions" to make them defined. |
1929 |
|
|
1930 |
set escape-character 17 |
** Solaris |
1931 |
|
|
1932 |
in his .kermrc file, to make C-q the kermit escape character. |
We list bugs in current versions here. Solaris 2.x and 4.x are covered in the |
1933 |
|
section on legacy systems. |
1934 |
|
|
1935 |
* The Motif version of Emacs paints the screen a solid color. |
*** On Solaris, C-x doesn't get through to Emacs when you use the console. |
1936 |
|
|
1937 |
This has been observed to result from the following X resource: |
This is a Solaris feature (at least on Intel x86 cpus). Type C-r |
1938 |
|
C-r C-t, to toggle whether C-x gets through to Emacs. |
1939 |
|
|
1940 |
Emacs*default.attributeFont: -*-courier-medium-r-*-*-*-140-*-*-*-*-iso8859-* |
*** Problem with remote X server on Suns. |
1941 |
|
|
1942 |
That the resource has this effect indicates a bug in something, but we |
On a Sun, running Emacs on one machine with the X server on another |
1943 |
do not yet know what. If it is an Emacs bug, we hope someone can |
may not work if you have used the unshared system libraries. This |
1944 |
explain what the bug is so we can fix it. In the mean time, removing |
is because the unshared libraries fail to use YP for host name lookup. |
1945 |
the resource prevents the problem. |
As a result, the host name you specify may not be recognized. |
1946 |
|
|
1947 |
* Emacs gets hung shortly after startup, on Sunos 4.1.3. |
*** Emacs reports a BadAtom error (from X) running on Solaris 7 or 8. |
1948 |
|
|
1949 |
We think this is due to a bug in Sunos. The word is that |
This happens when Emacs was built on some other version of Solaris. |
1950 |
one of these Sunos patches fixes the bug: |
Rebuild it on Solaris 8. |
1951 |
|
|
1952 |
100075-11 100224-06 100347-03 100482-05 100557-02 100623-03 100804-03 101080-01 |
*** On Solaris, CTRL-t is ignored by Emacs when you use |
1953 |
100103-12 100249-09 100496-02 100564-07 100630-02 100891-10 101134-01 |
the fr.ISO-8859-15 locale (and maybe other related locales). |
|
100170-09 100296-04 100377-09 100507-04 100567-04 100650-02 101070-01 101145-01 |
|
|
100173-10 100305-15 100383-06 100513-04 100570-05 100689-01 101071-03 101200-02 |
|
|
100178-09 100338-05 100421-03 100536-02 100584-05 100784-01 101072-01 101207-01 |
|
1954 |
|
|
1955 |
We don't know which of these patches really matter. If you find out |
You can fix this by editing the file: |
|
which ones, please inform bug-gnu-emacs@gnu.org. |
|
1956 |
|
|
1957 |
* Emacs aborts while starting up, only when run without X. |
/usr/openwin/lib/locale/iso8859-15/Compose |
1958 |
|
|
1959 |
This problem often results from compiling Emacs with GCC when GCC was |
Near the bottom there is a line that reads: |
|
installed incorrectly. The usual error in installing GCC is to |
|
|
specify --includedir=/usr/include. Installation of GCC makes |
|
|
corrected copies of the system header files. GCC is supposed to use |
|
|
the corrected copies in preference to the original system headers. |
|
|
Specifying --includedir=/usr/include causes the original system header |
|
|
files to be used. On some systems, the definition of ioctl in the |
|
|
original system header files is invalid for ANSI C and causes Emacs |
|
|
not to work. |
|
1960 |
|
|
1961 |
The fix is to reinstall GCC, and this time do not specify --includedir |
Ctrl<t> <quotedbl> <Y> : "\276" threequarters |
|
when you configure it. Then recompile Emacs. Specifying --includedir |
|
|
is appropriate only in very special cases and it should *never* be the |
|
|
same directory where system header files are kept. |
|
1962 |
|
|
1963 |
* On Solaris 2.x, GCC complains "64 bit integer types not supported" |
that should read: |
1964 |
|
|
1965 |
This suggests that GCC is not installed correctly. Most likely you |
Ctrl<T> <quotedbl> <Y> : "\276" threequarters |
|
are using GCC 2.7.2.3 (or earlier) on Solaris 2.6 (or later); this |
|
|
does not work without patching. To run GCC 2.7.2.3 on Solaris 2.6 or |
|
|
later, you must patch fixinc.svr4 and reinstall GCC from scratch as |
|
|
described in the Solaris FAQ |
|
|
<http://www.wins.uva.nl/pub/solaris/solaris2.html>. A better fix is |
|
|
to upgrade to GCC 2.8.1 or later. |
|
1966 |
|
|
1967 |
* The Compose key on a DEC keyboard does not work as Meta key. |
Note the lower case <t>. Changing this line should make C-t work. |
1968 |
|
|
1969 |
This shell command should fix it: |
*** When using M-x dbx with the SparcWorks debugger, the `up' and `down' |
1970 |
|
commands do not move the arrow in Emacs. |
1971 |
|
|
1972 |
xmodmap -e 'keycode 0xb1 = Meta_L' |
You can fix this by adding the following line to `~/.dbxinit': |
1973 |
|
|
1974 |
* Regular expressions matching bugs on SCO systems. |
dbxenv output_short_file_name off |
1975 |
|
|
1976 |
On SCO, there are problems in regexp matching when Emacs is compiled |
** Irix |
|
with the system compiler. The compiler version is "Microsoft C |
|
|
version 6", SCO 4.2.0h Dev Sys Maintenance Supplement 01/06/93; Quick |
|
|
C Compiler Version 1.00.46 (Beta). The solution is to compile with |
|
|
GCC. |
|
1977 |
|
|
1978 |
* On Sunos 4, you get the error ld: Undefined symbol __lib_version. |
*** Irix 5.2: unexelfsgi.c can't find cmplrs/stsupport.h. |
1979 |
|
|
1980 |
This is the result of using cc or gcc with the shared library meant |
The file cmplrs/stsupport.h was included in the wrong file set in the |
1981 |
for acc (the Sunpro compiler). Check your LD_LIBRARY_PATH and delete |
Irix 5.2 distribution. You can find it in the optional fileset |
1982 |
/usr/lang/SC2.0.1 or some similar directory. |
compiler_dev, or copy it from some other Irix 5.2 system. A kludgy |
1983 |
|
workaround is to change unexelfsgi.c to include sym.h instead of |
1984 |
|
syms.h. |
1985 |
|
|
1986 |
* You can't select from submenus (in the X toolkit version). |
*** Irix 5.3: "out of virtual swap space". |
1987 |
|
|
1988 |
On certain systems, mouse-tracking and selection in top-level menus |
This message occurs when the system runs out of swap space due to too |
1989 |
works properly with the X toolkit, but neither of them works when you |
many large programs running. The solution is either to provide more |
1990 |
bring up a submenu (such as Bookmarks or Compare or Apply Patch, in |
swap space or to reduce the number of large programs being run. You |
1991 |
the Files menu). |
can check the current status of the swap space by executing the |
1992 |
|
command `swap -l'. |
1993 |
|
|
1994 |
This works on most systems. There is speculation that the failure is |
You can increase swap space by changing the file /etc/fstab. Adding a |
1995 |
due to bugs in old versions of X toolkit libraries, but no one really |
line like this: |
1996 |
knows. If someone debugs this and finds the precise cause, perhaps a |
|
1997 |
workaround can be found. |
/usr/swap/swap.more swap swap pri=3 0 0 |
1998 |
|
|
1999 |
|
where /usr/swap/swap.more is a file previously created (for instance |
2000 |
|
by using /etc/mkfile), will increase the swap space by the size of |
2001 |
|
that file. Execute `swap -m' or reboot the machine to activate the |
2002 |
|
new swap area. See the manpages for `swap' and `fstab' for further |
2003 |
|
information. |
2004 |
|
|
2005 |
|
The objectserver daemon can use up lots of memory because it can be |
2006 |
|
swamped with NIS information. It collects information about all users |
2007 |
|
on the network that can log on to the host. |
2008 |
|
|
2009 |
|
If you want to disable the objectserver completely, you can execute |
2010 |
|
the command `chkconfig objectserver off' and reboot. That may disable |
2011 |
|
some of the window system functionality, such as responding CDROM |
2012 |
|
icons. |
2013 |
|
|
2014 |
|
You can also remove NIS support from the objectserver. The SGI `admin' |
2015 |
|
FAQ has a detailed description on how to do that; see question 35 |
2016 |
|
("Why isn't the objectserver working?"). The admin FAQ can be found at |
2017 |
|
ftp://viz.tamu.edu/pub/sgi/faq/. |
2018 |
|
|
2019 |
|
*** Irix 5.3: Emacs crashes in utmpname. |
2020 |
|
|
2021 |
* Unusable default font on SCO 3.2v4. |
This problem is fixed in Patch 3175 for Irix 5.3. |
2022 |
|
It is also fixed in Irix versions 6.2 and up. |
2023 |
|
|
2024 |
|
*** Irix 6.0: Make tries (and fails) to build a program named unexelfsgi. |
2025 |
|
|
2026 |
|
A compiler bug inserts spaces into the string "unexelfsgi . o" |
2027 |
|
in src/Makefile. Edit src/Makefile, after configure is run, |
2028 |
|
find that string, and take out the spaces. |
2029 |
|
|
2030 |
|
Compiler fixes in Irix 6.0.1 should eliminate this problem. |
2031 |
|
|
2032 |
|
*** Irix 6.5: Emacs crashes on the SGI R10K, when compiled with GCC. |
2033 |
|
|
2034 |
|
This seems to be fixed in GCC 2.95. |
2035 |
|
|
2036 |
|
*** Trouble using ptys on IRIX, or running out of ptys. |
2037 |
|
|
2038 |
|
The program mkpts (which may be in `/usr/adm' or `/usr/sbin') needs to |
2039 |
|
be set-UID to root, or non-root programs like Emacs will not be able |
2040 |
|
to allocate ptys reliably. |
2041 |
|
|
2042 |
|
** SCO Unix and UnixWare |
2043 |
|
|
2044 |
|
*** SCO 3.2v4: Unusable default font. |
2045 |
|
|
2046 |
The Open Desktop environment comes with default X resource settings |
The Open Desktop environment comes with default X resource settings |
2047 |
that tell Emacs to use a variable-width font. Emacs cannot use such |
that tell Emacs to use a variable-width font. Emacs cannot use such |
2076 |
These resource files are not normally shared across a network of SCO |
These resource files are not normally shared across a network of SCO |
2077 |
machines; you must create the file on each machine individually. |
machines; you must create the file on each machine individually. |
2078 |
|
|
2079 |
* rcs2log gives you the awk error message "too many fields". |
*** Regular expressions matching bugs on SCO systems. |
|
|
|
|
This is due to an arbitrary limit in certain versions of awk. |
|
|
The solution is to use gawk (GNU awk). |
|
|
|
|
|
* Emacs is slow using X11R5 on HP/UX. |
|
|
|
|
|
This happens if you use the MIT versions of the X libraries--it |
|
|
doesn't run as fast as HP's version. People sometimes use the version |
|
|
because they see the HP version doesn't have the libraries libXaw.a, |
|
|
libXmu.a, libXext.a and others. HP/UX normally doesn't come with |
|
|
those libraries installed. To get good performance, you need to |
|
|
install them and rebuild Emacs. |
|
2080 |
|
|
2081 |
* Loading fonts is very slow. |
On SCO, there are problems in regexp matching when Emacs is compiled |
2082 |
|
with the system compiler. The compiler version is "Microsoft C |
2083 |
|
version 6", SCO 4.2.0h Dev Sys Maintenance Supplement 01/06/93; Quick |
2084 |
|
C Compiler Version 1.00.46 (Beta). The solution is to compile with |
2085 |
|
GCC. |
2086 |
|
|
2087 |
You might be getting scalable fonts instead of precomputed bitmaps. |
*** UnixWare 2.1: Error 12 (virtual memory exceeded) when dumping Emacs. |
|
Known scalable font directories are "Type1" and "Speedo". A font |
|
|
directory contains scalable fonts if it contains the file |
|
|
"fonts.scale". |
|
2088 |
|
|
2089 |
If this is so, re-order your X windows font path to put the scalable |
Paul Abrahams (abrahams@acm.org) reports that with the installed |
2090 |
font directories last. See the documentation of `xset' for details. |
virtual memory settings for UnixWare 2.1.2, an Error 12 occurs during |
2091 |
|
the "make" that builds Emacs, when running temacs to dump emacs. That |
2092 |
|
error indicates that the per-process virtual memory limit has been |
2093 |
|
exceeded. The default limit is probably 32MB. Raising the virtual |
2094 |
|
memory limit to 40MB should make it possible to finish building Emacs. |
2095 |
|
|
2096 |
With some X servers, it may be necessary to take the scalable font |
You can do this with the command `ulimit' (sh) or `limit' (csh). |
2097 |
directories out of your path entirely, at least for Emacs 19.26. |
But you have to be root to do it. |
|
Changes in the future may make this unnecessary. |
|
2098 |
|
|
2099 |
* On AIX 3.2.4, releasing Ctrl/Act key has no effect, if Shift is down. |
According to Martin Sohnius, you can also retune this in the kernel: |
2100 |
|
|
2101 |
Due to a feature of AIX, pressing or releasing the Ctrl/Act key is |
# /etc/conf/bin/idtune SDATLIM 33554432 ## soft data size limit |
2102 |
ignored when the Shift, Alt or AltGr keys are held down. This can |
# /etc/conf/bin/idtune HDATLIM 33554432 ## hard " |
2103 |
lead to the keyboard being "control-locked"--ordinary letters are |
# /etc/conf/bin/idtune SVMMSIZE unlimited ## soft process size limit |
2104 |
treated as control characters. |
# /etc/conf/bin/idtune HVMMSIZE unlimited ## hard " |
2105 |
|
# /etc/conf/bin/idbuild -B |
2106 |
|
|
2107 |
You can get out of this "control-locked" state by pressing and |
(He recommends you not change the stack limit, though.) |
2108 |
releasing Ctrl/Act while not pressing or holding any other keys. |
These changes take effect when you reboot. |
2109 |
|
|
2110 |
* display-time causes kernel problems on ISC systems. |
* Runtime problems specific to MS-Windows |
2111 |
|
|
2112 |
Under Interactive Unix versions 3.0.1 and 4.0 (and probably other |
** Emacs exits with "X protocol error" when run with an X server for MS-Windows. |
|
versions), display-time causes the loss of large numbers of STREVENT |
|
|
cells. Eventually the kernel's supply of these cells is exhausted. |
|
|
This makes emacs and the whole system run slow, and can make other |
|
|
processes die, in particular pcnfsd. |
|
2113 |
|
|
2114 |
Other emacs functions that communicate with remote processes may have |
A certain X server for Windows had a bug which caused this. |
2115 |
the same problem. Display-time seems to be far the worst. |
Supposedly the newer 32-bit version of this server doesn't have the |
2116 |
|
problem. |
2117 |
|
|
2118 |
The only known fix: Don't run display-time. |
** Known problems with the MS-Windows port of Emacs 21.2. |
2119 |
|
|
2120 |
* On Solaris, C-x doesn't get through to Emacs when you use the console. |
Frames are not refreshed while the File or Font dialog or a pop-up menu |
2121 |
|
is displayed. This also means help text for pop-up menus is not |
2122 |
|
displayed at all. This is because message handling under Windows is |
2123 |
|
synchronous, so we cannot handle repaint (or any other) messages while |
2124 |
|
waiting for a system function to return the result of the dialog or |
2125 |
|
pop-up menu interaction. |
2126 |
|
|
2127 |
This is a Solaris feature (at least on Intel x86 cpus). Type C-r |
Windows 95 and Windows NT up to version 4.0 do not support help text |
2128 |
C-r C-t, to toggle whether C-x gets through to Emacs. |
for menus. Help text is only available in later versions of Windows. |
2129 |
|
|
2130 |
* Error message `Symbol's value as variable is void: x', followed by |
There are problems with display if mouse-tracking is enabled and the |
2131 |
segmentation fault and core dump. |
mouse is moved off a frame, over another frame then back over the first |
2132 |
|
frame. A workaround is to click the left mouse button inside the frame |
2133 |
|
after moving back into it. |
2134 |
|
|
2135 |
This has been tracked to a bug in tar! People report that tar erroneously |
Some minor flickering still persists during mouse-tracking, although |
2136 |
added a line like this at the beginning of files of Lisp code: |
not as severely as in 21.1. |
2137 |
|
|
2138 |
x FILENAME, N bytes, B tape blocks |
Emacs can sometimes abort when non-ASCII text, possibly with null |
2139 |
|
characters, is copied and pasted into a buffer. |
2140 |
|
|
2141 |
If your tar has this problem, install GNU tar--if you can manage to |
An inactive cursor remains in an active window after the Windows |
2142 |
untar it :-). |
Manager driven switch of the focus, until a key is pressed. |
2143 |
|
|
2144 |
* Link failure when using acc on a Sun. |
Windows input methods are not recognized by Emacs (as of v21.2). Some |
2145 |
|
of these input methods cause the keyboard to send characters encoded |
2146 |
|
in the appropriate coding system (e.g., ISO 8859-1 for Latin-1 |
2147 |
|
characters, ISO 8859-8 for Hebrew characters, etc.). To make this |
2148 |
|
work, set the keyboard coding system to the appropriate value after |
2149 |
|
you activate the Windows input method. For example, if you activate |
2150 |
|
the Hebrew input method, type "C-x RET k iso-8859-8 RET". (Emacs |
2151 |
|
ought to recognize the Windows language-change event and set up the |
2152 |
|
appropriate keyboard encoding automatically, but it doesn't do that |
2153 |
|
yet.) |
2154 |
|
|
2155 |
To use acc, you need additional options just before the libraries, such as |
The %b specifier for format-time-string does not produce abbreviated |
2156 |
|
month names with consistent widths for some locales on some versions |
2157 |
|
of Windows. This is caused by a deficiency in the underlying system |
2158 |
|
library function. |
2159 |
|
|
2160 |
/usr/lang/SC2.0.1/values-Xt.o -L/usr/lang/SC2.0.1/cg87 -L/usr/lang/SC2.0.1 |
** Problems running Perl under Emacs on MS-Windows NT/95. |
2161 |
|
|
2162 |
and you need to add -lansi just before -lc. |
`perl -de 0' just hangs when executed in an Emacs subshell. |
2163 |
|
The fault lies with Perl (indirectly with Windows NT/95). |
2164 |
|
|
2165 |
The precise file names depend on the compiler version, so we |
The problem is that the Perl debugger explicitly opens a connection to |
2166 |
cannot easily arrange to supply them. |
"CON", which is the DOS/NT equivalent of "/dev/tty", for interacting |
2167 |
|
with the user. |
2168 |
|
|
2169 |
* Link failure on IBM AIX 1.3 ptf 0013. |
On Unix, this is okay, because Emacs (or the shell?) creates a |
2170 |
|
pseudo-tty so that /dev/tty is really the pipe Emacs is using to |
2171 |
|
communicate with the subprocess. |
2172 |
|
|
2173 |
There is a real duplicate definition of the function `_slibc_free' in |
On NT, this fails because CON always refers to the handle for the |
2174 |
the library /lib/libc_s.a (just do nm on it to verify). The |
relevant console (approximately equivalent to a tty), and cannot be |
2175 |
workaround/fix is: |
redirected to refer to the pipe Emacs assigned to the subprocess as |
2176 |
|
stdin. |
2177 |
|
|
2178 |
cd /lib |
A workaround is to modify perldb.pl to use STDIN/STDOUT instead of CON. |
|
ar xv libc_s.a NLtmtime.o |
|
|
ar dv libc_s.a NLtmtime.o |
|
2179 |
|
|
2180 |
* Undefined symbols _dlopen, _dlsym and/or _dlclose on a Sun. |
For Perl 4: |
2181 |
|
|
2182 |
If you see undefined symbols _dlopen, _dlsym, or _dlclose when linking |
*** PERL/LIB/PERLDB.PL.orig Wed May 26 08:24:18 1993 |
2183 |
with -lX11, compile and link against the file mit/util/misc/dlsym.c in |
--- PERL/LIB/PERLDB.PL Mon Jul 01 15:28:16 1996 |
2184 |
the MIT X11R5 distribution. Alternatively, link temacs using shared |
*************** |
2185 |
libraries with s/sunos4shr.h. (This doesn't work if you use the X |
*** 68,74 **** |
2186 |
toolkit.) |
$rcfile=".perldb"; |
2187 |
|
} |
2188 |
|
else { |
2189 |
|
! $console = "con"; |
2190 |
|
$rcfile="perldb.ini"; |
2191 |
|
} |
2192 |
|
|
2193 |
If you get the additional error that the linker could not find |
--- 68,74 ---- |
2194 |
lib_version.o, try extracting it from X11/usr/lib/X11/libvim.a in |
$rcfile=".perldb"; |
2195 |
X11R4, then use it in the link. |
} |
2196 |
|
else { |
2197 |
|
! $console = ""; |
2198 |
|
$rcfile="perldb.ini"; |
2199 |
|
} |
2200 |
|
|
|
* Error messages `Wrong number of arguments: #<subr where-is-internal>, 5' |
|
2201 |
|
|
2202 |
This typically results from having the powerkey library loaded. |
For Perl 5: |
2203 |
Powerkey was designed for Emacs 19.22. It is obsolete now because |
*** perl/5.001/lib/perl5db.pl.orig Sun Jun 04 21:13:40 1995 |
2204 |
Emacs 19 now has this feature built in; and powerkey also calls |
--- perl/5.001/lib/perl5db.pl Mon Jul 01 17:00:08 1996 |
2205 |
where-is-internal in an obsolete way. |
*************** |
2206 |
|
*** 22,28 **** |
2207 |
|
$rcfile=".perldb"; |
2208 |
|
} |
2209 |
|
elsif (-e "con") { |
2210 |
|
! $console = "con"; |
2211 |
|
$rcfile="perldb.ini"; |
2212 |
|
} |
2213 |
|
else { |
2214 |
|
--- 22,28 ---- |
2215 |
|
$rcfile=".perldb"; |
2216 |
|
} |
2217 |
|
elsif (-e "con") { |
2218 |
|
! $console = ""; |
2219 |
|
$rcfile="perldb.ini"; |
2220 |
|
} |
2221 |
|
else { |
2222 |
|
|
2223 |
So the fix is to arrange not to load powerkey. |
** On MS-Windows 95, Alt-f6 does not get through to Emacs. |
2224 |
|
|
2225 |
* In Shell mode, you get a ^M at the end of every line. |
This character seems to be trapped by the kernel in Windows 95. |
2226 |
|
You can enter M-f6 by typing ESC f6. |
2227 |
|
|
2228 |
This happens to people who use tcsh, because it is trying to be too |
** Typing Alt-Shift has strange effects on MS-Windows. |
|
smart. It sees that the Shell uses terminal type `unknown' and turns |
|
|
on the flag to output ^M at the end of each line. You can fix the |
|
|
problem by adding this to your .cshrc file: |
|
2229 |
|
|
2230 |
if ($?EMACS) then |
This combination of keys is a command to change keyboard layout. If |
2231 |
if ($EMACS == "t") then |
you proceed to type another non-modifier key before you let go of Alt |
2232 |
unset edit |
and Shift, the Alt and Shift act as modifiers in the usual way. A |
2233 |
stty -icrnl -onlcr -echo susp ^Z |
more permanent work around is to change it to another key combination, |
2234 |
endif |
or disable it in the keyboard control panel. |
|
endif |
|
2235 |
|
|
2236 |
* An error message such as `X protocol error: BadMatch (invalid |
** Interrupting Cygwin port of Bash from Emacs doesn't work. |
|
parameter attributes) on protocol request 93'. |
|
2237 |
|
|
2238 |
This comes from having an invalid X resource, such as |
Cygwin 1.x builds of the ported Bash cannot be interrupted from the |
2239 |
emacs*Cursor: black |
MS-Windows version of Emacs. This is due to some change in the Bash |
2240 |
(which is invalid because it specifies a color name for something |
port or in the Cygwin library which apparently make Bash ignore the |
2241 |
that isn't a color.) |
keyboard interrupt event sent by Emacs to Bash. (Older Cygwin ports |
2242 |
|
of Bash, up to b20.1, did receive SIGINT from Emacs.) |
2243 |
|
|
2244 |
The fix is to correct your X resources. |
** Accessing remote files with ange-ftp hangs the MS-Windows version of Emacs. |
2245 |
|
|
2246 |
* Undefined symbols when linking on Sunos 4.1 using --with-x-toolkit. |
If the FTP client is the Cygwin port of GNU `ftp', this appears to be |
2247 |
|
due to some bug in the Cygwin DLL or some incompatibility between it |
2248 |
|
and the implementation of asynchronous subprocesses in the Windows |
2249 |
|
port of Emacs. Specifically, some parts of the FTP server responses |
2250 |
|
are not flushed out, apparently due to buffering issues, which |
2251 |
|
confuses ange-ftp. |
2252 |
|
|
2253 |
If you get the undefined symbols _atowc _wcslen, _iswprint, _iswspace, |
The solution is to downgrade to an older version of the Cygwin DLL |
2254 |
_iswcntrl, _wcscpy, and _wcsncpy, then you need to add -lXwchar after |
(version 1.3.2 was reported to solve the problem), or use the stock |
2255 |
-lXaw in the command that links temacs. |
Windows FTP client, usually found in the `C:\WINDOWS' or 'C:\WINNT' |
2256 |
|
directory. To force ange-ftp use the stock Windows client, set the |
2257 |
|
variable `ange-ftp-ftp-program-name' to the absolute file name of the |
2258 |
|
client's executable. For example: |
2259 |
|
|
2260 |
This problem seems to arise only when the international language |
(setq ange-ftp-ftp-program-name "c:/windows/ftp.exe") |
|
extensions to X11R5 are installed. |
|
2261 |
|
|
2262 |
* Typing C-c C-c in Shell mode kills your X server. |
If you want to stick with the Cygwin FTP client, you can work around |
2263 |
|
this problem by putting this in your `.emacs' file: |
2264 |
|
|
2265 |
This happens with Linux kernel 1.0 thru 1.04, approximately. The workaround is |
(setq ange-ftp-ftp-program-args '("-i" "-n" "-g" "-v" "--prompt" "") |
|
to define SIGNALS_VIA_CHARACTERS in config.h and recompile Emacs. |
|
|
Newer Linux kernel versions don't have this problem. |
|
2266 |
|
|
2267 |
* src/Makefile and lib-src/Makefile are truncated--most of the file missing. |
** lpr commands don't work on MS-Windows with some cheap printers. |
2268 |
|
|
2269 |
This can happen if configure uses GNU sed version 2.03. That version |
This problem may also strike other platforms, but the solution is |
2270 |
had a bug. GNU sed version 2.05 works properly. |
likely to be a global one, and not Emacs specific. |
2271 |
|
|
2272 |
* Slow startup on X11R6 with X windows. |
Many cheap inkjet, and even some cheap laser printers, do not |
2273 |
|
print plain text anymore, they will only print through graphical |
2274 |
|
printer drivers. A workaround on MS-Windows is to use Windows' basic |
2275 |
|
built in editor to print (this is possibly the only useful purpose it |
2276 |
|
has): |
2277 |
|
|
2278 |
If Emacs takes two minutes to start up on X11R6, see if your X |
(setq printer-name "") ;; notepad takes the default |
2279 |
resources specify any Adobe fonts. That causes the type-1 font |
(setq lpr-command "notepad") ;; notepad |
2280 |
renderer to start up, even if the font you asked for is not a type-1 |
(setq lpr-switches nil) ;; not needed |
2281 |
font. |
(setq lpr-printer-switch "/P") ;; run notepad as batch printer |
2282 |
|
|
2283 |
One way to avoid this problem is to eliminate the type-1 fonts from |
** Antivirus software interacts badly with the MS-Windows version of Emacs. |
|
your font path, like this: |
|
2284 |
|
|
2285 |
xset -fp /usr/X11R6/lib/X11/fonts/Type1/ |
The usual manifestation of these problems is that subprocesses don't |
2286 |
|
work or even wedge the entire system. In particular, "M-x shell RET" |
2287 |
|
was reported to fail to work. But other commands also sometimes don't |
2288 |
|
work when an antivirus package is installed. |
2289 |
|
|
2290 |
* Pull-down menus appear in the wrong place, in the toolkit version of Emacs. |
The solution is to switch the antivirus software to a less aggressive |
2291 |
|
mode (e.g., disable the ``auto-protect'' feature), or even uninstall |
2292 |
|
or disable it entirely. |
2293 |
|
|
2294 |
An X resource of this form can cause the problem: |
** On MS-Windows 95/98/ME, subprocesses do not terminate properly. |
2295 |
|
|
2296 |
Emacs*geometry: 80x55+0+0 |
This is a limitation of the Operating System, and can cause problems |
2297 |
|
when shutting down Windows. Ensure that all subprocesses are exited |
2298 |
|
cleanly before exiting Emacs. For more details, see the FAQ at |
2299 |
|
http://www.gnu.org/software/emacs/windows/. |
2300 |
|
|
2301 |
This resource is supposed to apply, and does apply, to the menus |
** MS-Windows 95/98/ME crashes when Emacs invokes non-existent programs. |
|
individually as well as to Emacs frames. If that is not what you |
|
|
want, rewrite the resource. |
|
2302 |
|
|
2303 |
To check thoroughly for such resource specifications, use `xrdb |
When a program you are trying to run is not found on the PATH, |
2304 |
-query' to see what resources the X server records, and also look at |
Windows might respond by crashing or locking up your system. In |
2305 |
the user's ~/.Xdefaults and ~/.Xdefaults-* files. |
particular, this has been reported when trying to compile a Java |
2306 |
|
program in JDEE when javac.exe is installed, but not on the system |
2307 |
|
PATH. |
2308 |
|
|
2309 |
* --with-x-toolkit version crashes when used with shared libraries. |
** Pressing the mouse button on MS-Windows does not give a mouse-2 event. |
2310 |
|
|
2311 |
On some systems, including Sunos 4 and DGUX 5.4.2 and perhaps others, |
This is usually a problem with the mouse driver. Because most Windows |
2312 |
unexec doesn't work properly with the shared library for the X |
programs do not do anything useful with the middle mouse button, many |
2313 |
toolkit. You might be able to work around this by using a nonshared |
mouse drivers allow you to define the wheel press to do something |
2314 |
libXt.a library. The real fix is to upgrade the various versions of |
different. Some drivers do not even have the option to generate a |
2315 |
unexec and/or ralloc. We think this has been fixed on Sunos 4 |
middle button press. In such cases, setting the wheel press to |
2316 |
and Solaris in version 19.29. |
"scroll" sometimes works if you press the button twice. Trying a |
2317 |
|
generic mouse driver might help. |
2318 |
|
|
2319 |
* `make install' fails on install-doc with `Error 141'. |
** Scrolling the mouse wheel on MS-Windows always scrolls the top window. |
2320 |
|
|
2321 |
This happens on Ultrix 4.2 due to failure of a pipeline of tar |
This is another common problem with mouse drivers. Instead of |
2322 |
commands. We don't know why they fail, but the bug seems not to be in |
generating scroll events, some mouse drivers try to fake scroll bar |
2323 |
Emacs. The workaround is to run the shell command in install-doc by |
movement. But they are not intelligent enough to handle multiple |
2324 |
hand. |
scroll bars within a frame. Trying a generic mouse driver might help. |
2325 |
|
|
2326 |
* --with-x-toolkit option configures wrong on BSD/386. |
** Mail sent through Microsoft Exchange in some encodings appears to be |
2327 |
|
mangled and is not seen correctly in Rmail or Gnus. We don't know |
2328 |
|
exactly what happens, but it isn't an Emacs problem in cases we've |
2329 |
|
seen. |
2330 |
|
|
2331 |
This problem is due to bugs in the shell in version 1.0 of BSD/386. |
** On MS-Windows, you cannot use the right-hand ALT key and the left-hand |
2332 |
The workaround is to edit the configure file to use some other shell, |
CTRL key together to type a Control-Meta character. |
|
such as bash. |
|
2333 |
|
|
2334 |
* Subprocesses remain, hanging but not zombies, on Sunos 5.3. |
This is a consequence of a misfeature beyond Emacs's control. |
2335 |
|
|
2336 |
A bug in Sunos 5.3 causes Emacs subprocesses to remain after Emacs |
Under Windows, the AltGr key on international keyboards generates key |
2337 |
exits. Sun patch # 101415-02 is part of the fix for this, but it only |
events with the modifiers Right-Alt and Left-Ctrl. Since Emacs cannot |
2338 |
applies to ptys, and doesn't fix the problem with subprocesses |
distinguish AltGr from an explicit Right-Alt and Left-Ctrl |
2339 |
communicating through pipes. |
combination, whenever it sees Right-Alt and Left-Ctrl it assumes that |
2340 |
|
AltGr has been pressed. The variable `w32-recognize-altgr' can be set |
2341 |
|
to nil to tell Emacs that AltGr is really Ctrl and Alt. |
2342 |
|
|
2343 |
* Mail is lost when sent to local aliases. |
** Under some X-servers running on MS-Windows, Emacs' display is incorrect. |
2344 |
|
|
2345 |
Many emacs mail user agents (VM and rmail, for instance) use the |
The symptoms are that Emacs does not completely erase blank areas of the |
2346 |
sendmail.el library. This library can arrange for mail to be |
screen during scrolling or some other screen operations (e.g., selective |
2347 |
delivered by passing messages to the /usr/lib/sendmail (usually) |
display or when killing a region). M-x recenter will cause the screen |
2348 |
program . In doing so, it passes the '-t' flag to sendmail, which |
to be completely redisplayed and the "extra" characters will disappear. |
|
means that the name of the recipient of the message is not on the |
|
|
command line and, therefore, that sendmail must parse the message to |
|
|
obtain the destination address. |
|
2349 |
|
|
2350 |
There is a bug in the SunOS4.1.1 and SunOS4.1.3 versions of sendmail. |
This is known to occur under Exceed 6, and possibly earlier versions |
2351 |
In short, when given the -t flag, the SunOS sendmail won't recognize |
as well; it is reportedly solved in version 6.2.0.16 and later. The |
2352 |
non-local (i.e. NIS) aliases. It has been reported that the Solaris |
problem lies in the X-server settings. |
|
2.x versions of sendmail do not have this bug. For those using SunOS |
|
|
4.1, the best fix is to install sendmail V8 or IDA sendmail (which |
|
|
have other advantages over the regular sendmail as well). At the time |
|
|
of this writing, these official versions are available: |
|
2353 |
|
|
2354 |
Sendmail V8 on ftp.cs.berkeley.edu in /ucb/sendmail: |
There are reports that you can solve the problem with Exceed by |
2355 |
sendmail.8.6.9.base.tar.Z (the base system source & documentation) |
running `Xconfig' from within NT, choosing "X selection", then |
2356 |
sendmail.8.6.9.cf.tar.Z (configuration files) |
un-checking the boxes "auto-copy X selection" and "auto-paste to X |
2357 |
sendmail.8.6.9.misc.tar.Z (miscellaneous support programs) |
selection". |
|
sendmail.8.6.9.xdoc.tar.Z (extended documentation, with postscript) |
|
2358 |
|
|
2359 |
IDA sendmail on vixen.cso.uiuc.edu in /pub: |
Of this does not work, please inform bug-gnu-emacs@gnu.org. Then |
2360 |
sendmail-5.67b+IDA-1.5.tar.gz |
please call support for your X-server and see if you can get a fix. |
2361 |
|
If you do, please send it to bug-gnu-emacs@gnu.org so we can list it |
2362 |
|
here. |
2363 |
|
|
2364 |
* On AIX, you get this message when running Emacs: |
* Build-time problems |
2365 |
|
|
2366 |
Could not load program emacs |
** Configuration |
|
Symbol smtcheckinit in csh is undefined |
|
|
Error was: Exec format error |
|
2367 |
|
|
2368 |
or this one: |
*** The `configure' script doesn't find the jpeg library. |
2369 |
|
|
2370 |
Could not load program .emacs |
There are reports that this happens on some systems because the linker |
2371 |
Symbol _system_con in csh is undefined |
by default only looks for shared libraries, but jpeg distribution by |
2372 |
Symbol _fp_trapsta in csh is undefined |
default only installs a nonshared version of the library, `libjpeg.a'. |
|
Error was: Exec format error |
|
2373 |
|
|
2374 |
These can happen when you try to run on AIX 3.2.5 a program that was |
If this is the problem, you can configure the jpeg library with the |
2375 |
compiled with 3.2.4. The fix is to recompile. |
`--enable-shared' option and then rebuild libjpeg. This produces a |
2376 |
|
shared version of libjpeg, which you need to install. Finally, rerun |
2377 |
|
the Emacs configure script, which should now find the jpeg library. |
2378 |
|
Alternatively, modify the generated src/Makefile to link the .a file |
2379 |
|
explicitly, and edit src/config.h to define HAVE_JPEG. |
2380 |
|
|
2381 |
* On AIX, you get this compiler error message: |
*** AIX: You get this compiler error message: |
2382 |
|
|
2383 |
Processing include file ./XMenuInt.h |
Processing include file ./XMenuInt.h |
2384 |
1501-106: (S) Include file X11/Xlib.h not found. |
1501-106: (S) Include file X11/Xlib.h not found. |
2387 |
libraries. You have to find your sipo (bootable tape) and install |
libraries. You have to find your sipo (bootable tape) and install |
2388 |
X11Dev... with smit. |
X11Dev... with smit. |
2389 |
|
|
2390 |
* You "lose characters" after typing Compose Character key. |
** Compilation |
|
|
|
|
This is because the Compose Character key is defined as the keysym |
|
|
Multi_key, and Emacs (seeing that) does the proper X11 |
|
|
character-composition processing. If you don't want your Compose key |
|
|
to do that, you can redefine it with xmodmap. |
|
|
|
|
|
For example, here's one way to turn it into a Meta key: |
|
|
|
|
|
xmodmap -e "keysym Multi_key = Meta_L" |
|
|
|
|
|
If all users at your site of a particular keyboard prefer Meta to |
|
|
Compose, you can make the remapping happen automatically by adding the |
|
|
xmodmap command to the xdm setup script for that display. |
|
|
|
|
|
* C-z just refreshes the screen instead of suspending Emacs. |
|
|
|
|
|
You are probably using a shell that doesn't support job control, even |
|
|
though the system itself is capable of it. Either use a different shell, |
|
|
or set the variable `cannot-suspend' to a non-nil value. |
|
|
|
|
|
* Watch out for .emacs files and EMACSLOADPATH environment vars |
|
|
|
|
|
These control the actions of Emacs. |
|
|
~/.emacs is your Emacs init file. |
|
|
EMACSLOADPATH overrides which directories the function |
|
|
"load" will search. |
|
|
|
|
|
If you observe strange problems, check for these and get rid |
|
|
of them, then try again. |
|
|
|
|
|
* After running emacs once, subsequent invocations crash. |
|
|
|
|
|
Some versions of SVR4 have a serious bug in the implementation of the |
|
|
mmap () system call in the kernel; this causes emacs to run correctly |
|
|
the first time, and then crash when run a second time. |
|
|
|
|
|
Contact your vendor and ask for the mmap bug fix; in the mean time, |
|
|
you may be able to work around the problem by adding a line to your |
|
|
operating system description file (whose name is reported by the |
|
|
configure script) that reads: |
|
|
#define SYSTEM_MALLOC |
|
|
This makes Emacs use memory less efficiently, but seems to work around |
|
|
the kernel bug. |
|
|
|
|
|
* Inability to send an Alt-modified key, when Emacs is communicating |
|
|
directly with an X server. |
|
|
|
|
|
If you have tried to bind an Alt-modified key as a command, and it |
|
|
does not work to type the command, the first thing you should check is |
|
|
whether the key is getting through to Emacs. To do this, type C-h c |
|
|
followed by the Alt-modified key. C-h c should say what kind of event |
|
|
it read. If it says it read an Alt-modified key, then make sure you |
|
|
have made the key binding correctly. |
|
|
|
|
|
If C-h c reports an event that doesn't have the Alt modifier, it may |
|
|
be because your X server has no key for the Alt modifier. The X |
|
|
server that comes from MIT does not set up the Alt modifier by |
|
|
default. |
|
2391 |
|
|
2392 |
If your keyboard has keys named Alt, you can enable them as follows: |
*** Building Emacs over NFS fails with ``Text file busy''. |
|
|
|
|
xmodmap -e 'add mod2 = Alt_L' |
|
|
xmodmap -e 'add mod2 = Alt_R' |
|
|
|
|
|
If the keyboard has just one key named Alt, then only one of those |
|
|
commands is needed. The modifier `mod2' is a reasonable choice if you |
|
|
are using an unmodified MIT version of X. Otherwise, choose any |
|
|
modifier bit not otherwise used. |
|
2393 |
|
|
2394 |
If your keyboard does not have keys named Alt, you can use some other |
This was reported to happen when building Emacs on a GNU/Linux system |
2395 |
keys. Use the keysym command in xmodmap to turn a function key (or |
(RedHat Linux 6.2) using a build directory automounted from Solaris |
2396 |
some other 'spare' key) into Alt_L or into Alt_R, and then use the |
(SunOS 5.6) file server, but it might not be limited to that |
2397 |
commands show above to make them modifier keys. |
configuration alone. Presumably, the NFS server doesn't commit the |
2398 |
|
files' data to disk quickly enough, and the Emacs executable file is |
2399 |
Note that if you have Alt keys but no Meta keys, Emacs translates Alt |
left ``busy'' for several seconds after Emacs has finished dumping |
2400 |
into Meta. This is because of the great importance of Meta in Emacs. |
itself. This causes the subsequent commands which invoke the dumped |
2401 |
|
Emacs executable to fail with the above message. |
|
* `Pid xxx killed due to text modification or page I/O error' |
|
|
|
|
|
On HP/UX, you can get that error when the Emacs executable is on an NFS |
|
|
file system. HP/UX responds this way if it tries to swap in a page and |
|
|
does not get a response from the server within a timeout whose default |
|
|
value is just ten seconds. |
|
|
|
|
|
If this happens to you, extend the timeout period. |
|
2402 |
|
|
2403 |
* `expand-file-name' fails to work on any but the machine you dumped Emacs on. |
In some of these cases, a time skew between the NFS server and the |
2404 |
|
machine where Emacs is built is detected and reported by GNU Make |
2405 |
|
(it says that some of the files have modification time in the future). |
2406 |
|
This might be a symptom of NFS-related problems. |
2407 |
|
|
2408 |
On Ultrix, if you use any of the functions which look up information |
If the NFS server runs on Solaris, apply the Solaris patch 105379-05 |
2409 |
in the passwd database before dumping Emacs (say, by using |
(Sunos 5.6: /kernel/misc/nfssrv patch). If that doesn't work, or if |
2410 |
expand-file-name in site-init.el), then those functions will not work |
you have a different version of the OS or the NFS server, you can |
2411 |
in the dumped Emacs on any host but the one Emacs was dumped on. |
force the NFS server to use 1KB blocks, which was reported to fix the |
2412 |
|
problem albeit at a price of slowing down file I/O. You can force 1KB |
2413 |
|
blocks by specifying the "-o rsize=1024,wsize=1024" options to the |
2414 |
|
`mount' command, or by adding ",rsize=1024,wsize=1024" to the mount |
2415 |
|
options in the appropriate system configuration file, such as |
2416 |
|
`/etc/auto.home'. |
2417 |
|
|
2418 |
The solution? Don't use expand-file-name in site-init.el, or in |
Alternatively, when Make fails due to this problem, you could wait for |
2419 |
anything it loads. Yuck - some solution. |
a few seconds and then invoke Make again. In one particular case, |
2420 |
|
waiting for 10 or more seconds between the two Make invocations seemed |
2421 |
|
to work around the problem. |
2422 |
|
|
2423 |
I'm not sure why this happens; if you can find out exactly what is |
Similar problems can happen if your machine NFS-mounts a directory |
2424 |
going on, and perhaps find a fix or a workaround, please let us know. |
onto itself. Suppose the Emacs sources live in `/usr/local/src' and |
2425 |
Perhaps the YP functions cache some information, the cache is included |
you are working on the host called `marvin'. Then an entry in the |
2426 |
in the dumped Emacs, and is then inaccurate on any other host. |
`/etc/fstab' file like the following is asking for trouble: |
2427 |
|
|
2428 |
* On some variants of SVR4, Emacs does not work at all with X. |
marvin:/usr/local/src /usr/local/src ...options.omitted... |
2429 |
|
|
2430 |
Try defining BROKEN_FIONREAD in your config.h file. If this solves |
The solution is to remove this line from `etc/fstab'. |
|
the problem, please send a bug report to tell us this is needed; be |
|
|
sure to say exactly what type of machine and system you are using. |
|
2431 |
|
|
2432 |
* Linking says that the functions insque and remque are undefined. |
*** Building Emacs with GCC 2.9x fails in the `src' directory. |
2433 |
|
|
2434 |
Change oldXMenu/Makefile by adding insque.o to the variable OBJS. |
This may happen if you use a development version of GNU `cpp' from one |
2435 |
|
of the GCC snapshots between Oct 2000 and Feb 2001, or from a released |
2436 |
|
version of GCC newer than 2.95.2 which was prepared around those |
2437 |
|
dates; similar problems were reported with some snapshots of GCC 3.1 |
2438 |
|
around Sep 30 2001. The preprocessor in those versions is |
2439 |
|
incompatible with a traditional Unix cpp (e.g., it expands ".." into |
2440 |
|
". .", which breaks relative file names that reference the parent |
2441 |
|
directory; or inserts TAB characters before lines that set Make |
2442 |
|
variables). |
2443 |
|
|
2444 |
* Emacs fails to understand most Internet host names, even though |
The solution is to make sure the preprocessor is run with the |
2445 |
the names work properly with other programs on the same system. |
`-traditional' option. The `configure' script does that automatically |
2446 |
* Emacs won't work with X-windows if the value of DISPLAY is HOSTNAME:0. |
when it detects the known problems in your cpp, but you might hit some |
2447 |
* GNUs can't make contact with the specified host for nntp. |
unknown ones. To force the `configure' script to use `-traditional', |
2448 |
|
run the script like this: |
2449 |
|
|
2450 |
This typically happens on Suns and other systems that use shared |
CPP='gcc -E -traditional' ./configure ... |
|
libraries. The cause is that the site has installed a version of the |
|
|
shared library which uses a name server--but has not installed a |
|
|
similar version of the unshared library which Emacs uses. |
|
2451 |
|
|
2452 |
The result is that most programs, using the shared library, work with |
(replace the ellipsis "..." with any additional arguments you pass to |
2453 |
the nameserver, but Emacs does not. |
the script). |
2454 |
|
|
2455 |
The fix is to install an unshared library that corresponds to what you |
Note that this problem does not pertain to the MS-Windows port of |
2456 |
installed in the shared library, and then relink Emacs. |
Emacs, since it doesn't use the preprocessor to generate Makefiles. |
2457 |
|
|
2458 |
On SunOS 4.1, simply define HAVE_RES_INIT. |
*** src/Makefile and lib-src/Makefile are truncated--most of the file missing. |
2459 |
|
*** Compiling wakeup, in lib-src, says it can't make wakeup.c. |
2460 |
|
|
2461 |
If you have already installed the name resolver in the file libresolv.a, |
This can happen if configure uses GNU sed version 2.03. That version |
2462 |
then you need to compile Emacs to use that library. The easiest way to |
had a bug. GNU sed version 2.05 works properly.To solve the |
2463 |
do this is to add to config.h a definition of LIBS_SYSTEM, LIBS_MACHINE |
problem, install the current version of GNU Sed, then rerun Emacs's |
2464 |
or LIB_STANDARD which uses -lresolv. Watch out! If you redefine a macro |
configure script. |
|
that is already in use in your configuration to supply some other libraries, |
|
|
be careful not to lose the others. |
|
2465 |
|
|
2466 |
Thus, you could start by adding this to config.h: |
*** Compiling lib-src says there is no rule to make test-distrib.c. |
2467 |
|
|
2468 |
#define LIBS_SYSTEM -lresolv |
This results from a bug in a VERY old version of GNU Sed. To solve |
2469 |
|
the problem, install the current version of GNU Sed, then rerun |
2470 |
|
Emacs's configure script. |
2471 |
|
|
2472 |
Then if this gives you an error for redefining a macro, and you see that |
*** Building the MS-Windows port with Cygwin GCC can fail. |
|
the s- file defines LIBS_SYSTEM as -lfoo -lbar, you could change config.h |
|
|
again to say this: |
|
2473 |
|
|
2474 |
#define LIBS_SYSTEM -lresolv -lfoo -lbar |
Emacs may not build using recent Cygwin builds of GCC, such as Cygwin |
2475 |
|
version 1.1.8, using the default configure settings. It appears to be |
2476 |
|
necessary to specify the -mwin32 flag when compiling, and define |
2477 |
|
__MSVCRT__, like so: |
2478 |
|
|
2479 |
* On a Sun running SunOS 4.1.1, you get this error message from GNU ld: |
configure --with-gcc --cflags -mwin32 --cflags -D__MSVCRT__ |
2480 |
|
|
2481 |
/lib/libc.a(_Q_sub.o): Undefined symbol __Q_get_rp_rd referenced from text segment |
*** Building the MS-Windows port fails with a CreateProcess failure. |
2482 |
|
|
2483 |
The problem is in the Sun shared C library, not in GNU ld. |
Some versions of mingw32 make on some versions of Windows do not seem |
2484 |
|
to detect the shell correctly. Try "make SHELL=cmd.exe", or if that |
2485 |
|
fails, try running make from Cygwin bash instead. |
2486 |
|
|
2487 |
The solution is to install Patch-ID# 100267-03 from Sun. |
*** Building the MS-Windows port with Leim fails in the `leim' directory. |
2488 |
|
|
2489 |
* Self documentation messages are garbled. |
The error message might be something like this: |
2490 |
|
|
2491 |
This means that the file `etc/DOC-...' doesn't properly correspond |
Converting d:/emacs-21.3/leim/CXTERM-DIC/4Corner.tit to quail-package... |
2492 |
with the Emacs executable. Redumping Emacs and then installing the |
Invalid ENCODE: value in TIT dictionary |
2493 |
corresponding pair of files should fix the problem. |
NMAKE : fatal error U1077: '"../src/obj-spd/i386/emacs.exe"' : return code |
2494 |
|
'0xffffffff' |
2495 |
|
Stop. |
2496 |
|
|
2497 |
* Trouble using ptys on AIX. |
This can happen if the Leim distribution is unpacked with a program |
2498 |
|
which converts the `*.tit' files to DOS-style CR-LF text format. The |
2499 |
|
`*.tit' files in the leim/CXTERM-DIC directory require Unix-style line |
2500 |
|
endings to compile properly, because Emacs reads them without any code |
2501 |
|
or EOL conversions. |
2502 |
|
|
2503 |
People often install the pty devices on AIX incorrectly. |
The solution is to make sure the program used to unpack Leim does not |
2504 |
Use `smit pty' to reinstall them properly. |
change the files' line endings behind your back. The GNU FTP site has |
2505 |
|
in the `/gnu/emacs/windows' directory a program called `djtarnt.exe' |
2506 |
|
which can be used to unpack `.tar.gz' and `.zip' archives without |
2507 |
|
mangling them. |
2508 |
|
|
2509 |
* Shell mode on HP/UX gives the message, "`tty`: Ambiguous". |
*** Building `ctags' for MS-Windows with the MinGW port of GCC fails. |
2510 |
|
|
2511 |
christos@theory.tn.cornell.edu says: |
This might happen due to a bug in the MinGW header assert.h, which |
2512 |
|
defines the `assert' macro with a trailing semi-colon. The following |
2513 |
|
patch to assert.h should solve this: |
2514 |
|
|
2515 |
The problem is that in your .cshrc you have something that tries to |
*** include/assert.h.orig Sun Nov 7 02:41:36 1999 |
2516 |
execute `tty`. If you are not running the shell on a real tty then |
--- include/assert.h Mon Jan 29 11:49:10 2001 |
2517 |
tty will print "not a tty". Csh expects one word in some places, |
*************** |
2518 |
but tty is giving it back 3. |
*** 41,47 **** |
2519 |
|
/* |
2520 |
|
* If not debugging, assert does nothing. |
2521 |
|
*/ |
2522 |
|
! #define assert(x) ((void)0); |
2523 |
|
|
2524 |
The solution is to add a pair of quotes around `tty` to make it a single |
#else /* debugging enabled */ |
|
word: |
|
2525 |
|
|
2526 |
if (`tty` == "/dev/console") |
--- 41,47 ---- |
2527 |
|
/* |
2528 |
|
* If not debugging, assert does nothing. |
2529 |
|
*/ |
2530 |
|
! #define assert(x) ((void)0) |
2531 |
|
|
2532 |
should be changed to: |
#else /* debugging enabled */ |
2533 |
|
|
|
if ("`tty`" == "/dev/console") |
|
2534 |
|
|
2535 |
Even better, move things that set up terminal sections out of .cshrc |
** Linking |
|
and into .login. |
|
2536 |
|
|
2537 |
* Using X Windows, control-shift-leftbutton makes Emacs hang. |
*** Building Emacs with a system compiler fails to link because of an |
2538 |
|
undefined symbol such as __eprintf which does not appear in Emacs. |
2539 |
|
|
2540 |
Use the shell command `xset bc' to make the old X Menu package work. |
This can happen if some of the libraries linked into Emacs were built |
2541 |
|
with GCC, but Emacs itself is being linked with a compiler other than |
2542 |
|
GCC. Object files compiled with GCC might need some helper functions |
2543 |
|
from libgcc.a, the library which comes with GCC, but the system |
2544 |
|
compiler does not instruct the linker to search libgcc.a during the |
2545 |
|
link stage. |
2546 |
|
|
2547 |
* Emacs running under X Windows does not handle mouse clicks. |
A solution is to link with GCC, like this: |
|
* `emacs -geometry 80x20' finds a file named `80x20'. |
|
2548 |
|
|
2549 |
One cause of such problems is having (setq term-file-prefix nil) in |
make CC=gcc |
|
your .emacs file. Another cause is a bad value of EMACSLOADPATH in |
|
|
the environment. |
|
2550 |
|
|
2551 |
* Emacs gets error message from linker on Sun. |
Since the .o object files already exist, this will not recompile Emacs |
2552 |
|
with GCC, but just restart by trying again to link temacs. |
2553 |
|
|
2554 |
If the error message says that a symbol such as `f68881_used' or |
*** AIX 1.3 ptf 0013: Link failure. |
|
`ffpa_used' or `start_float' is undefined, this probably indicates |
|
|
that you have compiled some libraries, such as the X libraries, |
|
|
with a floating point option other than the default. |
|
2555 |
|
|
2556 |
It's not terribly hard to make this work with small changes in |
There is a real duplicate definition of the function `_slibc_free' in |
2557 |
crt0.c together with linking with Fcrt1.o, Wcrt1.o or Mcrt1.o. |
the library /lib/libc_s.a (just do nm on it to verify). The |
2558 |
However, the easiest approach is to build Xlib with the default |
workaround/fix is: |
|
floating point option: -fsoft. |
|
2559 |
|
|
2560 |
* Emacs fails to get default settings from X Windows server. |
cd /lib |
2561 |
|
ar xv libc_s.a NLtmtime.o |
2562 |
|
ar dv libc_s.a NLtmtime.o |
2563 |
|
|
2564 |
The X library in X11R4 has a bug; it interchanges the 2nd and 3rd |
*** AIX 4.1.2: Linker error messages such as |
2565 |
arguments to XGetDefaults. Define the macro XBACKWARDS in config.h to |
ld: 0711-212 SEVERE ERROR: Symbol .__quous, found in the global symbol table |
2566 |
tell Emacs to compensate for this. |
of archive /usr/lib/libIM.a, was not defined in archive member shr.o. |
2567 |
|
|
2568 |
I don't believe there is any way Emacs can determine for itself |
This is a problem in libIM.a. You can work around it by executing |
2569 |
whether this problem is present on a given system. |
these shell commands in the src subdirectory of the directory where |
2570 |
|
you build Emacs: |
2571 |
|
|
2572 |
* Keyboard input gets confused after a beep when using a DECserver |
cp /usr/lib/libIM.a . |
2573 |
as a concentrator. |
chmod 664 libIM.a |
2574 |
|
ranlib libIM.a |
2575 |
|
|
2576 |
This problem seems to be a matter of configuring the DECserver to use |
Then change -lIM to ./libIM.a in the command to link temacs (in |
2577 |
7 bit characters rather than 8 bit characters. |
Makefile). |
2578 |
|
|
2579 |
* M-x shell persistently reports "Process shell exited abnormally with code 1". |
*** Sun with acc: Link failure when using acc on a Sun. |
2580 |
|
|
2581 |
This happened on Suns as a result of what is said to be a bug in Sunos |
To use acc, you need additional options just before the libraries, such as |
|
version 4.0.x. The only fix was to reboot the machine. |
|
2582 |
|
|
2583 |
* Programs running under terminal emulator do not recognize `emacs' |
/usr/lang/SC2.0.1/values-Xt.o -L/usr/lang/SC2.0.1/cg87 -L/usr/lang/SC2.0.1 |
|
terminal type. |
|
2584 |
|
|
2585 |
The cause of this is a shell startup file that sets the TERMCAP |
and you need to add -lansi just before -lc. |
|
environment variable. The terminal emulator uses that variable to |
|
|
provide the information on the special terminal type that Emacs |
|
|
emulates. |
|
2586 |
|
|
2587 |
Rewrite your shell startup file so that it does not change TERMCAP |
The precise file names depend on the compiler version, so we |
2588 |
in such a case. You could use the following conditional which sets |
cannot easily arrange to supply them. |
|
it only if it is undefined. |
|
2589 |
|
|
2590 |
if ( ! ${?TERMCAP} ) setenv TERMCAP ~/my-termcap-file |
*** Linking says that the functions insque and remque are undefined. |
2591 |
|
|
2592 |
Or you could set TERMCAP only when you set TERM--which should not |
Change oldXMenu/Makefile by adding insque.o to the variable OBJS. |
|
happen in a non-login shell. |
|
2593 |
|
|
2594 |
* X Windows doesn't work if DISPLAY uses a hostname. |
*** `tparam' reported as a multiply-defined symbol when linking with ncurses. |
2595 |
|
|
2596 |
People have reported kernel bugs in certain systems that cause Emacs |
This problem results from an incompatible change in ncurses, in |
2597 |
not to work with X Windows if DISPLAY is set using a host name. But |
version 1.9.9e approximately. This version is unable to provide a |
2598 |
the problem does not occur if DISPLAY is set to `unix:0.0'. I think |
definition of tparm without also defining tparam. This is also |
2599 |
the bug has to do with SIGIO or FIONREAD. |
incompatible with Terminfo; as a result, the Emacs Terminfo support |
2600 |
|
does not work with this version of ncurses. |
2601 |
|
|
2602 |
You may be able to compensate for the bug by doing (set-input-mode nil nil). |
The fix is to install a newer version of ncurses, such as version 4.2. |
|
However, that has the disadvantage of turning off interrupts, so that |
|
|
you are unable to quit out of a Lisp program by typing C-g. |
|
2603 |
|
|
2604 |
The easy way to do this is to put |
** Dumping |
2605 |
|
|
2606 |
(setq x-sigio-bug t) |
*** Linux: Segfault during `make bootstrap' under certain recent versions of the Linux kernel. |
2607 |
|
|
2608 |
in your site-init.el file. |
With certain recent Linux kernels (like the one of Redhat Fedora Core |
2609 |
|
1), the new "Exec-shield" functionality is enabled by default, which |
2610 |
|
creates a different memory layout that breaks the emacs dumper. |
2611 |
|
|
2612 |
* Problem with remote X server on Suns. |
You can check the Exec-shield state like this: |
2613 |
|
|
2614 |
On a Sun, running Emacs on one machine with the X server on another |
cat /proc/sys/kernel/exec-shield |
|
may not work if you have used the unshared system libraries. This |
|
|
is because the unshared libraries fail to use YP for host name lookup. |
|
|
As a result, the host name you specify may not be recognized. |
|
2615 |
|
|
2616 |
* Shell mode ignores interrupts on Apollo Domain |
It returns 1 or 2 when Exec-shield is enabled, 0 otherwise. Please |
2617 |
|
read your system documentation for more details on Exec-shield and |
2618 |
|
associated commands. |
2619 |
|
|
2620 |
You may find that M-x shell prints the following message: |
When Exec-shield is enabled, building Emacs will segfault during the |
2621 |
|
execution of this command: |
2622 |
|
|
2623 |
Warning: no access to tty; thus no job control in this shell... |
temacs --batch --load loadup [dump|bootstrap] |
2624 |
|
|
2625 |
This can happen if there are not enough ptys on your system. |
To work around this problem, it is necessary to temporarily disable |
2626 |
Here is how to make more of them. |
Exec-shield while building Emacs, using the `setarch' command like |
2627 |
|
this: |
2628 |
|
|
2629 |
% cd /dev |
setarch i386 ./configure <configure parameters> |
2630 |
% ls pty* |
setarch i386 make <make parameters> |
|
# shows how many pty's you have. I had 8, named pty0 to pty7) |
|
|
% /etc/crpty 8 |
|
|
# creates eight new pty's |
|
2631 |
|
|
2632 |
* Fatal signal in the command temacs -l loadup inc dump |
*** Fatal signal in the command temacs -l loadup inc dump. |
2633 |
|
|
2634 |
This command is the final stage of building Emacs. It is run by the |
This command is the final stage of building Emacs. It is run by the |
2635 |
Makefile in the src subdirectory, or by build.com on VMS. |
Makefile in the src subdirectory, or by build.com on VMS. |
2637 |
It has been known to get fatal errors due to insufficient swapping |
It has been known to get fatal errors due to insufficient swapping |
2638 |
space available on the machine. |
space available on the machine. |
2639 |
|
|
2640 |
On 68000's, it has also happened because of bugs in the |
On 68000s, it has also happened because of bugs in the |
2641 |
subroutine `alloca'. Verify that `alloca' works right, even |
subroutine `alloca'. Verify that `alloca' works right, even |
2642 |
for large blocks (many pages). |
for large blocks (many pages). |
2643 |
|
|
2644 |
* test-distrib says that the distribution has been clobbered |
*** test-distrib says that the distribution has been clobbered. |
2645 |
* or, temacs prints "Command key out of range 0-127" |
*** or, temacs prints "Command key out of range 0-127". |
2646 |
* or, temacs runs and dumps emacs, but emacs totally fails to work. |
*** or, temacs runs and dumps emacs, but emacs totally fails to work. |
2647 |
* or, temacs gets errors dumping emacs |
*** or, temacs gets errors dumping emacs. |
2648 |
|
|
2649 |
This can be because the .elc files have been garbled. Do not be |
This can be because the .elc files have been garbled. Do not be |
2650 |
fooled by the fact that most of a .elc file is text: these are |
fooled by the fact that most of a .elc file is text: these are |
2677 |
and remake temacs. |
and remake temacs. |
2678 |
7) Remake emacs. It should work now, with valid .elc files. |
7) Remake emacs. It should work now, with valid .elc files. |
2679 |
|
|
2680 |
* temacs prints "Pure Lisp storage exhausted" |
*** temacs prints "Pure Lisp storage exhausted". |
2681 |
|
|
2682 |
This means that the Lisp code loaded from the .elc and .el |
This means that the Lisp code loaded from the .elc and .el |
2683 |
files during temacs -l loadup inc dump took up more |
files during temacs -l loadup inc dump took up more |
2706 |
of something else that is wrong. Be sure to check and fix the real |
of something else that is wrong. Be sure to check and fix the real |
2707 |
problem. |
problem. |
2708 |
|
|
2709 |
* Changes made to .el files do not take effect. |
*** Linux: Emacs crashes when dumping itself on Mac PPC running Yellow Dog GNU/Linux. |
2710 |
|
|
2711 |
You may have forgotten to recompile them into .elc files. |
The crashes happen inside the function Fmake_symbol; here's a typical |
2712 |
Then the old .elc files will be loaded, and your changes |
C backtrace printed by GDB: |
|
will not be seen. To fix this, do M-x byte-recompile-directory |
|
|
and specify the directory that contains the Lisp files. |
|
2713 |
|
|
2714 |
Emacs should print a warning when loading a .elc file which is older |
0x190c0c0 in Fmake_symbol () |
2715 |
than the corresponding .el file. |
(gdb) where |
2716 |
|
#0 0x190c0c0 in Fmake_symbol () |
2717 |
|
#1 0x1942ca4 in init_obarray () |
2718 |
|
#2 0x18b3500 in main () |
2719 |
|
#3 0x114371c in __libc_start_main (argc=5, argv=0x7ffff5b4, envp=0x7ffff5cc, |
2720 |
|
|
2721 |
|
This could happen because GCC version 2.95 and later changed the base |
2722 |
|
of the load address to 0x10000000. Emacs needs to be told about this, |
2723 |
|
but we currently cannot do that automatically, because that breaks |
2724 |
|
other versions of GNU/Linux on the MacPPC. Until we find a way to |
2725 |
|
distinguish between the Yellow Dog and the other varieties of |
2726 |
|
GNU/Linux systems on the PPC, you will have to manually uncomment the |
2727 |
|
following section near the end of the file src/m/macppc.h in the Emacs |
2728 |
|
distribution: |
2729 |
|
|
2730 |
|
#if 0 /* This breaks things on PPC GNU/Linux except for Yellowdog, |
2731 |
|
even with identical GCC, as, ld. Let's take it out until we |
2732 |
|
know what's really going on here. */ |
2733 |
|
/* GCC 2.95 and newer on GNU/Linux PPC changed the load address to |
2734 |
|
0x10000000. */ |
2735 |
|
#if defined __linux__ |
2736 |
|
#if __GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 95) |
2737 |
|
#define DATA_SEG_BITS 0x10000000 |
2738 |
|
#endif |
2739 |
|
#endif |
2740 |
|
#endif /* 0 */ |
2741 |
|
|
2742 |
* The dumped Emacs crashes when run, trying to write pure data. |
Remove the "#if 0" and "#endif" directives which surround this, save |
2743 |
|
the file, and then reconfigure and rebuild Emacs. The dumping process |
2744 |
|
should now succeed. |
2745 |
|
|
2746 |
|
*** HPUX 10.20: Emacs crashes during dumping on the HPPA machine. |
2747 |
|
|
2748 |
|
This seems to be due to a GCC bug; it is fixed in GCC 2.8.1. |
2749 |
|
|
2750 |
|
** Installation |
2751 |
|
|
2752 |
|
*** Installing Emacs gets an error running `install-info'. |
2753 |
|
|
2754 |
|
You need to install a recent version of Texinfo; that package |
2755 |
|
supplies the `install-info' command. |
2756 |
|
|
2757 |
|
** First execution |
2758 |
|
|
2759 |
|
*** Emacs binary is not in executable format, and cannot be run. |
2760 |
|
|
2761 |
|
This was reported to happen when Emacs is built in a directory mounted |
2762 |
|
via NFS, for some combinations of NFS client and NFS server. |
2763 |
|
Usually, the file `emacs' produced in these cases is full of |
2764 |
|
binary null characters, and the `file' utility says: |
2765 |
|
|
2766 |
|
emacs: ASCII text, with no line terminators |
2767 |
|
|
2768 |
|
We don't know what exactly causes this failure. A work-around is to |
2769 |
|
build Emacs in a directory on a local disk. |
2770 |
|
|
2771 |
|
*** The dumped Emacs crashes when run, trying to write pure data. |
2772 |
|
|
2773 |
Two causes have been seen for such problems. |
Two causes have been seen for such problems. |
2774 |
|
|
2783 |
not initialized are not supposed to be pure. On these systems you |
not initialized are not supposed to be pure. On these systems you |
2784 |
may need to add "#define static" to the m- or the s- file. |
may need to add "#define static" to the m- or the s- file. |
2785 |
|
|
2786 |
* Compilation errors on VMS. |
* Emacs 19 problems |
2787 |
|
|
2788 |
You will get warnings when compiling on VMS because there are |
** Error messages `Wrong number of arguments: #<subr where-is-internal>, 5'. |
|
variable names longer than 32 (or whatever it is) characters. |
|
|
This is not an error. Ignore it. |
|
2789 |
|
|
2790 |
VAX C does not support #if defined(foo). Uses of this construct |
This typically results from having the powerkey library loaded. |
2791 |
were removed, but some may have crept back in. They must be rewritten. |
Powerkey was designed for Emacs 19.22. It is obsolete now because |
2792 |
|
Emacs 19 now has this feature built in; and powerkey also calls |
2793 |
|
where-is-internal in an obsolete way. |
2794 |
|
|
2795 |
There is a bug in the C compiler which fails to sign extend characters |
So the fix is to arrange not to load powerkey. |
|
in conditional expressions. The bug is: |
|
|
char c = -1, d = 1; |
|
|
int i; |
|
2796 |
|
|
2797 |
i = d ? c : d; |
* Runtime problems on legacy systems |
|
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. |
|
2798 |
|
|
2799 |
* rmail gets error getting new mail |
This section covers bugs reported on very old hardware or software. |
2800 |
|
If you are using hardware and an operating system shipped after 2000, |
2801 |
|
it is unlikely you will see any of these. |
2802 |
|
|
2803 |
rmail gets new mail from /usr/spool/mail/$USER using a program |
** Ancient operating systems |
|
called `movemail'. This program interlocks with /bin/mail using |
|
|
the protocol defined by /bin/mail. |
|
2804 |
|
|
2805 |
There are two different protocols in general use. One of them uses |
*** ISC Unix |
|
the `flock' system call. The other involves creating a lock file; |
|
|
`movemail' must be able to write in /usr/spool/mail in order to do |
|
|
this. You control which one is used by defining, or not defining, |
|
|
the macro MAIL_USE_FLOCK in config.h or the m- or s- file it includes. |
|
|
IF YOU DON'T USE THE FORM OF INTERLOCKING THAT IS NORMAL ON YOUR |
|
|
SYSTEM, YOU CAN LOSE MAIL! |
|
2806 |
|
|
2807 |
If your system uses the lock file protocol, and fascist restrictions |
**** ISC: display-time causes kernel problems on ISC systems. |
|
prevent ordinary users from writing the lock files in /usr/spool/mail, |
|
|
you may need to make `movemail' setgid to a suitable group such as |
|
|
`mail'. You can use these commands (as root): |
|
2808 |
|
|
2809 |
chgrp mail movemail |
Under Interactive Unix versions 3.0.1 and 4.0 (and probably other |
2810 |
chmod 2755 movemail |
versions), display-time causes the loss of large numbers of STREVENT |
2811 |
|
cells. Eventually the kernel's supply of these cells is exhausted. |
2812 |
|
This makes emacs and the whole system run slow, and can make other |
2813 |
|
processes die, in particular pcnfsd. |
2814 |
|
|
2815 |
If your system uses the lock file protocol, and fascist restrictions |
Other emacs functions that communicate with remote processes may have |
2816 |
prevent ordinary users from writing the lock files in /usr/spool/mail, |
the same problem. Display-time seems to be far the worst. |
|
you may need to make `movemail' setgid to a suitable group such as |
|
|
`mail'. To do this, use the following commands (as root) after doing the |
|
|
make install. |
|
2817 |
|
|
2818 |
chgrp mail movemail |
The only known fix: Don't run display-time. |
|
chmod 2755 movemail |
|
2819 |
|
|
2820 |
Installation normally copies movemail from the build directory to an |
*** SunOS |
|
installation directory which is usually under /usr/local/lib. The |
|
|
installed copy of movemail is usually in the directory |
|
|
/usr/local/lib/emacs/VERSION/TARGET. You must change the group and |
|
|
mode of the installed copy; changing the group and mode of the build |
|
|
directory copy is ineffective. |
|
2821 |
|
|
2822 |
* Emacs spontaneously displays "I-search: " at the bottom of the screen. |
**** Sun 4.0.x: M-x shell persistently reports "Process shell exited abnormally with code 1". |
2823 |
|
|
2824 |
This means that Control-S/Control-Q (XON/XOFF) "flow control" is being |
This happened on Suns as a result of what is said to be a bug in Sunos |
2825 |
used. C-s/C-q flow control is bad for Emacs editors because it takes |
version 4.0.x. The only fix was to reboot the machine. |
|
away C-s and C-q as user commands. Since editors do not output long |
|
|
streams of text without user commands, there is no need for a |
|
|
user-issuable "stop output" command in an editor; therefore, a |
|
|
properly designed flow control mechanism would transmit all possible |
|
|
input characters without interference. Designing such a mechanism is |
|
|
easy, for a person with at least half a brain. |
|
2826 |
|
|
2827 |
There are three possible reasons why flow control could be taking place: |
**** SunOS4.1.1 and SunOS4.1.3: Mail is lost when sent to local aliases. |
2828 |
|
|
2829 |
1) Terminal has not been told to disable flow control |
Many emacs mail user agents (VM and rmail, for instance) use the |
2830 |
2) Insufficient padding for the terminal in use |
sendmail.el library. This library can arrange for mail to be |
2831 |
3) Some sort of terminal concentrator or line switch is responsible |
delivered by passing messages to the /usr/lib/sendmail (usually) |
2832 |
|
program . In doing so, it passes the '-t' flag to sendmail, which |
2833 |
|
means that the name of the recipient of the message is not on the |
2834 |
|
command line and, therefore, that sendmail must parse the message to |
2835 |
|
obtain the destination address. |
2836 |
|
|
2837 |
First of all, many terminals have a set-up mode which controls whether |
There is a bug in the SunOS4.1.1 and SunOS4.1.3 versions of sendmail. |
2838 |
they generate XON/XOFF flow control characters. This must be set to |
In short, when given the -t flag, the SunOS sendmail won't recognize |
2839 |
"no XON/XOFF" in order for Emacs to work. Sometimes there is an |
non-local (i.e. NIS) aliases. It has been reported that the Solaris |
2840 |
escape sequence that the computer can send to turn flow control off |
2.x versions of sendmail do not have this bug. For those using SunOS |
2841 |
and on. If so, perhaps the termcap `ti' string should turn flow |
4.1, the best fix is to install sendmail V8 or IDA sendmail (which |
2842 |
control off, and the `te' string should turn it on. |
have other advantages over the regular sendmail as well). At the time |
2843 |
|
of this writing, these official versions are available: |
2844 |
|
|
2845 |
Once the terminal has been told "no flow control", you may find it |
Sendmail V8 on ftp.cs.berkeley.edu in /ucb/sendmail: |
2846 |
needs more padding. The amount of padding Emacs sends is controlled |
sendmail.8.6.9.base.tar.Z (the base system source & documentation) |
2847 |
by the termcap entry for the terminal in use, and by the output baud |
sendmail.8.6.9.cf.tar.Z (configuration files) |
2848 |
rate as known by the kernel. The shell command `stty' will print |
sendmail.8.6.9.misc.tar.Z (miscellaneous support programs) |
2849 |
your output baud rate; `stty' with suitable arguments will set it if |
sendmail.8.6.9.xdoc.tar.Z (extended documentation, with postscript) |
|
it is wrong. Setting to a higher speed causes increased padding. If |
|
|
the results are wrong for the correct speed, there is probably a |
|
|
problem in the termcap entry. You must speak to a local Unix wizard |
|
|
to fix this. Perhaps you are just using the wrong terminal type. |
|
2850 |
|
|
2851 |
For terminals that lack a "no flow control" mode, sometimes just |
IDA sendmail on vixen.cso.uiuc.edu in /pub: |
2852 |
giving lots of padding will prevent actual generation of flow control |
sendmail-5.67b+IDA-1.5.tar.gz |
|
codes. You might as well try it. |
|
2853 |
|
|
2854 |
If you are really unlucky, your terminal is connected to the computer |
**** Sunos 5.3: Subprocesses remain, hanging but not zombies. |
|
through a concentrator which sends XON/XOFF flow control to the |
|
|
computer, or it insists on sending flow control itself no matter how |
|
|
much padding you give it. Unless you can figure out how to turn flow |
|
|
control off on this concentrator (again, refer to your local wizard), |
|
|
you are screwed! You should have the terminal or concentrator |
|
|
replaced with a properly designed one. In the mean time, some drastic |
|
|
measures can make Emacs semi-work. |
|
2855 |
|
|
2856 |
You can make Emacs ignore C-s and C-q and let the operating system |
A bug in Sunos 5.3 causes Emacs subprocesses to remain after Emacs |
2857 |
handle them. To do this on a per-session basis, just type M-x |
exits. Sun patch # 101415-02 is part of the fix for this, but it only |
2858 |
enable-flow-control RET. You will see a message that C-\ and C-^ are |
applies to ptys, and doesn't fix the problem with subprocesses |
2859 |
now translated to C-s and C-q. (Use the same command M-x |
communicating through pipes. |
|
enable-flow-control to turn *off* this special mode. It toggles flow |
|
|
control handling.) |
|
2860 |
|
|
2861 |
If C-\ and C-^ are inconvenient for you (for example, if one of them |
**** Sunos 4: You get the error ld: Undefined symbol __lib_version. |
|
is the escape character of your terminal concentrator), you can choose |
|
|
other characters by setting the variables flow-control-c-s-replacement |
|
|
and flow-control-c-q-replacement. But choose carefully, since all |
|
|
other control characters are already used by emacs. |
|
2862 |
|
|
2863 |
IMPORTANT: if you type C-s by accident while flow control is enabled, |
This is the result of using cc or gcc with the shared library meant |
2864 |
Emacs output will freeze, and you will have to remember to type C-q in |
for acc (the Sunpro compiler). Check your LD_LIBRARY_PATH and delete |
2865 |
order to continue. |
/usr/lang/SC2.0.1 or some similar directory. |
2866 |
|
|
2867 |
If you work in an environment where a majority of terminals of a |
**** SunOS 4.1.3: Emacs unpredictably crashes in _yp_dobind_soft. |
|
certain type are flow control hobbled, you can use the function |
|
|
`enable-flow-control-on' to turn on this flow control avoidance scheme |
|
|
automatically. Here is an example: |
|
2868 |
|
|
2869 |
(enable-flow-control-on "vt200" "vt300" "vt101" "vt131") |
This happens if you configure Emacs specifying just `sparc-sun-sunos4' |
2870 |
|
on a system that is version 4.1.3. You must specify the precise |
2871 |
|
version number (or let configure figure out the configuration, which |
2872 |
|
it can do perfectly well for SunOS). |
2873 |
|
|
2874 |
If this isn't quite correct (e.g. you have a mixture of flow-control hobbled |
**** Sunos 4.1.3: Emacs gets hung shortly after startup. |
|
and good vt200 terminals), you can still run enable-flow-control |
|
|
manually. |
|
2875 |
|
|
2876 |
I have no intention of ever redesigning the Emacs command set for the |
We think this is due to a bug in Sunos. The word is that |
2877 |
assumption that terminals use C-s/C-q flow control. XON/XOFF flow |
one of these Sunos patches fixes the bug: |
|
control technique is a bad design, and terminals that need it are bad |
|
|
merchandise and should not be purchased. Now that X is becoming |
|
|
widespread, XON/XOFF seems to be on the way out. If you can get some |
|
|
use out of GNU Emacs on inferior terminals, more power to you, but I |
|
|
will not make Emacs worse for properly designed systems for the sake |
|
|
of inferior systems. |
|
2878 |
|
|
2879 |
* Control-S and Control-Q commands are ignored completely. |
100075-11 100224-06 100347-03 100482-05 100557-02 100623-03 100804-03 101080-01 |
2880 |
|
100103-12 100249-09 100496-02 100564-07 100630-02 100891-10 101134-01 |
2881 |
|
100170-09 100296-04 100377-09 100507-04 100567-04 100650-02 101070-01 101145-01 |
2882 |
|
100173-10 100305-15 100383-06 100513-04 100570-05 100689-01 101071-03 101200-02 |
2883 |
|
100178-09 100338-05 100421-03 100536-02 100584-05 100784-01 101072-01 101207-01 |
2884 |
|
|
2885 |
For some reason, your system is using brain-damaged C-s/C-q flow |
We don't know which of these patches really matter. If you find out |
2886 |
control despite Emacs's attempts to turn it off. Perhaps your |
which ones, please inform bug-gnu-emacs@gnu.org. |
|
terminal is connected to the computer through a concentrator |
|
|
that wants to use flow control. |
|
2887 |
|
|
2888 |
You should first try to tell the concentrator not to use flow control. |
**** SunOS 4: Emacs processes keep going after you kill the X server |
2889 |
If you succeed in this, try making the terminal work without |
(or log out, if you logged in using X). |
|
flow control, as described in the preceding section. |
|
2890 |
|
|
2891 |
If that line of approach is not successful, map some other characters |
Someone reported that recompiling with GCC 2.7.0 fixed this problem. |
|
into C-s and C-q using keyboard-translate-table. The example above |
|
|
shows how to do this with C-^ and C-\. |
|
2892 |
|
|
2893 |
* Control-S and Control-Q commands are ignored completely on a net connection. |
**** SunOS: You get linker errors |
2894 |
|
ld: Undefined symbol |
2895 |
|
_get_wmShellWidgetClass |
2896 |
|
_get_applicationShellWidgetClass |
2897 |
|
|
2898 |
Some versions of rlogin (and possibly telnet) do not pass flow |
The fix to this is to install patch 100573 for OpenWindows 3.0 |
2899 |
control characters to the remote system to which they connect. |
or link libXmu statically. |
|
On such systems, emacs on the remote system cannot disable flow |
|
|
control on the local system. |
|
2900 |
|
|
2901 |
One way to cure this is to disable flow control on the local host |
*** Apollo Domain |
|
(the one running rlogin, not the one running rlogind) using the |
|
|
stty command, before starting the rlogin process. On many systems, |
|
|
"stty start u stop u" will do this. |
|
2902 |
|
|
2903 |
Some versions of tcsh will prevent even this from working. One way |
**** Shell mode ignores interrupts on Apollo Domain. |
|
around this is to start another shell before starting rlogin, and |
|
|
issue the stty command to disable flow control from that shell. |
|
2904 |
|
|
2905 |
If none of these methods work, the best solution is to type |
You may find that M-x shell prints the following message: |
|
M-x enable-flow-control at the beginning of your emacs session, or |
|
|
if you expect the problem to continue, add a line such as the |
|
|
following to your .emacs (on the host running rlogind): |
|
2906 |
|
|
2907 |
(enable-flow-control-on "vt200" "vt300" "vt101" "vt131") |
Warning: no access to tty; thus no job control in this shell... |
2908 |
|
|
2909 |
See the entry about spontaneous display of I-search (above) for more |
This can happen if there are not enough ptys on your system. |
2910 |
info. |
Here is how to make more of them. |
2911 |
|
|
2912 |
* Screen is updated wrong, but only on one kind of terminal. |
% cd /dev |
2913 |
|
% ls pty* |
2914 |
|
# shows how many pty's you have. I had 8, named pty0 to pty7) |
2915 |
|
% /etc/crpty 8 |
2916 |
|
# creates eight new pty's |
2917 |
|
|
2918 |
This could mean that the termcap entry you are using for that |
*** Irix |
|
terminal is wrong, or it could mean that Emacs has a bug handing |
|
|
the combination of features specified for that terminal. |
|
2919 |
|
|
2920 |
The first step in tracking this down is to record what characters |
*** Irix 6.2: No visible display on mips-sgi-irix6.2 when compiling with GCC 2.8.1. |
|
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: |
|
2921 |
|
|
2922 |
1) The characters sent are correct, according to the terminal manual. |
This problem went away after installing the latest IRIX patches |
2923 |
|
as of 8 Dec 1998. |
2924 |
|
|
2925 |
In this case, there is no obvious bug in Emacs, and most likely you |
The same problem has been reported on Irix 6.3. |
|
need more padding, or possibly the terminal manual is wrong. |
|
2926 |
|
|
2927 |
2) The characters sent are incorrect, due to an obscure aspect |
*** Irix 6.3: substituting environment variables in file names |
2928 |
of the terminal behavior not described in an obvious way |
in the minibuffer gives peculiar error messages such as |
|
by termcap. |
|
2929 |
|
|
2930 |
This case is hard. It will be necessary to think of a way for |
Substituting nonexistent environment variable "" |
|
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. |
|
2931 |
|
|
2932 |
3) The termcap entry is wrong. |
This is not an Emacs bug; it is caused by something in SGI patch |
2933 |
|
003082 August 11, 1998. |
2934 |
|
|
2935 |
See the file etc/TERMS for information on changes |
*** OPENSTEP |
|
that are known to be needed in commonly used termcap entries |
|
|
for certain terminals. |
|
2936 |
|
|
2937 |
4) The characters sent are incorrect, and clearly cannot be |
**** OPENSTEP 4.2: Compiling syntax.c with gcc 2.7.2.1 fails. |
|
right for any terminal with the termcap entry you were using. |
|
2938 |
|
|
2939 |
This is unambiguously an Emacs bug, and can probably be fixed |
The compiler was reported to crash while compiling syntax.c with the |
2940 |
in termcap.c, tparam.c, term.c, scroll.c, cm.c or dispnew.c. |
following message: |
2941 |
|
|
2942 |
* Output from Control-V is slow. |
cc: Internal compiler error: program cc1obj got fatal signal 11 |
2943 |
|
|
2944 |
On many bit-map terminals, scrolling operations are fairly slow. |
To work around this, replace the macros UPDATE_SYNTAX_TABLE_FORWARD, |
2945 |
Often the termcap entry for the type of terminal in use fails |
INC_BOTH, and INC_FROM with functions. To this end, first define 3 |
2946 |
to inform Emacs of this. The two lines at the bottom of the screen |
functions, one each for every macro. Here's an example: |
|
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. |
|
2947 |
|
|
2948 |
If scrolling is slow but Emacs thinks it is fast, the usual reason is |
static int update_syntax_table_forward(int from) |
2949 |
that the termcap entry for the terminal you are using does not |
{ |
2950 |
specify any padding time for the `al' and `dl' strings. Emacs |
return(UPDATE_SYNTAX_TABLE_FORWARD(from)); |
2951 |
concludes that these operations take only as much time as it takes to |
}/*update_syntax_table_forward*/ |
|
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. |
|
2952 |
|
|
2953 |
Currently Emacs thinks in terms of serial lines which send characters |
Then replace all references to UPDATE_SYNTAX_TABLE_FORWARD in syntax.c |
2954 |
at a fixed rate, so that any operation which takes time for the |
with a call to the function update_syntax_table_forward. |
|
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. |
|
2955 |
|
|
2956 |
Most bit-map terminals provide commands for inserting or deleting |
*** Solaris 2.x |
|
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. |
|
2957 |
|
|
2958 |
You should also define the `IC' and `DC' strings if your terminal |
**** Strange results from format %d in a few cases, on a Sun. |
|
has a command to insert or delete multiple characters. These |
|
|
take the number of positions to insert or delete as an argument. |
|
2959 |
|
|
2960 |
A `cs' string to set the scrolling region will reduce the amount |
Sun compiler version SC3.0 has been found to miscompile part of |
2961 |
of motion you see on the screen when part of the screen is scrolled. |
editfns.c. The workaround is to compile with some other compiler such |
2962 |
|
as GCC. |
2963 |
|
|
2964 |
* Your Delete key sends a Backspace to the terminal, using an AIXterm. |
**** On Solaris, Emacs dumps core if lisp-complete-symbol is called. |
2965 |
|
|
2966 |
The solution is to include in your .Xdefaults the lines: |
If you compile Emacs with the -fast or -xO4 option with version 3.0.2 |
2967 |
|
of the Sun C compiler, Emacs dumps core when lisp-complete-symbol is |
2968 |
|
called. The problem does not happen if you compile with GCC. |
2969 |
|
|
2970 |
*aixterm.Translations: #override <Key>BackSpace: string(0x7f) |
**** On Solaris, Emacs crashes if you use (display-time). |
|
aixterm*ttyModes: erase ^? |
|
2971 |
|
|
2972 |
This makes your Backspace key send DEL (ASCII 127). |
This can happen if you configure Emacs without specifying the precise |
2973 |
|
version of Solaris that you are using. |
2974 |
|
|
2975 |
* You type Control-H (Backspace) expecting to delete characters. |
**** Solaris 2.3 and 2.4: Unpredictable segmentation faults. |
2976 |
|
|
2977 |
Put `stty dec' in your .login file and your problems will disappear |
A user reported that this happened in 19.29 when it was compiled with |
2978 |
after a day or two. |
the Sun compiler, but not when he recompiled with GCC 2.7.0. |
2979 |
|
|
2980 |
The choice of Backspace for erasure was based on confusion, caused by |
We do not know whether something in Emacs is partly to blame for this. |
|
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. |
|
2981 |
|
|
2982 |
For this reason, I believe `stty dec' is the right mode to use, |
**** Solaris 2.4: Emacs dumps core on startup. |
|
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'. |
|
2983 |
|
|
2984 |
If you are obstinate about confusing buggy overprinting with deletion, |
Bill Sebok says that the cause of this is Solaris 2.4 vendor patch |
2985 |
you can redefine Backspace in your .emacs file: |
102303-05, which extends the Solaris linker to deal with the Solaris |
2986 |
(global-set-key "\b" 'delete-backward-char) |
Common Desktop Environment's linking needs. You can fix the problem |
2987 |
You can probably access help-command via f1. |
by removing this patch and installing patch 102049-02 instead. |
2988 |
|
However, that linker version won't work with CDE. |
2989 |
|
|
2990 |
* Editing files through RFS gives spurious "file has changed" warnings. |
Solaris 2.5 comes with a linker that has this bug. It is reported that if |
2991 |
It is possible that a change in Emacs 18.37 gets around this problem, |
you install all the latest patches (as of June 1996), the bug is fixed. |
2992 |
but in case not, here is a description of how to fix the RFS bug that |
We suspect the crucial patch is one of these, but we don't know |
2993 |
causes it. |
for certain. |
2994 |
|
|
2995 |
There was a serious pair of bugs in the handling of the fsync() system |
103093-03: [README] SunOS 5.5: kernel patch (2140557 bytes) |
2996 |
call in the RFS server. |
102832-01: [README] OpenWindows 3.5: Xview Jumbo Patch (4181613 bytes) |
2997 |
|
103242-04: [README] SunOS 5.5: linker patch (595363 bytes) |
2998 |
|
|
2999 |
The first is that the fsync() call is handled as another name for the |
(One user reports that the bug was fixed by those patches together |
3000 |
close() system call (!!). It appears that fsync() is not used by very |
with patches 102980-04, 103279-01, 103300-02, and 103468-01.) |
|
many programs; Emacs version 18 does an fsync() before closing files |
|
|
to make sure that the bits are on the disk. |
|
3001 |
|
|
3002 |
This is fixed by the enclosed patch to the RFS server. |
If you can determine which patch does fix the bug, please tell |
3003 |
|
bug-gnu-emacs@gnu.org. |
3004 |
|
|
3005 |
The second, more serious problem, is that fsync() is treated as a |
Meanwhile, the GNU linker links Emacs properly on both Solaris 2.4 and |
3006 |
non-blocking system call (i.e., it's implemented as a message that |
Solaris 2.5. |
|
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. |
|
3007 |
|
|
3008 |
(as always, your line numbers may vary) |
**** Solaris 2.4: Dired hangs and C-g does not work. Or Emacs hangs |
3009 |
|
forever waiting for termination of a subprocess that is a zombie. |
3010 |
|
|
3011 |
% rcsdiff -c -r1.2 serversyscall.c |
casper@fwi.uva.nl says the problem is in X11R6. Rebuild libX11.so |
3012 |
RCS file: RCS/serversyscall.c,v |
after changing the file xc/config/cf/sunLib.tmpl. Change the lines |
3013 |
retrieving revision 1.2 |
|
3014 |
diff -c -r1.2 serversyscall.c |
#if ThreadedX |
3015 |
*** /tmp/,RCSt1003677 Wed Jan 28 15:15:02 1987 |
#define SharedX11Reqs -lthread |
3016 |
--- serversyscall.c Wed Jan 28 15:14:48 1987 |
#endif |
3017 |
*************** |
|
3018 |
*** 163,169 **** |
to: |
3019 |
/* |
|
3020 |
* No return sent for close or fsync! |
#if OSMinorVersion < 4 |
3021 |
*/ |
#if ThreadedX |
3022 |
! if (syscall == RSYS_close || syscall == RSYS_fsync) |
#define SharedX11Reqs -lthread |
3023 |
proc->p_returnval = deallocate_fd(proc, msg->m_args[0]); |
#endif |
3024 |
else |
#endif |
3025 |
{ |
|
3026 |
--- 166,172 ---- |
Be sure also to edit x/config/cf/sun.cf so that OSMinorVersion is 4 |
3027 |
/* |
(as it should be for Solaris 2.4). The file has three definitions for |
3028 |
* No return sent for close or fsync! |
OSMinorVersion: the first is for x86, the second for SPARC under |
3029 |
*/ |
Solaris, and the third for SunOS 4. Make sure to update the |
3030 |
! if (syscall == RSYS_close) |
definition for your type of machine and system. |
3031 |
proc->p_returnval = deallocate_fd(proc, msg->m_args[0]); |
|
3032 |
else |
Then do `make Everything' in the top directory of X11R6, to rebuild |
3033 |
{ |
the makefiles and rebuild X. The X built this way work only on |
3034 |
|
Solaris 2.4, not on 2.3. |
3035 |
|
|
3036 |
|
For multithreaded X to work it is necessary to install patch |
3037 |
|
101925-02 to fix problems in header files [2.4]. You need |
3038 |
|
to reinstall gcc or re-run just-fixinc after installing that |
3039 |
|
patch. |
3040 |
|
|
3041 |
|
However, Frank Rust <frust@iti.cs.tu-bs.de> used a simpler solution: |
3042 |
|
he changed |
3043 |
|
#define ThreadedX YES |
3044 |
|
to |
3045 |
|
#define ThreadedX NO |
3046 |
|
in sun.cf and did `make World' to rebuild X11R6. Removing all |
3047 |
|
`-DXTHREAD*' flags and `-lthread' entries from lib/X11/Makefile and |
3048 |
|
typing 'make install' in that directory also seemed to work. |
3049 |
|
|
3050 |
|
**** Solaris 2.x: GCC complains "64 bit integer types not supported". |
3051 |
|
|
3052 |
|
This suggests that GCC is not installed correctly. Most likely you |
3053 |
|
are using GCC 2.7.2.3 (or earlier) on Solaris 2.6 (or later); this |
3054 |
|
does not work without patching. To run GCC 2.7.2.3 on Solaris 2.6 or |
3055 |
|
later, you must patch fixinc.svr4 and reinstall GCC from scratch as |
3056 |
|
described in the Solaris FAQ |
3057 |
|
<http://www.wins.uva.nl/pub/solaris/solaris2.html>. A better fix is |
3058 |
|
to upgrade to GCC 2.8.1 or later. |
3059 |
|
|
3060 |
|
**** Solaris 2.7: Building Emacs with WorkShop Compilers 5.0 98/12/15 |
3061 |
|
C 5.0 failed, apparently with non-default CFLAGS, most probably due to |
3062 |
|
compiler bugs. Using Sun Solaris 2.7 Sun WorkShop 6 update 1 C |
3063 |
|
release was reported to work without problems. It worked OK on |
3064 |
|
another system with Solaris 8 using apparently the same 5.0 compiler |
3065 |
|
and the default CFLAGS. |
3066 |
|
|
3067 |
|
**** Solaris 2.x: Emacs dumps core when built with Motif. |
3068 |
|
|
3069 |
|
The Solaris Motif libraries are buggy, at least up through Solaris 2.5.1. |
3070 |
|
Install the current Motif runtime library patch appropriate for your host. |
3071 |
|
(Make sure the patch is current; some older patch versions still have the bug.) |
3072 |
|
You should install the other patches recommended by Sun for your host, too. |
3073 |
|
You can obtain Sun patches from ftp://sunsolve.sun.com/pub/patches/; |
3074 |
|
look for files with names ending in `.PatchReport' to see which patches |
3075 |
|
are currently recommended for your host. |
3076 |
|
|
3077 |
|
On Solaris 2.6, Emacs is said to work with Motif when Solaris patch |
3078 |
|
105284-12 is installed, but fail when 105284-15 is installed. |
3079 |
|
105284-18 might fix it again. |
3080 |
|
|
3081 |
|
*** Solaris 2.6 and 7: the Compose key does not work. |
3082 |
|
|
3083 |
|
This is a bug in Motif in Solaris. Supposedly it has been fixed for |
3084 |
|
the next major release of Solaris. However, if someone with Sun |
3085 |
|
support complains to Sun about the bug, they may release a patch. |
3086 |
|
If you do this, mention Sun bug #4188711. |
3087 |
|
|
3088 |
|
One workaround is to use a locale that allows non-ASCII characters. |
3089 |
|
For example, before invoking emacs, set the LC_ALL environment |
3090 |
|
variable to "en_US" (American English). The directory /usr/lib/locale |
3091 |
|
lists the supported locales; any locale other than "C" or "POSIX" |
3092 |
|
should do. |
3093 |
|
|
3094 |
|
pen@lysator.liu.se says (Feb 1998) that the Compose key does work |
3095 |
|
if you link with the MIT X11 libraries instead of the Solaris X11 |
3096 |
|
libraries. |
3097 |
|
|
3098 |
|
*** Ultrix and Digital Unix |
3099 |
|
|
3100 |
|
**** Ultrix 4.2: `make install' fails on install-doc with `Error 141'. |
3101 |
|
|
3102 |
|
This happens on Ultrix 4.2 due to failure of a pipeline of tar |
3103 |
|
commands. We don't know why they fail, but the bug seems not to be in |
3104 |
|
Emacs. The workaround is to run the shell command in install-doc by |
3105 |
|
hand. |
3106 |
|
|
3107 |
|
**** Digital Unix 4.0: Garbled display on non-X terminals when Emacs runs. |
3108 |
|
|
3109 |
|
So far it appears that running `tset' triggers this problem (when TERM |
3110 |
|
is vt100, at least). If you do not run `tset', then Emacs displays |
3111 |
|
properly. If someone can tell us precisely which effect of running |
3112 |
|
`tset' actually causes the problem, we may be able to implement a fix |
3113 |
|
in Emacs. |
3114 |
|
|
3115 |
|
**** Ultrix: `expand-file-name' fails to work on any but the machine you dumped Emacs on. |
3116 |
|
|
3117 |
|
On Ultrix, if you use any of the functions which look up information |
3118 |
|
in the passwd database before dumping Emacs (say, by using |
3119 |
|
expand-file-name in site-init.el), then those functions will not work |
3120 |
|
in the dumped Emacs on any host but the one Emacs was dumped on. |
3121 |
|
|
3122 |
|
The solution? Don't use expand-file-name in site-init.el, or in |
3123 |
|
anything it loads. Yuck - some solution. |
3124 |
|
|
3125 |
|
I'm not sure why this happens; if you can find out exactly what is |
3126 |
|
going on, and perhaps find a fix or a workaround, please let us know. |
3127 |
|
Perhaps the YP functions cache some information, the cache is included |
3128 |
|
in the dumped Emacs, and is then inaccurate on any other host. |
3129 |
|
|
3130 |
|
*** SVr4 |
3131 |
|
|
3132 |
|
**** SVr4: On some variants of SVR4, Emacs does not work at all with X. |
3133 |
|
|
3134 |
|
Try defining BROKEN_FIONREAD in your config.h file. If this solves |
3135 |
|
the problem, please send a bug report to tell us this is needed; be |
3136 |
|
sure to say exactly what type of machine and system you are using. |
3137 |
|
|
3138 |
|
**** SVr4: After running emacs once, subsequent invocations crash. |
3139 |
|
|
3140 |
|
Some versions of SVR4 have a serious bug in the implementation of the |
3141 |
|
mmap () system call in the kernel; this causes emacs to run correctly |
3142 |
|
the first time, and then crash when run a second time. |
3143 |
|
|
3144 |
|
Contact your vendor and ask for the mmap bug fix; in the mean time, |
3145 |
|
you may be able to work around the problem by adding a line to your |
3146 |
|
operating system description file (whose name is reported by the |
3147 |
|
configure script) that reads: |
3148 |
|
#define SYSTEM_MALLOC |
3149 |
|
This makes Emacs use memory less efficiently, but seems to work around |
3150 |
|
the kernel bug. |
3151 |
|
|
3152 |
|
*** Linux 1.x |
3153 |
|
|
3154 |
|
**** Linux 1.0-1.04: Typing C-c C-c in Shell mode kills your X server. |
3155 |
|
|
3156 |
|
This happens with Linux kernel 1.0 thru 1.04, approximately. The workaround is |
3157 |
|
to define SIGNALS_VIA_CHARACTERS in config.h and recompile Emacs. |
3158 |
|
Newer Linux kernel versions don't have this problem. |
3159 |
|
|
3160 |
|
**** Linux 1.3: Output from subprocess (such as man or diff) is randomly |
3161 |
|
truncated on GNU/Linux systems. |
3162 |
|
|
3163 |
|
This is due to a kernel bug which seems to be fixed in Linux version |
3164 |
|
1.3.75. |
3165 |
|
|
3166 |
|
** MS-DOS |
3167 |
|
|
3168 |
|
*** When compiling with DJGPP on MS-Windows NT, "config msdos" fails. |
3169 |
|
|
3170 |
|
If the error message is "VDM has been already loaded", this is because |
3171 |
|
Windows has a program called `redir.exe' that is incompatible with a |
3172 |
|
program by the same name supplied with DJGPP, which is used by |
3173 |
|
config.bat. To resolve this, move the DJGPP's `bin' subdirectory to |
3174 |
|
the front of your PATH environment variable. |
3175 |
|
|
3176 |
|
*** When compiling with DJGPP on MS-Windows 95, Make fails for some targets |
3177 |
|
like make-docfile. |
3178 |
|
|
3179 |
|
This can happen if long file name support (the setting of environment |
3180 |
|
variable LFN) when Emacs distribution was unpacked and during |
3181 |
|
compilation are not the same. See the MSDOG section of INSTALL for |
3182 |
|
the explanation of how to avoid this problem. |
3183 |
|
|
3184 |
|
*** Emacs compiled with DJGPP complains at startup: |
3185 |
|
|
3186 |
|
"Wrong type of argument: internal-facep, msdos-menu-active-face" |
3187 |
|
|
3188 |
|
This can happen if you define an environment variable `TERM'. Emacs |
3189 |
|
on MSDOS uses an internal terminal emulator which is disabled if the |
3190 |
|
value of `TERM' is anything but the string "internal". Emacs then |
3191 |
|
works as if its terminal were a dumb glass teletype that doesn't |
3192 |
|
support faces. To work around this, arrange for `TERM' to be |
3193 |
|
undefined when Emacs runs. The best way to do that is to add an |
3194 |
|
[emacs] section to the DJGPP.ENV file which defines an empty value for |
3195 |
|
`TERM'; this way, only Emacs gets the empty value, while the rest of |
3196 |
|
your system works as before. |
3197 |
|
|
3198 |
|
*** MS-DOS: Emacs crashes at startup. |
3199 |
|
|
3200 |
|
Some users report that Emacs 19.29 requires dpmi memory management, |
3201 |
|
and crashes on startup if the system does not have it. We don't yet |
3202 |
|
know why this happens--perhaps these machines don't have enough real |
3203 |
|
memory, or perhaps something is wrong in Emacs or the compiler. |
3204 |
|
However, arranging to use dpmi support is a workaround. |
3205 |
|
|
3206 |
|
You can find out if you have a dpmi host by running go32 without |
3207 |
|
arguments; it will tell you if it uses dpmi memory. For more |
3208 |
|
information about dpmi memory, consult the djgpp FAQ. (djgpp |
3209 |
|
is the GNU C compiler as packaged for MSDOS.) |
3210 |
|
|
3211 |
|
Compiling Emacs under MSDOS is extremely sensitive for proper memory |
3212 |
|
configuration. If you experience problems during compilation, consider |
3213 |
|
removing some or all memory resident programs (notably disk caches) |
3214 |
|
and make sure that your memory managers are properly configured. See |
3215 |
|
the djgpp faq for configuration hints. |
3216 |
|
|
3217 |
|
*** Emacs compiled with DJGPP for MS-DOS/MS-Windows cannot access files |
3218 |
|
in the directory with the special name `dev' under the root of any |
3219 |
|
drive, e.g. `c:/dev'. |
3220 |
|
|
3221 |
|
This is an unfortunate side-effect of the support for Unix-style |
3222 |
|
device names such as /dev/null in the DJGPP runtime library. A |
3223 |
|
work-around is to rename the problem directory to another name. |
3224 |
|
|
3225 |
|
*** MS-DOS+DJGPP: Problems on MS-DOG if DJGPP v2.0 is used to compile Emacs. |
3226 |
|
|
3227 |
|
There are two DJGPP library bugs which cause problems: |
3228 |
|
|
3229 |
|
* Running `shell-command' (or `compile', or `grep') you get |
3230 |
|
`Searching for program: permission denied (EACCES), c:/command.com'; |
3231 |
|
* After you shell to DOS, Ctrl-Break kills Emacs. |
3232 |
|
|
3233 |
|
To work around these bugs, you can use two files in the msdos |
3234 |
|
subdirectory: `is_exec.c' and `sigaction.c'. Compile them and link |
3235 |
|
them into the Emacs executable `temacs'; then they will replace the |
3236 |
|
incorrect library functions. |
3237 |
|
|
3238 |
|
*** MS-DOS: Emacs compiled for MSDOS cannot find some Lisp files, or other |
3239 |
|
run-time support files, when long filename support is enabled. |
3240 |
|
|
3241 |
|
Usually, this problem will manifest itself when Emacs exits |
3242 |
|
immediately after flashing the startup screen, because it cannot find |
3243 |
|
the Lisp files it needs to load at startup. Redirect Emacs stdout |
3244 |
|
and stderr to a file to see the error message printed by Emacs. |
3245 |
|
|
3246 |
|
Another manifestation of this problem is that Emacs is unable to load |
3247 |
|
the support for editing program sources in languages such as C and |
3248 |
|
Lisp. |
3249 |
|
|
3250 |
|
This can happen if the Emacs distribution was unzipped without LFN |
3251 |
|
support, thus causing long filenames to be truncated to the first 6 |
3252 |
|
characters and a numeric tail that Windows 95 normally attaches to it. |
3253 |
|
You should unzip the files again with a utility that supports long |
3254 |
|
filenames (such as djtar from DJGPP or InfoZip's UnZip program |
3255 |
|
compiled with DJGPP v2). The MSDOG section of the file INSTALL |
3256 |
|
explains this issue in more detail. |
3257 |
|
|
3258 |
|
Another possible reason for such failures is that Emacs compiled for |
3259 |
|
MSDOS is used on Windows NT, where long file names are not supported |
3260 |
|
by this version of Emacs, but the distribution was unpacked by an |
3261 |
|
unzip program that preserved the long file names instead of truncating |
3262 |
|
them to DOS 8+3 limits. To be useful on NT, the MSDOS port of Emacs |
3263 |
|
must be unzipped by a DOS utility, so that long file names are |
3264 |
|
properly truncated. |
3265 |
|
|
3266 |
|
** Archaic window managers and toolkits |
3267 |
|
|
3268 |
|
*** OpenLook: Under OpenLook, the Emacs window disappears when you type M-q. |
3269 |
|
|
3270 |
|
Some versions of the Open Look window manager interpret M-q as a quit |
3271 |
|
command for whatever window you are typing at. If you want to use |
3272 |
|
Emacs with that window manager, you should try to configure the window |
3273 |
|
manager to use some other command. You can disable the |
3274 |
|
shortcut keys entirely by adding this line to ~/.OWdefaults: |
3275 |
|
|
3276 |
|
OpenWindows.WindowMenuAccelerators: False |
3277 |
|
|
3278 |
|
**** twm: A position you specified in .Xdefaults is ignored, using twm. |
3279 |
|
|
3280 |
|
twm normally ignores "program-specified" positions. |
3281 |
|
You can tell it to obey them with this command in your `.twmrc' file: |
3282 |
|
|
3283 |
|
UsePPosition "on" #allow clients to request a position |
3284 |
|
|
3285 |
|
** Bugs related to old DEC hardware |
3286 |
|
|
3287 |
|
*** The Compose key on a DEC keyboard does not work as Meta key. |
3288 |
|
|
3289 |
|
This shell command should fix it: |
3290 |
|
|
3291 |
|
xmodmap -e 'keycode 0xb1 = Meta_L' |
3292 |
|
|
3293 |
|
*** Keyboard input gets confused after a beep when using a DECserver |
3294 |
|
as a concentrator. |
3295 |
|
|
3296 |
|
This problem seems to be a matter of configuring the DECserver to use |
3297 |
|
7 bit characters rather than 8 bit characters. |
3298 |
|
|
3299 |
|
* Build problems on legacy systems |
3300 |
|
|
3301 |
|
** BSD/386 1.0: --with-x-toolkit option configures wrong. |
3302 |
|
|
3303 |
|
This problem is due to bugs in the shell in version 1.0 of BSD/386. |
3304 |
|
The workaround is to edit the configure file to use some other shell, |
3305 |
|
such as bash. |
3306 |
|
|
3307 |
|
** Digital Unix 4.0: Emacs fails to build, giving error message |
3308 |
|
Invalid dimension for the charset-ID 160 |
3309 |
|
|
3310 |
|
This is due to a bug or an installation problem in GCC 2.8.0. |
3311 |
|
Installing a more recent version of GCC fixes the problem. |
3312 |
|
|
3313 |
|
** Digital Unix 4.0: Failure in unexec while dumping emacs. |
3314 |
|
|
3315 |
|
This problem manifests itself as an error message |
3316 |
|
|
3317 |
|
unexec: Bad address, writing data section to ... |
3318 |
|
|
3319 |
|
The user suspects that this happened because his X libraries |
3320 |
|
were built for an older system version, |
3321 |
|
|
3322 |
|
./configure --x-includes=/usr/include --x-libraries=/usr/shlib |
3323 |
|
|
3324 |
|
made the problem go away. |
3325 |
|
|
3326 |
|
** Sunos 4.1.1: there are errors compiling sysdep.c. |
3327 |
|
|
3328 |
|
If you get errors such as |
3329 |
|
|
3330 |
|
"sysdep.c", line 2017: undefined structure or union |
3331 |
|
"sysdep.c", line 2017: undefined structure or union |
3332 |
|
"sysdep.c", line 2019: nodename undefined |
3333 |
|
|
3334 |
|
This can result from defining LD_LIBRARY_PATH. It is very tricky |
3335 |
|
to use that environment variable with Emacs. The Emacs configure |
3336 |
|
script links many test programs with the system libraries; you must |
3337 |
|
make sure that the libraries available to configure are the same |
3338 |
|
ones available when you build Emacs. |
3339 |
|
|
3340 |
|
** SunOS 4.1.1: You get this error message from GNU ld: |
3341 |
|
|
3342 |
|
/lib/libc.a(_Q_sub.o): Undefined symbol __Q_get_rp_rd referenced from text segment |
3343 |
|
|
3344 |
|
The problem is in the Sun shared C library, not in GNU ld. |
3345 |
|
|
3346 |
|
The solution is to install Patch-ID# 100267-03 from Sun. |
3347 |
|
|
3348 |
|
** Sunos 4.1: Undefined symbols when linking using --with-x-toolkit. |
3349 |
|
|
3350 |
|
If you get the undefined symbols _atowc _wcslen, _iswprint, _iswspace, |
3351 |
|
_iswcntrl, _wcscpy, and _wcsncpy, then you need to add -lXwchar after |
3352 |
|
-lXaw in the command that links temacs. |
3353 |
|
|
3354 |
|
This problem seems to arise only when the international language |
3355 |
|
extensions to X11R5 are installed. |
3356 |
|
|
3357 |
|
** SunOS: Emacs gets error message from linker on Sun. |
3358 |
|
|
3359 |
|
If the error message says that a symbol such as `f68881_used' or |
3360 |
|
`ffpa_used' or `start_float' is undefined, this probably indicates |
3361 |
|
that you have compiled some libraries, such as the X libraries, |
3362 |
|
with a floating point option other than the default. |
3363 |
|
|
3364 |
|
It's not terribly hard to make this work with small changes in |
3365 |
|
crt0.c together with linking with Fcrt1.o, Wcrt1.o or Mcrt1.o. |
3366 |
|
However, the easiest approach is to build Xlib with the default |
3367 |
|
floating point option: -fsoft. |
3368 |
|
|
3369 |
|
** SunOS: Undefined symbols _dlopen, _dlsym and/or _dlclose. |
3370 |
|
|
3371 |
|
If you see undefined symbols _dlopen, _dlsym, or _dlclose when linking |
3372 |
|
with -lX11, compile and link against the file mit/util/misc/dlsym.c in |
3373 |
|
the MIT X11R5 distribution. Alternatively, link temacs using shared |
3374 |
|
libraries with s/sunos4shr.h. (This doesn't work if you use the X |
3375 |
|
toolkit.) |
3376 |
|
|
3377 |
|
If you get the additional error that the linker could not find |
3378 |
|
lib_version.o, try extracting it from X11/usr/lib/X11/libvim.a in |
3379 |
|
X11R4, then use it in the link. |
3380 |
|
|
3381 |
|
** VMS: Compilation errors on VMS. |
3382 |
|
|
3383 |
|
You will get warnings when compiling on VMS because there are |
3384 |
|
variable names longer than 32 (or whatever it is) characters. |
3385 |
|
This is not an error. Ignore it. |
3386 |
|
|
3387 |
|
VAX C does not support #if defined(foo). Uses of this construct |
3388 |
|
were removed, but some may have crept back in. They must be rewritten. |
3389 |
|
|
3390 |
|
There is a bug in the C compiler which fails to sign extend characters |
3391 |
|
in conditional expressions. The bug is: |
3392 |
|
char c = -1, d = 1; |
3393 |
|
int i; |
3394 |
|
|
3395 |
|
i = d ? c : d; |
3396 |
|
The result is i == 255; the fix is to typecast the char in the |
3397 |
|
conditional expression as an (int). Known occurrences of such |
3398 |
|
constructs in Emacs have been fixed. |
3399 |
|
|
3400 |
* Vax C compiler bugs affecting Emacs. |
** Vax C compiler bugs affecting Emacs. |
3401 |
|
|
3402 |
You may get one of these problems compiling Emacs: |
You may get one of these problems compiling Emacs: |
3403 |
|
|
3430 |
The `contents' field of a Lisp vector is an array of Lisp_Objects, |
The `contents' field of a Lisp vector is an array of Lisp_Objects, |
3431 |
so you may see the problem happening with indexed references to that. |
so you may see the problem happening with indexed references to that. |
3432 |
|
|
3433 |
* 68000 C compiler problems |
** 68000 C compiler problems |
3434 |
|
|
3435 |
Various 68000 compilers have different problems. |
Various 68000 compilers have different problems. |
3436 |
These are some that have been observed. |
These are some that have been observed. |
3437 |
|
|
3438 |
** Using value of assignment expression on union type loses. |
*** Using value of assignment expression on union type loses. |
3439 |
This means that x = y = z; or foo (x = z); does not work |
This means that x = y = z; or foo (x = z); does not work |
3440 |
if x is of type Lisp_Object. |
if x is of type Lisp_Object. |
3441 |
|
|
3442 |
** "cannot reclaim" error. |
*** "cannot reclaim" error. |
3443 |
|
|
3444 |
This means that an expression is too complicated. You get the correct |
This means that an expression is too complicated. You get the correct |
3445 |
line number in the error message. The code must be rewritten with |
line number in the error message. The code must be rewritten with |
3446 |
simpler expressions. |
simpler expressions. |
3447 |
|
|
3448 |
** XCONS, XSTRING, etc macros produce incorrect code. |
*** XCONS, XSTRING, etc macros produce incorrect code. |
3449 |
|
|
3450 |
If temacs fails to run at all, this may be the cause. |
If temacs fails to run at all, this may be the cause. |
3451 |
Compile this test program and look at the assembler code: |
Compile this test program and look at the assembler code: |
3465 |
This problem will not happen if the m-...h file for your type |
This problem will not happen if the m-...h file for your type |
3466 |
of machine defines NO_UNION_TYPE. That is the recommended setting now. |
of machine defines NO_UNION_TYPE. That is the recommended setting now. |
3467 |
|
|
3468 |
* C compilers lose on returning unions |
*** C compilers lose on returning unions. |
3469 |
|
|
3470 |
I hear that some C compilers cannot handle returning a union type. |
I hear that some C compilers cannot handle returning a union type. |
3471 |
Most of the functions in GNU Emacs return type Lisp_Object, which is |
Most of the functions in GNU Emacs return type Lisp_Object, which is |
3475 |
of machine defines NO_UNION_TYPE. |
of machine defines NO_UNION_TYPE. |
3476 |
|
|
3477 |
|
|
3478 |
Copyright 1987,88,89,93,94,95,96,97,98,1999,2001,2002 |
Copyright 1987,88,89,93,94,95,96,97,98,1999,2001,2002,2004 |
3479 |
Free Software Foundation, Inc. |
Free Software Foundation, Inc. |
3480 |
|
|
3481 |
Copying and redistribution of this file with or without modification |
Copying and redistribution of this file with or without modification |