92354
|
1 Known Problems with GNU Emacs
|
|
2
|
75774
|
3 Copyright (C) 1987, 1988, 1989, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
|
106815
|
4 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
|
75774
|
5 Free Software Foundation, Inc.
|
|
6 See the end of the file for license conditions.
|
|
7
|
|
8
|
25853
|
9 This file describes various problems that have been encountered
|
101543
|
10 in compiling, installing and running GNU Emacs. Try doing C-c C-t
|
|
11 and browsing through the outline headers. (See C-h m for help on
|
108799
|
12 Outline mode.) Information about systems that are no longer supported,
|
|
13 and old Emacs releases, has been removed. Consult older versions of
|
|
14 this file if you are interested in that information.
|
56734
|
15
|
90104
|
16 * Mule-UCS doesn't work in Emacs 23.
|
89502
|
17
|
|
18 It's completely redundant now, as far as we know.
|
|
19
|
56734
|
20 * Emacs startup failures
|
|
21
|
|
22 ** Emacs fails to start, complaining about missing fonts.
|
|
23
|
|
24 A typical error message might be something like
|
|
25
|
|
26 No fonts match `-*-fixed-medium-r-*--6-*-*-*-*-*-iso8859-1'
|
|
27
|
|
28 This happens because some X resource specifies a bad font family for
|
|
29 Emacs to use. The possible places where this specification might be
|
|
30 are:
|
|
31
|
|
32 - in your ~/.Xdefaults file
|
|
33
|
|
34 - client-side X resource file, such as ~/Emacs or
|
|
35 /usr/X11R6/lib/app-defaults/Emacs or
|
|
36 /usr/X11R6/lib/X11/app-defaults/Emacs
|
|
37
|
|
38 One of these files might have bad or malformed specification of a
|
|
39 fontset that Emacs should use. To fix the problem, you need to find
|
|
40 the problematic line(s) and correct them.
|
|
41
|
|
42 ** Emacs aborts while starting up, only when run without X.
|
|
43
|
|
44 This problem often results from compiling Emacs with GCC when GCC was
|
|
45 installed incorrectly. The usual error in installing GCC is to
|
|
46 specify --includedir=/usr/include. Installation of GCC makes
|
|
47 corrected copies of the system header files. GCC is supposed to use
|
|
48 the corrected copies in preference to the original system headers.
|
|
49 Specifying --includedir=/usr/include causes the original system header
|
|
50 files to be used. On some systems, the definition of ioctl in the
|
|
51 original system header files is invalid for ANSI C and causes Emacs
|
|
52 not to work.
|
|
53
|
|
54 The fix is to reinstall GCC, and this time do not specify --includedir
|
|
55 when you configure it. Then recompile Emacs. Specifying --includedir
|
|
56 is appropriate only in very special cases and it should *never* be the
|
|
57 same directory where system header files are kept.
|
|
58
|
|
59 ** Emacs does not start, complaining that it cannot open termcap database file.
|
|
60
|
|
61 If your system uses Terminfo rather than termcap (most modern
|
|
62 systems do), this could happen if the proper version of
|
|
63 ncurses is not visible to the Emacs configure script (i.e. it
|
|
64 cannot be found along the usual path the linker looks for
|
|
65 libraries). It can happen because your version of ncurses is
|
|
66 obsolete, or is available only in form of binaries.
|
|
67
|
|
68 The solution is to install an up-to-date version of ncurses in
|
|
69 the developer's form (header files, static libraries and
|
|
70 symbolic links); in some GNU/Linux distributions (e.g. Debian)
|
|
71 it constitutes a separate package.
|
|
72
|
|
73 ** Emacs 20 and later fails to load Lisp files at startup.
|
|
74
|
|
75 The typical error message might be like this:
|
|
76
|
|
77 "Cannot open load file: fontset"
|
|
78
|
|
79 This could happen if you compress the file lisp/subdirs.el. That file
|
|
80 tells Emacs what are the directories where it should look for Lisp
|
|
81 files. Emacs cannot work with subdirs.el compressed, since the
|
|
82 Auto-compress mode it needs for this will not be loaded until later,
|
|
83 when your .emacs file is processed. (The package `fontset.el' is
|
|
84 required to set up fonts used to display text on window systems, and
|
|
85 it's loaded very early in the startup procedure.)
|
|
86
|
|
87 Similarly, any other .el file for which there's no corresponding .elc
|
|
88 file could fail to load if it is compressed.
|
|
89
|
108807
|
90 The solution is to uncompress all .el files that don't have a .elc file.
|
56734
|
91
|
|
92 Another possible reason for such failures is stale *.elc files
|
108800
|
93 lurking somewhere on your load-path -- see the next section.
|
56734
|
94
|
|
95 ** Emacs prints an error at startup after upgrading from an earlier version.
|
|
96
|
|
97 An example of such an error is:
|
|
98
|
|
99 x-complement-fontset-spec: "Wrong type argument: stringp, nil"
|
|
100
|
|
101 This can be another symptom of stale *.elc files in your load-path.
|
|
102 The following command will print any duplicate Lisp files that are
|
|
103 present in load-path:
|
|
104
|
|
105 emacs -q -batch -f list-load-path-shadows
|
|
106
|
|
107 If this command prints any file names, some of these files are stale,
|
|
108 and should be deleted or their directories removed from your
|
|
109 load-path.
|
|
110
|
|
111 ** With X11R6.4, public-patch-3, Emacs crashes at startup.
|
|
112
|
|
113 Reportedly this patch in X fixes the problem.
|
|
114
|
|
115 --- xc/lib/X11/imInt.c~ Wed Jun 30 13:31:56 1999
|
|
116 +++ xc/lib/X11/imInt.c Thu Jul 1 15:10:27 1999
|
|
117 @@ -1,4 +1,4 @@
|
|
118 -/* $TOG: imInt.c /main/5 1998/05/30 21:11:16 kaleb $ */
|
|
119 +/* $TOG: imInt.c /main/5 1998/05/30 21:11:16 kaleb $ */
|
|
120 /******************************************************************
|
|
121
|
97732
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
122 Copyright 1992, 1993, 1994 by FUJITSU LIMITED
|
56734
|
123 @@ -166,8 +166,8 @@
|
|
124 _XimMakeImName(lcd)
|
97732
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
125 XLCd lcd;
|
56734
|
126 {
|
|
127 - char* begin;
|
|
128 - char* end;
|
|
129 + char* begin = NULL;
|
|
130 + char* end = NULL;
|
97732
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
131 char* ret;
|
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
132 int i = 0;
|
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
133 char* ximmodifier = XIMMODIFIER;
|
56734
|
134 @@ -182,7 +182,11 @@
|
97732
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
135 }
|
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
136 ret = Xmalloc(end - begin + 2);
|
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
137 if (ret != NULL) {
|
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
138 - (void)strncpy(ret, begin, end - begin + 1);
|
56734
|
139 + if (begin != NULL) {
|
97732
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
140 + (void)strncpy(ret, begin, end - begin + 1);
|
56734
|
141 + } else {
|
97732
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
142 + ret[0] = '\0';
|
56734
|
143 + }
|
97732
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
144 ret[end - begin + 1] = '\0';
|
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
145 }
|
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
146 return ret;
|
56734
|
147
|
77765
|
148 ** Emacs crashes on startup after a glibc upgrade.
|
|
149
|
|
150 This is caused by a binary incompatible change to the malloc
|
|
151 implementation in glibc 2.5.90-22. As a result, Emacs binaries built
|
|
152 using prior versions of glibc crash when run under 2.5.90-22.
|
|
153
|
77766
|
154 This problem was first seen in pre-release versions of Fedora 7, and
|
77765
|
155 may be fixed in the final Fedora 7 release. To stop the crash from
|
|
156 happening, first try upgrading to the newest version of glibc; if this
|
|
157 does not work, rebuild Emacs with the same version of glibc that you
|
|
158 will run it under. For details, see
|
|
159
|
|
160 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239344
|
|
161
|
56734
|
162 * Crash bugs
|
|
163
|
108364
|
164 ** Emacs crashes when running in a terminal, if compiled with GCC 4.5.0
|
108359
|
165 This version of GCC is buggy: see
|
|
166
|
|
167 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6031
|
|
168 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43904
|
|
169
|
|
170 You can work around this error in gcc-4.5 by omitting sibling call
|
|
171 optimization. To do this, configure Emacs with
|
|
172
|
|
173 CFLAGS="-g -O2 -fno-optimize-sibling-calls" ./configure
|
|
174
|
56734
|
175 ** Emacs crashes in x-popup-dialog.
|
|
176
|
|
177 This can happen if the dialog widget cannot find the font it wants to
|
|
178 use. You can work around the problem by specifying another font with
|
|
179 an X resource--for example, `Emacs.dialog*.font: 9x15' (or any font that
|
|
180 happens to exist on your X server).
|
|
181
|
|
182 ** Emacs crashes when you use Bibtex mode.
|
|
183
|
|
184 This happens if your system puts a small limit on stack size. You can
|
|
185 prevent the problem by using a suitable shell command (often `ulimit')
|
|
186 to raise the stack size limit before you run Emacs.
|
|
187
|
|
188 Patches to raise the stack size limit automatically in `main'
|
|
189 (src/emacs.c) on various systems would be greatly appreciated.
|
|
190
|
|
191 ** Error message `Symbol's value as variable is void: x', followed by
|
|
192 a segmentation fault and core dump.
|
|
193
|
|
194 This has been tracked to a bug in tar! People report that tar erroneously
|
|
195 added a line like this at the beginning of files of Lisp code:
|
|
196
|
|
197 x FILENAME, N bytes, B tape blocks
|
|
198
|
|
199 If your tar has this problem, install GNU tar--if you can manage to
|
|
200 untar it :-).
|
|
201
|
|
202 ** Crashes when displaying GIF images in Emacs built with version
|
|
203 libungif-4.1.0 are resolved by using version libungif-4.1.0b1.
|
|
204 Configure checks for the correct version, but this problem could occur
|
|
205 if a binary built against a shared libungif is run on a system with an
|
|
206 older version.
|
|
207
|
|
208 ** Emacs aborts inside the function `tparam1'.
|
|
209
|
|
210 This can happen if Emacs was built without terminfo support, but the
|
|
211 terminal's capabilities use format that is only supported by terminfo.
|
|
212 If your system has ncurses installed, this might happen if your
|
|
213 version of ncurses is broken; upgrading to a newer version of ncurses
|
|
214 and reconfiguring and rebuilding Emacs should solve this.
|
|
215
|
|
216 All modern systems support terminfo, so even if ncurses is not the
|
|
217 problem, you should look for a way to configure Emacs so that it uses
|
|
218 terminfo when built.
|
|
219
|
103293
|
220 ** Emacs crashes when using some version of the Exceed X server.
|
|
221
|
|
222 Upgrading to a newer version of Exceed has been reported to prevent
|
|
223 these crashes. You should consider switching to a free X server, such
|
|
224 as Xming or Cygwin/X.
|
56734
|
225
|
|
226 ** Emacs crashes with SIGSEGV in XtInitializeWidgetClass.
|
|
227
|
|
228 It crashes on X, but runs fine when called with option "-nw".
|
|
229
|
|
230 This has been observed when Emacs is linked with GNU ld but without passing
|
|
231 the -z nocombreloc flag. Emacs normally knows to pass the -z nocombreloc
|
|
232 flag when needed, so if you come across a situation where the flag is
|
|
233 necessary but missing, please report it via M-x report-emacs-bug.
|
|
234
|
|
235 On platforms such as Solaris, you can also work around this problem by
|
|
236 configuring your compiler to use the native linker instead of GNU ld.
|
|
237
|
111178
|
238 ** When Emacs is compiled with Gtk+, closing a display kills Emacs.
|
|
239
|
|
240 There is a long-standing bug in GTK that prevents it from recovering
|
|
241 from disconnects: http://bugzilla.gnome.org/show_bug.cgi?id=85715.
|
|
242
|
|
243 Thus, for instance, when Emacs is run as a server on a text terminal,
|
|
244 and an X frame is created, and the X server for that frame crashes or
|
|
245 exits unexpectedly, Emacs must exit to prevent a GTK error that would
|
|
246 result in an endless loop.
|
|
247
|
|
248 If you need Emacs to be able to recover from closing displays, compile
|
|
249 it with the Lucid toolkit instead of GTK.
|
100503
|
250
|
56734
|
251 * General runtime problems
|
|
252
|
|
253 ** Lisp problems
|
|
254
|
|
255 *** Changes made to .el files do not take effect.
|
|
256
|
|
257 You may have forgotten to recompile them into .elc files.
|
|
258 Then the old .elc files will be loaded, and your changes
|
|
259 will not be seen. To fix this, do M-x byte-recompile-directory
|
|
260 and specify the directory that contains the Lisp files.
|
|
261
|
|
262 Emacs should print a warning when loading a .elc file which is older
|
|
263 than the corresponding .el file.
|
|
264
|
|
265 *** Watch out for .emacs files and EMACSLOADPATH environment vars.
|
|
266
|
|
267 These control the actions of Emacs.
|
|
268 ~/.emacs is your Emacs init file.
|
108807
|
269 EMACSLOADPATH overrides which directories the function "load" will search.
|
56734
|
270
|
|
271 If you observe strange problems, check for these and get rid
|
|
272 of them, then try again.
|
|
273
|
|
274 *** Using epop3.el package causes Emacs to signal an error.
|
|
275
|
|
276 The error message might be something like this:
|
|
277
|
|
278 "Lisp nesting exceeds max-lisp-eval-depth"
|
|
279
|
|
280 This happens because epop3 redefines the function gethash, which is a
|
|
281 built-in primitive beginning with Emacs 21.1. We don't have a patch
|
|
282 for epop3 that fixes this, but perhaps a newer version of epop3
|
|
283 corrects that.
|
|
284
|
|
285 *** Buffers from `with-output-to-temp-buffer' get set up in Help mode.
|
|
286
|
|
287 Changes in Emacs 20.4 to the hooks used by that function cause
|
|
288 problems for some packages, specifically BBDB. See the function's
|
|
289 documentation for the hooks involved. BBDB 2.00.06 fixes the problem.
|
|
290
|
|
291 *** The Hyperbole package causes *Help* buffers not to be displayed in
|
|
292 Help mode due to setting `temp-buffer-show-hook' rather than using
|
|
293 `add-hook'. Using `(add-hook 'temp-buffer-show-hook
|
|
294 'help-mode-maybe)' after loading Hyperbole should fix this.
|
|
295
|
|
296 ** Keyboard problems
|
|
297
|
|
298 *** "Compose Character" key does strange things when used as a Meta key.
|
|
299
|
|
300 If you define one key to serve as both Meta and Compose Character, you
|
|
301 will get strange results. In previous Emacs versions, this "worked"
|
|
302 in that the key acted as Meta--that's because the older Emacs versions
|
|
303 did not try to support Compose Character. Now Emacs tries to do
|
|
304 character composition in the standard X way. This means that you
|
|
305 must pick one meaning or the other for any given key.
|
|
306
|
|
307 You can use both functions (Meta, and Compose Character) if you assign
|
|
308 them to two different keys.
|
|
309
|
|
310 *** C-z just refreshes the screen instead of suspending Emacs.
|
|
311
|
|
312 You are probably using a shell that doesn't support job control, even
|
|
313 though the system itself is capable of it. Either use a different shell,
|
|
314 or set the variable `cannot-suspend' to a non-nil value.
|
|
315
|
|
316 *** With M-x enable-flow-control, you need to type C-\ twice
|
|
317 to do incremental search--a single C-\ gets no response.
|
|
318
|
|
319 This has been traced to communicating with your machine via kermit,
|
|
320 with C-\ as the kermit escape character. One solution is to use
|
|
321 another escape character in kermit. One user did
|
|
322
|
|
323 set escape-character 17
|
|
324
|
|
325 in his .kermrc file, to make C-q the kermit escape character.
|
|
326
|
|
327 ** Mailers and other helper programs
|
|
328
|
|
329 *** movemail compiled with POP support can't connect to the POP server.
|
|
330
|
|
331 Make sure that the `pop' entry in /etc/services, or in the services
|
|
332 NIS map if your machine uses NIS, has the same port number as the
|
|
333 entry on the POP server. A common error is for the POP server to be
|
|
334 listening on port 110, the assigned port for the POP3 protocol, while
|
|
335 the client is trying to connect on port 109, the assigned port for the
|
|
336 old POP protocol.
|
|
337
|
|
338 *** RMAIL gets error getting new mail.
|
|
339
|
|
340 RMAIL gets new mail from /usr/spool/mail/$USER using a program
|
|
341 called `movemail'. This program interlocks with /bin/mail using
|
|
342 the protocol defined by /bin/mail.
|
|
343
|
|
344 There are two different protocols in general use. One of them uses
|
|
345 the `flock' system call. The other involves creating a lock file;
|
|
346 `movemail' must be able to write in /usr/spool/mail in order to do
|
|
347 this. You control which one is used by defining, or not defining,
|
|
348 the macro MAIL_USE_FLOCK in config.h or the m- or s- file it includes.
|
|
349 IF YOU DON'T USE THE FORM OF INTERLOCKING THAT IS NORMAL ON YOUR
|
|
350 SYSTEM, YOU CAN LOSE MAIL!
|
|
351
|
|
352 If your system uses the lock file protocol, and fascist restrictions
|
|
353 prevent ordinary users from writing the lock files in /usr/spool/mail,
|
|
354 you may need to make `movemail' setgid to a suitable group such as
|
|
355 `mail'. To do this, use the following commands (as root) after doing the
|
|
356 make install.
|
|
357
|
97732
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
358 chgrp mail movemail
|
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
359 chmod 2755 movemail
|
56734
|
360
|
|
361 Installation normally copies movemail from the build directory to an
|
|
362 installation directory which is usually under /usr/local/lib. The
|
|
363 installed copy of movemail is usually in the directory
|
|
364 /usr/local/lib/emacs/VERSION/TARGET. You must change the group and
|
|
365 mode of the installed copy; changing the group and mode of the build
|
|
366 directory copy is ineffective.
|
|
367
|
|
368 *** rcs2log gives you the awk error message "too many fields".
|
|
369
|
|
370 This is due to an arbitrary limit in certain versions of awk.
|
|
371 The solution is to use gawk (GNU awk).
|
|
372
|
|
373 ** Problems with hostname resolution
|
|
374
|
|
375 *** Emacs fails to understand most Internet host names, even though
|
|
376 the names work properly with other programs on the same system.
|
|
377 *** Emacs won't work with X-windows if the value of DISPLAY is HOSTNAME:0.
|
65134
|
378 *** Gnus can't make contact with the specified host for nntp.
|
56734
|
379
|
|
380 This typically happens on Suns and other systems that use shared
|
|
381 libraries. The cause is that the site has installed a version of the
|
|
382 shared library which uses a name server--but has not installed a
|
|
383 similar version of the unshared library which Emacs uses.
|
|
384
|
|
385 The result is that most programs, using the shared library, work with
|
|
386 the nameserver, but Emacs does not.
|
|
387
|
|
388 The fix is to install an unshared library that corresponds to what you
|
|
389 installed in the shared library, and then relink Emacs.
|
|
390
|
|
391 If you have already installed the name resolver in the file libresolv.a,
|
|
392 then you need to compile Emacs to use that library. The easiest way to
|
|
393 do this is to add to config.h a definition of LIBS_SYSTEM, LIBS_MACHINE
|
|
394 or LIB_STANDARD which uses -lresolv. Watch out! If you redefine a macro
|
|
395 that is already in use in your configuration to supply some other libraries,
|
|
396 be careful not to lose the others.
|
|
397
|
|
398 Thus, you could start by adding this to config.h:
|
|
399
|
|
400 #define LIBS_SYSTEM -lresolv
|
|
401
|
|
402 Then if this gives you an error for redefining a macro, and you see that
|
|
403 the s- file defines LIBS_SYSTEM as -lfoo -lbar, you could change config.h
|
|
404 again to say this:
|
|
405
|
|
406 #define LIBS_SYSTEM -lresolv -lfoo -lbar
|
|
407
|
|
408 *** Emacs does not know your host's fully-qualified domain name.
|
|
409
|
77311
|
410 For example, (system-name) returns some variation on
|
|
411 "localhost.localdomain", rather the name you were expecting.
|
|
412
|
56734
|
413 You need to configure your machine with a fully qualified domain name,
|
77311
|
414 (i.e. a name with at least one ".") either in /etc/hosts,
|
108807
|
415 /etc/hostname, the NIS, or wherever your system calls for specifying this.
|
56734
|
416
|
|
417 If you cannot fix the configuration, you can set the Lisp variable
|
|
418 mail-host-address to the value you want.
|
|
419
|
|
420 ** NFS and RFS
|
|
421
|
|
422 *** Emacs says it has saved a file, but the file does not actually
|
|
423 appear on disk.
|
|
424
|
|
425 This can happen on certain systems when you are using NFS, if the
|
|
426 remote disk is full. It is due to a bug in NFS (or certain NFS
|
|
427 implementations), and there is apparently nothing Emacs can do to
|
|
428 detect the problem. Emacs checks the failure codes of all the system
|
|
429 calls involved in writing a file, including `close'; but in the case
|
|
430 where the problem occurs, none of those system calls fails.
|
|
431
|
|
432 *** Editing files through RFS gives spurious "file has changed" warnings.
|
|
433 It is possible that a change in Emacs 18.37 gets around this problem,
|
|
434 but in case not, here is a description of how to fix the RFS bug that
|
|
435 causes it.
|
|
436
|
|
437 There was a serious pair of bugs in the handling of the fsync() system
|
|
438 call in the RFS server.
|
|
439
|
|
440 The first is that the fsync() call is handled as another name for the
|
|
441 close() system call (!!). It appears that fsync() is not used by very
|
|
442 many programs; Emacs version 18 does an fsync() before closing files
|
|
443 to make sure that the bits are on the disk.
|
|
444
|
|
445 This is fixed by the enclosed patch to the RFS server.
|
|
446
|
|
447 The second, more serious problem, is that fsync() is treated as a
|
|
448 non-blocking system call (i.e., it's implemented as a message that
|
|
449 gets sent to the remote system without waiting for a reply). Fsync is
|
|
450 a useful tool for building atomic file transactions. Implementing it
|
|
451 as a non-blocking RPC call (when the local call blocks until the sync
|
|
452 is done) is a bad idea; unfortunately, changing it will break the RFS
|
|
453 protocol. No fix was supplied for this problem.
|
|
454
|
|
455 (as always, your line numbers may vary)
|
|
456
|
|
457 % rcsdiff -c -r1.2 serversyscall.c
|
|
458 RCS file: RCS/serversyscall.c,v
|
|
459 retrieving revision 1.2
|
|
460 diff -c -r1.2 serversyscall.c
|
|
461 *** /tmp/,RCSt1003677 Wed Jan 28 15:15:02 1987
|
|
462 --- serversyscall.c Wed Jan 28 15:14:48 1987
|
|
463 ***************
|
|
464 *** 163,169 ****
|
97732
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
465 /*
|
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
466 * No return sent for close or fsync!
|
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
467 */
|
56734
|
468 ! if (syscall == RSYS_close || syscall == RSYS_fsync)
|
97732
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
469 proc->p_returnval = deallocate_fd(proc, msg->m_args[0]);
|
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
470 else
|
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
471 {
|
56734
|
472 --- 166,172 ----
|
97732
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
473 /*
|
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
474 * No return sent for close or fsync!
|
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
475 */
|
56734
|
476 ! if (syscall == RSYS_close)
|
97732
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
477 proc->p_returnval = deallocate_fd(proc, msg->m_args[0]);
|
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
478 else
|
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
479 {
|
56734
|
480
|
108800
|
481 ** PSGML conflicts with sgml-mode.
|
56734
|
482
|
|
483 PSGML package uses the same names of some variables (like keymap)
|
|
484 as built-in sgml-mode.el because it was created as a replacement
|
|
485 of that package. The conflict will be shown if you load
|
|
486 sgml-mode.el before psgml.el. E.g. this could happen if you edit
|
|
487 HTML page and then start to work with SGML or XML file. html-mode
|
|
488 (from sgml-mode.el) is used for HTML file and loading of psgml.el
|
|
489 (for sgml-mode or xml-mode) will cause an error.
|
|
490
|
60158
|
491 ** PCL-CVS
|
|
492
|
|
493 *** Lines are not updated or new lines are added in the buffer upon commit.
|
|
494
|
|
495 When committing files located higher in the hierarchy than the examined
|
|
496 directory, some versions of the CVS program return an ambiguous message
|
|
497 from which PCL-CVS cannot extract the full location of the committed
|
|
498 files. As a result, the corresponding lines in the PCL-CVS buffer are
|
|
499 not updated with the new revision of these files, and new lines are
|
|
500 added to the top-level directory.
|
|
501
|
|
502 This can happen with CVS versions 1.12.8 and 1.12.9. Upgrade to CVS
|
|
503 1.12.10 or newer to fix this problem.
|
|
504
|
56734
|
505 ** Miscellaneous problems
|
|
506
|
78982
|
507 *** Emacs uses 100% of CPU time
|
|
508
|
|
509 This is a known problem with some versions of the Semantic package.
|
78998
|
510 The solution is to upgrade Semantic to version 2.0pre4 (distributed
|
|
511 with CEDET 1.0pre4) or later.
|
78982
|
512
|
56734
|
513 *** Self-documentation messages are garbled.
|
|
514
|
|
515 This means that the file `etc/DOC-...' doesn't properly correspond
|
|
516 with the Emacs executable. Redumping Emacs and then installing the
|
|
517 corresponding pair of files should fix the problem.
|
|
518
|
|
519 *** Programs running under terminal emulator do not recognize `emacs'
|
|
520 terminal type.
|
|
521
|
|
522 The cause of this is a shell startup file that sets the TERMCAP
|
|
523 environment variable. The terminal emulator uses that variable to
|
108807
|
524 provide the information on the special terminal type that Emacs emulates.
|
56734
|
525
|
|
526 Rewrite your shell startup file so that it does not change TERMCAP
|
|
527 in such a case. You could use the following conditional which sets
|
|
528 it only if it is undefined.
|
|
529
|
|
530 if ( ! ${?TERMCAP} ) setenv TERMCAP ~/my-termcap-file
|
|
531
|
|
532 Or you could set TERMCAP only when you set TERM--which should not
|
|
533 happen in a non-login shell.
|
|
534
|
|
535 *** In Shell mode, you get a ^M at the end of every line.
|
|
536
|
|
537 This happens to people who use tcsh, because it is trying to be too
|
|
538 smart. It sees that the Shell uses terminal type `unknown' and turns
|
|
539 on the flag to output ^M at the end of each line. You can fix the
|
|
540 problem by adding this to your .cshrc file:
|
|
541
|
|
542 if ($?EMACS) then
|
72833
81a55a7dc3c3
* etc/NEWS: In terminal-oriented subshells, the EMACS environment
Paul Eggert <eggert@twinsun.com>
diff
changeset
|
543 if ("$EMACS" =~ /*) then
|
56734
|
544 unset edit
|
|
545 stty -icrnl -onlcr -echo susp ^Z
|
|
546 endif
|
|
547 endif
|
|
548
|
|
549 *** Emacs startup on GNU/Linux systems (and possibly other systems) is slow.
|
|
550
|
|
551 This can happen if the system is misconfigured and Emacs can't get the
|
|
552 full qualified domain name, FQDN. You should have your FQDN in the
|
|
553 /etc/hosts file, something like this:
|
|
554
|
|
555 127.0.0.1 localhost
|
|
556 129.187.137.82 nuc04.t30.physik.tu-muenchen.de nuc04
|
|
557
|
|
558 The way to set this up may vary on non-GNU systems.
|
|
559
|
|
560 *** Attempting to visit remote files via ange-ftp fails.
|
|
561
|
|
562 If the error message is "ange-ftp-file-modtime: Specified time is not
|
|
563 representable", then this could happen when `lukemftp' is used as the
|
|
564 ftp client. This was reported to happen on Debian GNU/Linux, kernel
|
|
565 version 2.4.3, with `lukemftp' 1.5-5, but might happen on other
|
|
566 systems as well. To avoid this problem, switch to using the standard
|
|
567 ftp client. On a Debian system, type
|
|
568
|
|
569 update-alternatives --config ftp
|
|
570
|
|
571 and then choose /usr/bin/netkit-ftp.
|
|
572
|
|
573 *** JPEG images aren't displayed.
|
|
574
|
|
575 This has been reported when Emacs is built with jpeg-6a library.
|
|
576 Upgrading to jpeg-6b solves the problem. Configure checks for the
|
|
577 correct version, but this problem could occur if a binary built
|
|
578 against a shared libjpeg is run on a system with an older version.
|
|
579
|
|
580 *** Dired is very slow.
|
|
581
|
|
582 This could happen if invocation of the `df' program takes a long
|
|
583 time. Possible reasons for this include:
|
|
584
|
|
585 - ClearCase mounted filesystems (VOBs) that sometimes make `df'
|
|
586 response time extremely slow (dozens of seconds);
|
|
587
|
|
588 - slow automounters on some old versions of Unix;
|
|
589
|
|
590 - slow operation of some versions of `df'.
|
|
591
|
|
592 To work around the problem, you could either (a) set the variable
|
|
593 `directory-free-space-program' to nil, and thus prevent Emacs from
|
|
594 invoking `df'; (b) use `df' from the GNU Fileutils package; or
|
|
595 (c) use CVS, which is Free Software, instead of ClearCase.
|
|
596
|
|
597 *** ps-print commands fail to find prologue files ps-prin*.ps.
|
|
598
|
|
599 This can happen if you use an old version of X-Symbol package: it
|
|
600 defines compatibility functions which trick ps-print into thinking it
|
|
601 runs in XEmacs, and look for the prologue files in a wrong directory.
|
|
602
|
|
603 The solution is to upgrade X-Symbol to a later version.
|
|
604
|
|
605 *** On systems with shared libraries you might encounter run-time errors
|
|
606 from the dynamic linker telling you that it is unable to find some
|
|
607 shared libraries, for instance those for Xaw3d or image support.
|
|
608 These errors mean Emacs has been linked with a library whose shared
|
|
609 library is not in the default search path of the dynamic linker.
|
|
610
|
|
611 Similar problems could prevent Emacs from building, since the build
|
|
612 process invokes Emacs several times.
|
|
613
|
|
614 On many systems, it is possible to set LD_LIBRARY_PATH in your
|
|
615 environment to specify additional directories where shared libraries
|
|
616 can be found.
|
|
617
|
|
618 Other systems allow to set LD_RUN_PATH in a similar way, but before
|
|
619 Emacs is linked. With LD_RUN_PATH set, the linker will include a
|
|
620 specified run-time search path in the executable.
|
|
621
|
|
622 On some systems, Emacs can crash due to problems with dynamic
|
|
623 linking. Specifically, on SGI Irix 6.5, crashes were reported with
|
|
624 backtraces like this:
|
|
625
|
|
626 (dbx) where
|
|
627 0 strcmp(0xf49239d, 0x4031184, 0x40302b4, 0x12, 0xf0000000, 0xf4923aa, 0x0, 0x492ddb2) ["/xlv22/ficus-jan23/work/irix/lib/libc/libc_n32_M3_ns/strings/strcmp.s":35, 0xfb7e480]
|
|
628 1 general_find_symbol(0xf49239d, 0x0, 0x0, 0x0, 0xf0000000, 0xf4923aa, 0x0, 0x492ddb2)
|
|
629 ["/comp2/mtibuild/v73/workarea/v7.3/rld/rld.c":2140, 0xfb65a98]
|
|
630 2 resolve_symbol(0xf49239d, 0x4031184, 0x0, 0xfbdd438, 0x0, 0xf4923aa, 0x0, 0x492ddb2)
|
|
631 ["/comp2/mtibuild/v73/workarea/v7.3/rld/rld.c":1947, 0xfb657e4]
|
|
632 3 lazy_text_resolve(0xd18, 0x1a3, 0x40302b4, 0x12, 0xf0000000, 0xf4923aa, 0x0, 0x492ddb2)
|
|
633 ["/comp2/mtibuild/v73/workarea/v7.3/rld/rld.c":997, 0xfb64d44]
|
|
634 4 _rld_text_resolve(0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
|
|
635 ["/comp2/mtibuild/v73/workarea/v7.3/rld/rld_bridge.s":175, 0xfb6032c]
|
|
636
|
|
637 (`rld' is the dynamic linker.) We don't know yet why this
|
|
638 happens, but setting the environment variable LD_BIND_NOW to 1 (which
|
|
639 forces the dynamic linker to bind all shared objects early on) seems
|
|
640 to work around the problem.
|
|
641
|
|
642 Please refer to the documentation of your dynamic linker for details.
|
|
643
|
|
644 *** You request inverse video, and the first Emacs frame is in inverse
|
|
645 video, but later frames are not in inverse video.
|
|
646
|
|
647 This can happen if you have an old version of the custom library in
|
|
648 your search path for Lisp packages. Use M-x list-load-path-shadows to
|
|
649 check whether this is true. If it is, delete the old custom library.
|
|
650
|
|
651 *** When you run Ispell from Emacs, it reports a "misalignment" error.
|
|
652
|
|
653 This can happen if you compiled the Ispell program to use ASCII
|
|
654 characters only and then try to use it from Emacs with non-ASCII
|
|
655 characters, like Latin-1. The solution is to recompile Ispell with
|
|
656 support for 8-bit characters.
|
|
657
|
|
658 To see whether your Ispell program supports 8-bit characters, type
|
|
659 this at your shell's prompt:
|
|
660
|
|
661 ispell -vv
|
|
662
|
|
663 and look in the output for the string "NO8BIT". If Ispell says
|
|
664 "!NO8BIT (8BIT)", your speller supports 8-bit characters; otherwise it
|
|
665 does not.
|
|
666
|
|
667 To rebuild Ispell with 8-bit character support, edit the local.h file
|
|
668 in the Ispell distribution and make sure it does _not_ define NO8BIT.
|
|
669 Then rebuild the speller.
|
|
670
|
|
671 Another possible cause for "misalignment" error messages is that the
|
|
672 version of Ispell installed on your machine is old. Upgrade.
|
|
673
|
|
674 Yet another possibility is that you are trying to spell-check a word
|
|
675 in a language that doesn't fit the dictionary you choose for use by
|
|
676 Ispell. (Ispell can only spell-check one language at a time, because
|
|
677 it uses a single dictionary.) Make sure that the text you are
|
|
678 spelling and the dictionary used by Ispell conform to each other.
|
|
679
|
|
680 If your spell-checking program is Aspell, it has been reported that if
|
|
681 you have a personal configuration file (normally ~/.aspell.conf), it
|
|
682 can cause this error. Remove that file, execute `ispell-kill-ispell'
|
|
683 in Emacs, and then try spell-checking again.
|
|
684
|
|
685 * Runtime problems related to font handling
|
|
686
|
99131
|
687 ** Characters are displayed as empty boxes or with wrong font under X.
|
|
688
|
|
689 *** This can occur when two different versions of FontConfig are used.
|
|
690 For example, XFree86 4.3.0 has one version and Gnome usually comes
|
|
691 with a newer version. Emacs compiled with Gtk+ will then use the
|
|
692 newer version. In most cases the problem can be temporarily fixed by
|
|
693 stopping the application that has the error (it can be Emacs or any
|
|
694 other application), removing ~/.fonts.cache-1, and then start the
|
|
695 application again. If removing ~/.fonts.cache-1 and restarting
|
|
696 doesn't help, the application with problem must be recompiled with the
|
|
697 same version of FontConfig as the rest of the system uses. For KDE,
|
|
698 it is sufficient to recompile Qt.
|
|
699
|
|
700 *** Some fonts have a missing glyph and no default character. This is
|
|
701 known to occur for character number 160 (no-break space) in some
|
|
702 fonts, such as Lucida but Emacs sets the display table for the unibyte
|
|
703 and Latin-1 version of this character to display a space.
|
|
704
|
|
705 *** Some of the fonts called for in your fontset may not exist on your
|
|
706 X server.
|
56734
|
707
|
|
708 Each X11 font covers just a fraction of the characters that Emacs
|
|
709 supports. To display the whole range of Emacs characters requires
|
99131
|
710 many different fonts, collected into a fontset. You can remedy the
|
|
711 problem by installing additional fonts.
|
56734
|
712
|
|
713 The intlfonts distribution includes a full spectrum of fonts that can
|
71541
|
714 display all the characters Emacs supports. The etl-unicode collection
|
|
715 of fonts (available from <URL:ftp://ftp.x.org/contrib/fonts/> and
|
|
716 <URL:ftp://ftp.xfree86.org/pub/mirror/X.Org/contrib/fonts/>) includes
|
|
717 fonts that can display many Unicode characters; they can also be used
|
|
718 by ps-print and ps-mule to print Unicode characters.
|
56734
|
719
|
|
720 ** Under X11, some characters appear improperly aligned in their lines.
|
|
721
|
71541
|
722 You may have bad X11 fonts; try installing the intlfonts distribution
|
99131
|
723 or the etl-unicode collection (see above).
|
|
724
|
|
725 ** Under X, an unexpected monospace font is used as the default font.
|
|
726
|
|
727 When compiled with XFT, Emacs tries to use a default font named
|
|
728 "monospace". This is a "virtual font", which the operating system
|
|
729 (Fontconfig) redirects to a suitable font such as DejaVu Sans Mono.
|
|
730 On some systems, there exists a font that is actually named Monospace,
|
|
731 which takes over the virtual font. This is considered an operating
|
|
732 system bug; see
|
|
733
|
|
734 http://lists.gnu.org/archive/html/emacs-devel/2008-10/msg00696.html
|
|
735
|
|
736 If you encounter this problem, set the default font to a specific font
|
|
737 in your .Xresources or initialization file. For instance, you can put
|
|
738 the following in your .Xresources:
|
|
739
|
|
740 Emacs.font: DejaVu Sans Mono 12
|
|
741
|
|
742 ** Certain fonts make each line take one pixel more than it should.
|
|
743
|
|
744 This is because these fonts contain characters a little taller than
|
|
745 the font's nominal height. Emacs needs to make sure that lines do not
|
|
746 overlap.
|
56734
|
747
|
|
748 ** Loading fonts is very slow.
|
|
749
|
|
750 You might be getting scalable fonts instead of precomputed bitmaps.
|
|
751 Known scalable font directories are "Type1" and "Speedo". A font
|
|
752 directory contains scalable fonts if it contains the file
|
|
753 "fonts.scale".
|
|
754
|
|
755 If this is so, re-order your X windows font path to put the scalable
|
|
756 font directories last. See the documentation of `xset' for details.
|
|
757
|
|
758 With some X servers, it may be necessary to take the scalable font
|
|
759 directories out of your path entirely, at least for Emacs 19.26.
|
|
760 Changes in the future may make this unnecessary.
|
|
761
|
|
762 ** Font Lock displays portions of the buffer in incorrect faces.
|
|
763
|
|
764 By far the most frequent cause of this is a parenthesis `(' or a brace
|
|
765 `{' in column zero. Font Lock assumes that such a paren is outside of
|
|
766 any comment or string. This is of course not true in general, but the
|
|
767 vast majority of well-formatted program source files don't have such
|
|
768 parens, and therefore this assumption is used to allow optimizations
|
|
769 in Font Lock's syntactical analysis. These optimizations avoid some
|
|
770 pathological cases where jit-lock, the Just-in-Time fontification
|
|
771 introduced with Emacs 21.1, could significantly slow down scrolling
|
|
772 through the buffer, especially scrolling backwards, and also jumping
|
|
773 to the end of a very large buffer.
|
|
774
|
59996
|
775 Beginning with version 22.1, a parenthesis or a brace in column zero
|
56734
|
776 is highlighted in bold-red face if it is inside a string or a comment,
|
|
777 to indicate that it could interfere with Font Lock (and also with
|
|
778 indentation) and should be moved or escaped with a backslash.
|
|
779
|
|
780 If you don't use large buffers, or have a very fast machine which
|
|
781 makes the delays insignificant, you can avoid the incorrect
|
|
782 fontification by setting the variable
|
|
783 `font-lock-beginning-of-syntax-function' to a nil value. (This must
|
|
784 be done _after_ turning on Font Lock.)
|
|
785
|
|
786 Another alternative is to avoid a paren in column zero. For example,
|
|
787 in a Lisp string you could precede the paren with a backslash.
|
|
788
|
|
789 ** With certain fonts, when the cursor appears on a character, the
|
|
790 character doesn't appear--you get a solid box instead.
|
|
791
|
|
792 One user on a Linux-based GNU system reported that this problem went
|
|
793 away with installation of a new X server. The failing server was
|
|
794 XFree86 3.1.1. XFree86 3.1.2 works.
|
|
795
|
|
796 ** Emacs pauses for several seconds when changing the default font.
|
|
797
|
|
798 This has been reported for fvwm 2.2.5 and the window manager of KDE
|
|
799 2.1. The reason for the pause is Xt waiting for a ConfigureNotify
|
|
800 event from the window manager, which the window manager doesn't send.
|
|
801 Xt stops waiting after a default timeout of usually 5 seconds.
|
|
802
|
|
803 A workaround for this is to add something like
|
|
804
|
|
805 emacs.waitForWM: false
|
|
806
|
|
807 to your X resources. Alternatively, add `(wait-for-wm . nil)' to a
|
|
808 frame's parameter list, like this:
|
|
809
|
|
810 (modify-frame-parameters nil '((wait-for-wm . nil)))
|
|
811
|
|
812 (this should go into your `.emacs' file).
|
|
813
|
|
814 ** Underlines appear at the wrong position.
|
|
815
|
|
816 This is caused by fonts having a wrong UNDERLINE_POSITION property.
|
|
817 Examples are the font 7x13 on XFree prior to version 4.1, or the jmk
|
94606
|
818 neep font from the Debian xfonts-jmk package prior to version 3.0.17.
|
|
819 To circumvent this problem, set x-use-underline-position-properties
|
|
820 to nil in your `.emacs'.
|
56734
|
821
|
|
822 To see what is the value of UNDERLINE_POSITION defined by the font,
|
108807
|
823 type `xlsfonts -lll FONT' and look at the font's UNDERLINE_POSITION property.
|
56734
|
824
|
|
825 ** When using Exceed, fonts sometimes appear too tall.
|
|
826
|
|
827 When the display is set to an Exceed X-server and fonts are specified
|
|
828 (either explicitly with the -fn option or implicitly with X resources)
|
|
829 then the fonts may appear "too tall". The actual character sizes are
|
|
830 correct but there is too much vertical spacing between rows, which
|
|
831 gives the appearance of "double spacing".
|
|
832
|
|
833 To prevent this, turn off the Exceed's "automatic font substitution"
|
|
834 feature (in the font part of the configuration window).
|
|
835
|
78910
|
836 ** Subscript/superscript text in TeX is hard to read.
|
|
837
|
84961
|
838 If `tex-fontify-script' is non-nil, tex-mode displays
|
|
839 subscript/superscript text in the faces subscript/superscript, which
|
|
840 are smaller than the normal font and lowered/raised. With some fonts,
|
|
841 nested superscripts (say) can be hard to read. Switching to a
|
|
842 different font, or changing your antialiasing setting (on an LCD
|
|
843 screen), can both make the problem disappear. Alternatively, customize
|
|
844 the following variables: tex-font-script-display (how much to
|
|
845 lower/raise); tex-suscript-height-ratio (how much smaller than
|
|
846 normal); tex-suscript-height-minimum (minimum height).
|
78910
|
847
|
56734
|
848 * Internationalization problems
|
|
849
|
73155
|
850 ** M-{ does not work on a Spanish PC keyboard.
|
|
851
|
|
852 Many Spanish keyboards seem to ignore that combination. Emacs can't
|
|
853 do anything about it.
|
|
854
|
105000
|
855 ** International characters aren't displayed under X.
|
|
856
|
|
857 *** Missing X fonts
|
47994
|
858
|
|
859 XFree86 4 contains many fonts in iso10646-1 encoding which have
|
51316
|
860 minimal character repertoires (whereas the encoding part of the font
|
|
861 name is meant to be a reasonable indication of the repertoire
|
|
862 according to the XLFD spec). Emacs may choose one of these to display
|
|
863 characters from the mule-unicode charsets and then typically won't be
|
|
864 able to find the glyphs to display many characters. (Check with C-u
|
|
865 C-x = .) To avoid this, you may need to use a fontset which sets the
|
|
866 font for the mule-unicode sets explicitly. E.g. to use GNU unifont,
|
|
867 include in the fontset spec:
|
47994
|
868
|
|
869 mule-unicode-2500-33ff:-gnu-unifont-*-iso10646-1,\
|
|
870 mule-unicode-e000-ffff:-gnu-unifont-*-iso10646-1,\
|
|
871 mule-unicode-0100-24ff:-gnu-unifont-*-iso10646-1
|
|
872
|
56734
|
873 ** The UTF-8/16/7 coding systems don't encode CJK (Far Eastern) characters.
|
51316
|
874
|
65518
|
875 Emacs directly supports the Unicode BMP whose code points are in the
|
|
876 ranges 0000-33ff and e000-ffff, and indirectly supports the parts of
|
|
877 CJK characters belonging to these legacy charsets:
|
|
878
|
|
879 GB2312, Big5, JISX0208, JISX0212, JISX0213-1, JISX0213-2, KSC5601
|
|
880
|
|
881 The latter support is done in Utf-Translate-Cjk mode (turned on by
|
|
882 default). Which Unicode CJK characters are decoded into which Emacs
|
|
883 charset is decided by the current language environment. For instance,
|
|
884 in Chinese-GB, most of them are decoded into chinese-gb2312.
|
51316
|
885
|
|
886 If you read UTF-8 data with code points outside these ranges, the
|
|
887 characters appear in the buffer as raw bytes of the original UTF-8
|
|
888 (composed into a single quasi-character) and they will be written back
|
|
889 correctly as UTF-8, assuming you don't break the composed sequences.
|
|
890 If you read such characters from UTF-16 or UTF-7 data, they are
|
|
891 substituted with the Unicode `replacement character', and you lose
|
|
892 information.
|
|
893
|
56734
|
894 ** Accented ISO-8859-1 characters are displayed as | or _.
|
34721
|
895
|
|
896 Try other font set sizes (S-mouse-1). If the problem persists with
|
|
897 other sizes as well, your text is corrupted, probably through software
|
|
898 that is not 8-bit clean. If the problem goes away with another font
|
|
899 size, it's probably because some fonts pretend to be ISO-8859-1 fonts
|
|
900 when they are really ASCII fonts. In particular the schumacher-clean
|
|
901 fonts have this bug in some versions of X.
|
|
902
|
|
903 To see what glyphs are included in a font, use `xfd', like this:
|
|
904
|
|
905 xfd -fn -schumacher-clean-medium-r-normal--12-120-75-75-c-60-iso8859-1
|
|
906
|
108807
|
907 If this shows only ASCII glyphs, the font is indeed the source of the problem.
|
34721
|
908
|
|
909 The solution is to remove the corresponding lines from the appropriate
|
|
910 `fonts.alias' file, then run `mkfontdir' in that directory, and then run
|
|
911 `xset fp rehash'.
|
|
912
|
56734
|
913 ** The `oc-unicode' package doesn't work with Emacs 21.
|
36112
|
914
|
36813
|
915 This package tries to define more private charsets than there are free
|
51132
|
916 slots now. The current built-in Unicode support is actually more
|
|
917 flexible. (Use option `utf-translate-cjk-mode' if you need CJK
|
|
918 support.) Files encoded as emacs-mule using oc-unicode aren't
|
|
919 generally read correctly by Emacs 21.
|
35645
|
920
|
56734
|
921 ** After a while, Emacs slips into unibyte mode.
|
25853
|
922
|
|
923 The VM mail package, which is not part of Emacs, sometimes does
|
|
924 (standard-display-european t)
|
49600
|
925 That should be changed to
|
25853
|
926 (standard-display-european 1 t)
|
|
927
|
56734
|
928 * X runtime problems
|
|
929
|
|
930 ** X keyboard problems
|
|
931
|
|
932 *** You "lose characters" after typing Compose Character key.
|
25853
|
933
|
|
934 This is because the Compose Character key is defined as the keysym
|
|
935 Multi_key, and Emacs (seeing that) does the proper X11
|
|
936 character-composition processing. If you don't want your Compose key
|
|
937 to do that, you can redefine it with xmodmap.
|
|
938
|
|
939 For example, here's one way to turn it into a Meta key:
|
|
940
|
|
941 xmodmap -e "keysym Multi_key = Meta_L"
|
|
942
|
|
943 If all users at your site of a particular keyboard prefer Meta to
|
|
944 Compose, you can make the remapping happen automatically by adding the
|
|
945 xmodmap command to the xdm setup script for that display.
|
|
946
|
56734
|
947 *** Using X Windows, control-shift-leftbutton makes Emacs hang.
|
|
948
|
|
949 Use the shell command `xset bc' to make the old X Menu package work.
|
|
950
|
69953
|
951 *** C-SPC fails to work on Fedora GNU/Linux (or with fcitx input method).
|
63756
|
952
|
|
953 Fedora Core 4 steals the C-SPC key by default for the `iiimx' program
|
|
954 which is the input method for some languages. It blocks Emacs users
|
|
955 from using the C-SPC key for `set-mark-command'.
|
|
956
|
|
957 One solutions is to remove the `<Ctrl>space' from the `Iiimx' file
|
|
958 which can be found in the `/usr/lib/X11/app-defaults' directory.
|
|
959 However, that requires root access.
|
|
960
|
|
961 Another is to specify `Emacs*useXIM: false' in your X resources.
|
|
962
|
|
963 Another is to build Emacs with the `--without-xim' configure option.
|
|
964
|
69926
|
965 The same problem happens on any other system if you are using fcitx
|
|
966 (Chinese input method) which by default use C-SPC for toggling. If
|
|
967 you want to use fcitx with Emacs, you have two choices. Toggle fcitx
|
|
968 by another key (e.g. C-\) by modifying ~/.fcitx/config, or be
|
|
969 accustomed to use C-@ for `set-mark-command'.
|
|
970
|
56734
|
971 *** M-SPC seems to be ignored as input.
|
|
972
|
|
973 See if your X server is set up to use this as a command
|
|
974 for character composition.
|
|
975
|
|
976 *** The S-C-t key combination doesn't get passed to Emacs on X.
|
|
977
|
|
978 This happens because some X configurations assign the Ctrl-Shift-t
|
|
979 combination the same meaning as the Multi_key. The offending
|
|
980 definition is in the file `...lib/X11/locale/iso8859-1/Compose'; there
|
|
981 might be other similar combinations which are grabbed by X for similar
|
|
982 purposes.
|
|
983
|
|
984 We think that this can be countermanded with the `xmodmap' utility, if
|
|
985 you want to be able to bind one of these key sequences within Emacs.
|
|
986
|
|
987 *** Under X, C-v and/or other keys don't work.
|
|
988
|
|
989 These may have been intercepted by your window manager. In
|
|
990 particular, AfterStep 1.6 is reported to steal C-v in its default
|
|
991 configuration. Various Meta keys are also likely to be taken by the
|
|
992 configuration of the `feel'. See the WM's documentation for how to
|
|
993 change this.
|
|
994
|
|
995 *** Clicking C-mouse-2 in the scroll bar doesn't split the window.
|
|
996
|
|
997 This currently doesn't work with scroll-bar widgets (and we don't know
|
|
998 a good way of implementing it with widgets). If Emacs is configured
|
|
999 --without-toolkit-scroll-bars, C-mouse-2 on the scroll bar does work.
|
|
1000
|
|
1001 *** Inability to send an Alt-modified key, when Emacs is communicating
|
25853
|
1002 directly with an X server.
|
|
1003
|
|
1004 If you have tried to bind an Alt-modified key as a command, and it
|
|
1005 does not work to type the command, the first thing you should check is
|
|
1006 whether the key is getting through to Emacs. To do this, type C-h c
|
|
1007 followed by the Alt-modified key. C-h c should say what kind of event
|
|
1008 it read. If it says it read an Alt-modified key, then make sure you
|
|
1009 have made the key binding correctly.
|
|
1010
|
|
1011 If C-h c reports an event that doesn't have the Alt modifier, it may
|
|
1012 be because your X server has no key for the Alt modifier. The X
|
108807
|
1013 server that comes from MIT does not set up the Alt modifier by default.
|
25853
|
1014
|
|
1015 If your keyboard has keys named Alt, you can enable them as follows:
|
|
1016
|
|
1017 xmodmap -e 'add mod2 = Alt_L'
|
|
1018 xmodmap -e 'add mod2 = Alt_R'
|
|
1019
|
|
1020 If the keyboard has just one key named Alt, then only one of those
|
|
1021 commands is needed. The modifier `mod2' is a reasonable choice if you
|
|
1022 are using an unmodified MIT version of X. Otherwise, choose any
|
|
1023 modifier bit not otherwise used.
|
|
1024
|
|
1025 If your keyboard does not have keys named Alt, you can use some other
|
|
1026 keys. Use the keysym command in xmodmap to turn a function key (or
|
|
1027 some other 'spare' key) into Alt_L or into Alt_R, and then use the
|
|
1028 commands show above to make them modifier keys.
|
|
1029
|
|
1030 Note that if you have Alt keys but no Meta keys, Emacs translates Alt
|
|
1031 into Meta. This is because of the great importance of Meta in Emacs.
|
|
1032
|
56734
|
1033 ** Window-manager and toolkit-related problems
|
|
1034
|
106268
|
1035 *** Metacity: Resizing Emacs or ALT-Tab causes X to be unresponsive.
|
|
1036
|
|
1037 This happens sometimes when using Metacity. Resizing Emacs or ALT-Tab:bing
|
|
1038 makes the system unresponsive to the mouse or the keyboard. Killing Emacs
|
109478
2660703dfff3
* PROBLEMS: Add note about use of backslashes in Windows paths.
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
1039 or shifting out from X11 and back again usually cures it (i.e. Ctrl-Alt-F1
|
106268
|
1040 and then Alt-F7). A bug for it is here:
|
|
1041 https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/231034.
|
|
1042 Note that a permanent fix seems to be to disable "assistive technologies".
|
|
1043
|
73196
8c94e11c22ec
* PROBLEMS: Document Emacs/XIM/gnome-settings-terminal clash.
Chong Yidong <cyd@stupidchicken.com>
diff
changeset
|
1044 *** Gnome: Emacs receives input directly from the keyboard, bypassing XIM.
|
8c94e11c22ec
* PROBLEMS: Document Emacs/XIM/gnome-settings-terminal clash.
Chong Yidong <cyd@stupidchicken.com>
diff
changeset
|
1045
|
8c94e11c22ec
* PROBLEMS: Document Emacs/XIM/gnome-settings-terminal clash.
Chong Yidong <cyd@stupidchicken.com>
diff
changeset
|
1046 This seems to happen when gnome-settings-daemon version 2.12 or later
|
8c94e11c22ec
* PROBLEMS: Document Emacs/XIM/gnome-settings-terminal clash.
Chong Yidong <cyd@stupidchicken.com>
diff
changeset
|
1047 is running. If gnome-settings-daemon is not running, Emacs receives
|
8c94e11c22ec
* PROBLEMS: Document Emacs/XIM/gnome-settings-terminal clash.
Chong Yidong <cyd@stupidchicken.com>
diff
changeset
|
1048 input through XIM without any problem. Furthermore, this seems only
|
8c94e11c22ec
* PROBLEMS: Document Emacs/XIM/gnome-settings-terminal clash.
Chong Yidong <cyd@stupidchicken.com>
diff
changeset
|
1049 to happen in *.UTF-8 locales; zh_CN.GB2312 and zh_CN.GBK locales, for
|
8c94e11c22ec
* PROBLEMS: Document Emacs/XIM/gnome-settings-terminal clash.
Chong Yidong <cyd@stupidchicken.com>
diff
changeset
|
1050 example, work fine. A bug report has been filed in the Gnome
|
8c94e11c22ec
* PROBLEMS: Document Emacs/XIM/gnome-settings-terminal clash.
Chong Yidong <cyd@stupidchicken.com>
diff
changeset
|
1051 bugzilla: http://bugzilla.gnome.org/show_bug.cgi?id=357032
|
8c94e11c22ec
* PROBLEMS: Document Emacs/XIM/gnome-settings-terminal clash.
Chong Yidong <cyd@stupidchicken.com>
diff
changeset
|
1052
|
56734
|
1053 *** Gnome: Emacs' xterm-mouse-mode doesn't work on the Gnome terminal.
|
|
1054
|
|
1055 A symptom of this bug is that double-clicks insert a control sequence
|
|
1056 into the buffer. The reason this happens is an apparent
|
|
1057 incompatibility of the Gnome terminal with Xterm, which also affects
|
|
1058 other programs using the Xterm mouse interface. A problem report has
|
|
1059 been filed.
|
|
1060
|
|
1061 *** KDE: When running on KDE, colors or fonts are not as specified for Emacs,
|
|
1062 or messed up.
|
|
1063
|
|
1064 For example, you could see background you set for Emacs only in the
|
|
1065 empty portions of the Emacs display, while characters have some other
|
|
1066 background.
|
|
1067
|
|
1068 This happens because KDE's defaults apply its color and font
|
|
1069 definitions even to applications that weren't compiled for KDE. The
|
|
1070 solution is to uncheck the "Apply fonts and colors to non-KDE apps"
|
|
1071 option in Preferences->Look&Feel->Style (KDE 2). In KDE 3, this option
|
|
1072 is in the "Colors" section, rather than "Style".
|
|
1073
|
|
1074 Alternatively, if you do want the KDE defaults to apply to other
|
|
1075 applications, but not to Emacs, you could modify the file `Emacs.ad'
|
|
1076 (should be in the `/usr/share/apps/kdisplay/app-defaults/' directory)
|
|
1077 so that it doesn't set the default background and foreground only for
|
|
1078 Emacs. For example, make sure the following resources are either not
|
|
1079 present or commented out:
|
|
1080
|
|
1081 Emacs.default.attributeForeground
|
|
1082 Emacs.default.attributeBackground
|
|
1083 Emacs*Foreground
|
|
1084 Emacs*Background
|
|
1085
|
78119
|
1086 It is also reported that a bug in the gtk-engines-qt engine can cause this if
|
|
1087 Emacs is compiled with Gtk+.
|
|
1088 The bug is fixed in version 0.7 or newer of gtk-engines-qt.
|
|
1089
|
56734
|
1090 *** KDE: Emacs hangs on KDE when a large portion of text is killed.
|
|
1091
|
|
1092 This is caused by a bug in the KDE applet `klipper' which periodically
|
|
1093 requests the X clipboard contents from applications. Early versions
|
67539
|
1094 of klipper don't implement the ICCCM protocol for large selections,
|
56734
|
1095 which leads to Emacs being flooded with selection requests. After a
|
58825
|
1096 while, Emacs may print a message:
|
56734
|
1097
|
|
1098 Timed out waiting for property-notify event
|
|
1099
|
58825
|
1100 A workaround is to not use `klipper'. An upgrade to the `klipper' that
|
|
1101 comes with KDE 3.3 or later also solves the problem.
|
56734
|
1102
|
|
1103 *** CDE: Frames may cover dialogs they created when using CDE.
|
|
1104
|
|
1105 This can happen if you have "Allow Primary Windows On Top" enabled which
|
|
1106 seems to be the default in the Common Desktop Environment.
|
|
1107 To change, go in to "Desktop Controls" -> "Window Style Manager"
|
|
1108 and uncheck "Allow Primary Windows On Top".
|
|
1109
|
|
1110 *** Xaw3d : When using Xaw3d scroll bars without arrows, the very first mouse
|
|
1111 click in a scroll bar might be ignored by the scroll bar widget. This
|
|
1112 is probably a bug in Xaw3d; when Xaw3d is compiled with arrows, the
|
|
1113 problem disappears.
|
|
1114
|
|
1115 *** Xaw: There are known binary incompatibilities between Xaw, Xaw3d, neXtaw,
|
|
1116 XawM and the few other derivatives of Xaw. So when you compile with
|
|
1117 one of these, it may not work to dynamically link with another one.
|
|
1118 For example, strange problems, such as Emacs exiting when you type
|
|
1119 "C-x 1", were reported when Emacs compiled with Xaw3d and libXaw was
|
|
1120 used with neXtaw at run time.
|
|
1121
|
|
1122 The solution is to rebuild Emacs with the toolkit version you actually
|
|
1123 want to use, or set LD_PRELOAD to preload the same toolkit version you
|
|
1124 built Emacs with.
|
|
1125
|
|
1126 *** Open Motif: Problems with file dialogs in Emacs built with Open Motif.
|
|
1127
|
|
1128 When Emacs 21 is built with Open Motif 2.1, it can happen that the
|
|
1129 graphical file dialog boxes do not work properly. The "OK", "Filter"
|
|
1130 and "Cancel" buttons do not respond to mouse clicks. Dragging the
|
|
1131 file dialog window usually causes the buttons to work again.
|
|
1132
|
|
1133 The solution is to use LessTif instead. LessTif is a free replacement
|
|
1134 for Motif. See the file INSTALL for information on how to do this.
|
|
1135
|
|
1136 Another workaround is not to use the mouse to trigger file prompts,
|
|
1137 but to use the keyboard. This way, you will be prompted for a file in
|
|
1138 the minibuffer instead of a graphical file dialog.
|
|
1139
|
|
1140 *** LessTif: Problems in Emacs built with LessTif.
|
|
1141
|
|
1142 The problems seem to depend on the version of LessTif and the Motif
|
|
1143 emulation for which it is set up.
|
|
1144
|
|
1145 Only the Motif 1.2 emulation seems to be stable enough in LessTif.
|
77139
|
1146 LessTif 0.92-17's Motif 1.2 emulation seems to work okay on FreeBSD.
|
56734
|
1147 On GNU/Linux systems, lesstif-0.92.6 configured with "./configure
|
|
1148 --enable-build-12 --enable-default-12" is reported to be the most
|
|
1149 successful. The binary GNU/Linux package
|
|
1150 lesstif-devel-0.92.0-1.i386.rpm was reported to have problems with
|
|
1151 menu placement.
|
|
1152
|
|
1153 On some systems, even with Motif 1.2 emulation, Emacs occasionally
|
|
1154 locks up, grabbing all mouse and keyboard events. We still don't know
|
108807
|
1155 what causes these problems; they are not reproducible by Emacs developers.
|
56734
|
1156
|
|
1157 *** Motif: The Motif version of Emacs paints the screen a solid color.
|
|
1158
|
|
1159 This has been observed to result from the following X resource:
|
|
1160
|
|
1161 Emacs*default.attributeFont: -*-courier-medium-r-*-*-*-140-*-*-*-*-iso8859-*
|
|
1162
|
|
1163 That the resource has this effect indicates a bug in something, but we
|
|
1164 do not yet know what. If it is an Emacs bug, we hope someone can
|
|
1165 explain what the bug is so we can fix it. In the mean time, removing
|
|
1166 the resource prevents the problem.
|
|
1167
|
|
1168 ** General X problems
|
|
1169
|
|
1170 *** Redisplay using X11 is much slower than previous Emacs versions.
|
|
1171
|
|
1172 We've noticed that certain X servers draw the text much slower when
|
|
1173 scroll bars are on the left. We don't know why this happens. If this
|
|
1174 happens to you, you can work around it by putting the scroll bars
|
|
1175 on the right (as they were in Emacs 19).
|
|
1176
|
|
1177 Here's how to do this:
|
|
1178
|
|
1179 (set-scroll-bar-mode 'right)
|
|
1180
|
|
1181 If you're not sure whether (or how much) this problem affects you,
|
|
1182 try that and see how much difference it makes. To set things back
|
|
1183 to normal, do
|
|
1184
|
|
1185 (set-scroll-bar-mode 'left)
|
|
1186
|
|
1187 *** Error messages about undefined colors on X.
|
|
1188
|
|
1189 The messages might say something like this:
|
|
1190
|
|
1191 Unable to load color "grey95"
|
|
1192
|
|
1193 (typically, in the `*Messages*' buffer), or something like this:
|
|
1194
|
|
1195 Error while displaying tooltip: (error Undefined color lightyellow)
|
|
1196
|
|
1197 These problems could happen if some other X program has used up too
|
|
1198 many colors of the X palette, leaving Emacs with insufficient system
|
|
1199 resources to load all the colors it needs.
|
|
1200
|
|
1201 A solution is to exit the offending X programs before starting Emacs.
|
|
1202
|
69398
|
1203 "undefined color" messages can also occur if the RgbPath entry in the
|
|
1204 X configuration file is incorrect, or the rgb.txt file is not where
|
|
1205 X expects to find it.
|
|
1206
|
56734
|
1207 *** Improving performance with slow X connections.
|
|
1208
|
|
1209 There are several ways to improve this performance, any subset of which can
|
|
1210 be carried out at the same time:
|
|
1211
|
|
1212 1) If you don't need X Input Methods (XIM) for entering text in some
|
|
1213 language you use, you can improve performance on WAN links by using
|
|
1214 the X resource useXIM to turn off use of XIM. This does not affect
|
|
1215 the use of Emacs' own input methods, which are part of the Leim
|
|
1216 package.
|
|
1217
|
|
1218 2) If the connection is very slow, you might also want to consider
|
75433
34fa35e88871
More details about disabling features that hamper performance with slow
Eli Zaretskii <eliz@gnu.org>
diff
changeset
|
1219 switching off scroll bars, menu bar, and tool bar. Adding the
|
34fa35e88871
More details about disabling features that hamper performance with slow
Eli Zaretskii <eliz@gnu.org>
diff
changeset
|
1220 following forms to your .emacs file will accomplish that, but only
|
34fa35e88871
More details about disabling features that hamper performance with slow
Eli Zaretskii <eliz@gnu.org>
diff
changeset
|
1221 after the the initial frame is displayed:
|
34fa35e88871
More details about disabling features that hamper performance with slow
Eli Zaretskii <eliz@gnu.org>
diff
changeset
|
1222
|
34fa35e88871
More details about disabling features that hamper performance with slow
Eli Zaretskii <eliz@gnu.org>
diff
changeset
|
1223 (scroll-bar-mode -1)
|
34fa35e88871
More details about disabling features that hamper performance with slow
Eli Zaretskii <eliz@gnu.org>
diff
changeset
|
1224 (menu-bar-mode -1)
|
34fa35e88871
More details about disabling features that hamper performance with slow
Eli Zaretskii <eliz@gnu.org>
diff
changeset
|
1225 (tool-bar-mode -1)
|
34fa35e88871
More details about disabling features that hamper performance with slow
Eli Zaretskii <eliz@gnu.org>
diff
changeset
|
1226
|
34fa35e88871
More details about disabling features that hamper performance with slow
Eli Zaretskii <eliz@gnu.org>
diff
changeset
|
1227 For still quicker startup, put these X resources in your .Xdefaults
|
34fa35e88871
More details about disabling features that hamper performance with slow
Eli Zaretskii <eliz@gnu.org>
diff
changeset
|
1228 file:
|
34fa35e88871
More details about disabling features that hamper performance with slow
Eli Zaretskii <eliz@gnu.org>
diff
changeset
|
1229
|
34fa35e88871
More details about disabling features that hamper performance with slow
Eli Zaretskii <eliz@gnu.org>
diff
changeset
|
1230 Emacs.verticalScrollBars: off
|
34fa35e88871
More details about disabling features that hamper performance with slow
Eli Zaretskii <eliz@gnu.org>
diff
changeset
|
1231 Emacs.menuBar: off
|
34fa35e88871
More details about disabling features that hamper performance with slow
Eli Zaretskii <eliz@gnu.org>
diff
changeset
|
1232 Emacs.toolBar: off
|
56734
|
1233
|
|
1234 3) Use ssh to forward the X connection, and enable compression on this
|
|
1235 forwarded X connection (ssh -XC remotehostname emacs ...).
|
|
1236
|
|
1237 4) Use lbxproxy on the remote end of the connection. This is an interface
|
|
1238 to the low bandwidth X extension in most modern X servers, which
|
|
1239 improves performance dramatically, at the slight expense of correctness
|
|
1240 of the X protocol. lbxproxy acheives the performance gain by grouping
|
|
1241 several X requests in one TCP packet and sending them off together,
|
77139
|
1242 instead of requiring a round-trip for each X request in a separate
|
56734
|
1243 packet. The switches that seem to work best for emacs are:
|
|
1244 -noatomsfile -nowinattr -cheaterrors -cheatevents
|
|
1245 Note that the -nograbcmap option is known to cause problems.
|
|
1246 For more about lbxproxy, see:
|
|
1247 http://www.xfree86.org/4.3.0/lbxproxy.1.html
|
|
1248
|
73631
|
1249 5) If copying and killing is slow, try to disable the interaction with the
|
|
1250 native system's clipboard by adding these lines to your .emacs file:
|
|
1251 (setq interprogram-cut-function nil)
|
|
1252 (setq interprogram-paste-function nil)
|
|
1253
|
56734
|
1254 *** Emacs gives the error, Couldn't find per display information.
|
|
1255
|
|
1256 This can result if the X server runs out of memory because Emacs uses
|
|
1257 a large number of fonts. On systems where this happens, C-h h is
|
|
1258 likely to cause it.
|
|
1259
|
|
1260 We do not know of a way to prevent the problem.
|
|
1261
|
|
1262 *** Emacs does not notice when you release the mouse.
|
|
1263
|
|
1264 There are reports that this happened with (some) Microsoft mice and
|
|
1265 that replacing the mouse made it stop.
|
|
1266
|
|
1267 *** You can't select from submenus (in the X toolkit version).
|
|
1268
|
|
1269 On certain systems, mouse-tracking and selection in top-level menus
|
|
1270 works properly with the X toolkit, but neither of them works when you
|
|
1271 bring up a submenu (such as Bookmarks or Compare or Apply Patch, in
|
|
1272 the Files menu).
|
|
1273
|
|
1274 This works on most systems. There is speculation that the failure is
|
|
1275 due to bugs in old versions of X toolkit libraries, but no one really
|
|
1276 knows. If someone debugs this and finds the precise cause, perhaps a
|
|
1277 workaround can be found.
|
|
1278
|
|
1279 *** An error message such as `X protocol error: BadMatch (invalid
|
|
1280 parameter attributes) on protocol request 93'.
|
|
1281
|
|
1282 This comes from having an invalid X resource, such as
|
|
1283 emacs*Cursor: black
|
|
1284 (which is invalid because it specifies a color name for something
|
|
1285 that isn't a color.)
|
|
1286
|
|
1287 The fix is to correct your X resources.
|
|
1288
|
|
1289 *** Slow startup on X11R6 with X windows.
|
|
1290
|
|
1291 If Emacs takes two minutes to start up on X11R6, see if your X
|
|
1292 resources specify any Adobe fonts. That causes the type-1 font
|
|
1293 renderer to start up, even if the font you asked for is not a type-1
|
|
1294 font.
|
|
1295
|
|
1296 One way to avoid this problem is to eliminate the type-1 fonts from
|
|
1297 your font path, like this:
|
|
1298
|
97732
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
1299 xset -fp /usr/X11R6/lib/X11/fonts/Type1/
|
56734
|
1300
|
|
1301 *** Pull-down menus appear in the wrong place, in the toolkit version of Emacs.
|
|
1302
|
|
1303 An X resource of this form can cause the problem:
|
|
1304
|
|
1305 Emacs*geometry: 80x55+0+0
|
|
1306
|
|
1307 This resource is supposed to apply, and does apply, to the menus
|
|
1308 individually as well as to Emacs frames. If that is not what you
|
|
1309 want, rewrite the resource.
|
|
1310
|
|
1311 To check thoroughly for such resource specifications, use `xrdb
|
|
1312 -query' to see what resources the X server records, and also look at
|
|
1313 the user's ~/.Xdefaults and ~/.Xdefaults-* files.
|
|
1314
|
|
1315 *** Emacs running under X Windows does not handle mouse clicks.
|
|
1316 *** `emacs -geometry 80x20' finds a file named `80x20'.
|
25853
|
1317
|
|
1318 One cause of such problems is having (setq term-file-prefix nil) in
|
|
1319 your .emacs file. Another cause is a bad value of EMACSLOADPATH in
|
|
1320 the environment.
|
|
1321
|
56734
|
1322 *** X Windows doesn't work if DISPLAY uses a hostname.
|
25853
|
1323
|
|
1324 People have reported kernel bugs in certain systems that cause Emacs
|
|
1325 not to work with X Windows if DISPLAY is set using a host name. But
|
|
1326 the problem does not occur if DISPLAY is set to `unix:0.0'. I think
|
|
1327 the bug has to do with SIGIO or FIONREAD.
|
|
1328
|
|
1329 You may be able to compensate for the bug by doing (set-input-mode nil nil).
|
|
1330 However, that has the disadvantage of turning off interrupts, so that
|
|
1331 you are unable to quit out of a Lisp program by typing C-g.
|
|
1332
|
97732
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
1333 *** Prevent double pastes in X
|
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
1334
|
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
1335 The problem: a region, such as a command, is pasted twice when you copy
|
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
1336 it with your mouse from GNU Emacs to an xterm or an RXVT shell in X.
|
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
1337 The solution: try the following in your X configuration file,
|
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
1338 /etc/X11/xorg.conf This should enable both PS/2 and USB mice for
|
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
1339 single copies. You do not need any other drivers or options.
|
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
1340
|
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
1341 Section "InputDevice"
|
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
1342 Identifier "Generic Mouse"
|
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
1343 Driver "mousedev"
|
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
1344 Option "Device" "/dev/input/mice"
|
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
1345 EndSection
|
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
1346
|
77139
|
1347 * Runtime problems on character terminals
|
56734
|
1348
|
107518
|
1349 ** The meta key does not work on xterm.
|
|
1350 Typing M-x rings the terminal bell, and inserts a string like ";120~".
|
|
1351 For recent xterm versions (>= 216), Emacs uses xterm's modifyOtherKeys
|
|
1352 feature to generate strings for key combinations that are not
|
|
1353 otherwise usable. One circumstance in which this can cause problems
|
|
1354 is if you have specified the X resource
|
|
1355
|
|
1356 xterm*VT100.Translations
|
|
1357
|
|
1358 to contain translations that use the meta key. Then xterm will not
|
|
1359 use meta in modified function-keys, which confuses Emacs. To fix
|
|
1360 this, you can remove the X resource or put this in your init file:
|
|
1361
|
|
1362 (xterm-remove-modify-other-keys)
|
|
1363
|
56734
|
1364 ** Emacs spontaneously displays "I-search: " at the bottom of the screen.
|
25853
|
1365
|
|
1366 This means that Control-S/Control-Q (XON/XOFF) "flow control" is being
|
|
1367 used. C-s/C-q flow control is bad for Emacs editors because it takes
|
|
1368 away C-s and C-q as user commands. Since editors do not output long
|
|
1369 streams of text without user commands, there is no need for a
|
|
1370 user-issuable "stop output" command in an editor; therefore, a
|
|
1371 properly designed flow control mechanism would transmit all possible
|
|
1372 input characters without interference. Designing such a mechanism is
|
|
1373 easy, for a person with at least half a brain.
|
|
1374
|
|
1375 There are three possible reasons why flow control could be taking place:
|
|
1376
|
|
1377 1) Terminal has not been told to disable flow control
|
|
1378 2) Insufficient padding for the terminal in use
|
|
1379 3) Some sort of terminal concentrator or line switch is responsible
|
|
1380
|
|
1381 First of all, many terminals have a set-up mode which controls whether
|
|
1382 they generate XON/XOFF flow control characters. This must be set to
|
103445
|
1383 "no XON/XOFF" in order for Emacs to work. (For example, on a VT220
|
|
1384 you may select "No XOFF" in the setup menu.) Sometimes there is an
|
25853
|
1385 escape sequence that the computer can send to turn flow control off
|
|
1386 and on. If so, perhaps the termcap `ti' string should turn flow
|
|
1387 control off, and the `te' string should turn it on.
|
|
1388
|
|
1389 Once the terminal has been told "no flow control", you may find it
|
|
1390 needs more padding. The amount of padding Emacs sends is controlled
|
|
1391 by the termcap entry for the terminal in use, and by the output baud
|
|
1392 rate as known by the kernel. The shell command `stty' will print
|
|
1393 your output baud rate; `stty' with suitable arguments will set it if
|
|
1394 it is wrong. Setting to a higher speed causes increased padding. If
|
|
1395 the results are wrong for the correct speed, there is probably a
|
|
1396 problem in the termcap entry. You must speak to a local Unix wizard
|
|
1397 to fix this. Perhaps you are just using the wrong terminal type.
|
|
1398
|
|
1399 For terminals that lack a "no flow control" mode, sometimes just
|
|
1400 giving lots of padding will prevent actual generation of flow control
|
|
1401 codes. You might as well try it.
|
|
1402
|
|
1403 If you are really unlucky, your terminal is connected to the computer
|
|
1404 through a concentrator which sends XON/XOFF flow control to the
|
|
1405 computer, or it insists on sending flow control itself no matter how
|
|
1406 much padding you give it. Unless you can figure out how to turn flow
|
|
1407 control off on this concentrator (again, refer to your local wizard),
|
|
1408 you are screwed! You should have the terminal or concentrator
|
|
1409 replaced with a properly designed one. In the mean time, some drastic
|
|
1410 measures can make Emacs semi-work.
|
|
1411
|
|
1412 You can make Emacs ignore C-s and C-q and let the operating system
|
|
1413 handle them. To do this on a per-session basis, just type M-x
|
|
1414 enable-flow-control RET. You will see a message that C-\ and C-^ are
|
|
1415 now translated to C-s and C-q. (Use the same command M-x
|
|
1416 enable-flow-control to turn *off* this special mode. It toggles flow
|
|
1417 control handling.)
|
|
1418
|
|
1419 If C-\ and C-^ are inconvenient for you (for example, if one of them
|
|
1420 is the escape character of your terminal concentrator), you can choose
|
|
1421 other characters by setting the variables flow-control-c-s-replacement
|
|
1422 and flow-control-c-q-replacement. But choose carefully, since all
|
|
1423 other control characters are already used by emacs.
|
|
1424
|
|
1425 IMPORTANT: if you type C-s by accident while flow control is enabled,
|
|
1426 Emacs output will freeze, and you will have to remember to type C-q in
|
|
1427 order to continue.
|
|
1428
|
|
1429 If you work in an environment where a majority of terminals of a
|
|
1430 certain type are flow control hobbled, you can use the function
|
|
1431 `enable-flow-control-on' to turn on this flow control avoidance scheme
|
|
1432 automatically. Here is an example:
|
|
1433
|
|
1434 (enable-flow-control-on "vt200" "vt300" "vt101" "vt131")
|
|
1435
|
|
1436 If this isn't quite correct (e.g. you have a mixture of flow-control hobbled
|
|
1437 and good vt200 terminals), you can still run enable-flow-control
|
|
1438 manually.
|
|
1439
|
|
1440 I have no intention of ever redesigning the Emacs command set for the
|
|
1441 assumption that terminals use C-s/C-q flow control. XON/XOFF flow
|
|
1442 control technique is a bad design, and terminals that need it are bad
|
|
1443 merchandise and should not be purchased. Now that X is becoming
|
|
1444 widespread, XON/XOFF seems to be on the way out. If you can get some
|
|
1445 use out of GNU Emacs on inferior terminals, more power to you, but I
|
|
1446 will not make Emacs worse for properly designed systems for the sake
|
|
1447 of inferior systems.
|
|
1448
|
56734
|
1449 ** Control-S and Control-Q commands are ignored completely.
|
25853
|
1450
|
|
1451 For some reason, your system is using brain-damaged C-s/C-q flow
|
|
1452 control despite Emacs's attempts to turn it off. Perhaps your
|
|
1453 terminal is connected to the computer through a concentrator
|
|
1454 that wants to use flow control.
|
|
1455
|
|
1456 You should first try to tell the concentrator not to use flow control.
|
|
1457 If you succeed in this, try making the terminal work without
|
|
1458 flow control, as described in the preceding section.
|
|
1459
|
|
1460 If that line of approach is not successful, map some other characters
|
|
1461 into C-s and C-q using keyboard-translate-table. The example above
|
|
1462 shows how to do this with C-^ and C-\.
|
|
1463
|
56734
|
1464 ** Screen is updated wrong, but only on one kind of terminal.
|
25853
|
1465
|
|
1466 This could mean that the termcap entry you are using for that
|
|
1467 terminal is wrong, or it could mean that Emacs has a bug handing
|
|
1468 the combination of features specified for that terminal.
|
|
1469
|
|
1470 The first step in tracking this down is to record what characters
|
|
1471 Emacs is sending to the terminal. Execute the Lisp expression
|
|
1472 (open-termscript "./emacs-script") to make Emacs write all
|
|
1473 terminal output into the file ~/emacs-script as well; then do
|
|
1474 what makes the screen update wrong, and look at the file
|
|
1475 and decode the characters using the manual for the terminal.
|
|
1476 There are several possibilities:
|
|
1477
|
|
1478 1) The characters sent are correct, according to the terminal manual.
|
|
1479
|
|
1480 In this case, there is no obvious bug in Emacs, and most likely you
|
|
1481 need more padding, or possibly the terminal manual is wrong.
|
|
1482
|
|
1483 2) The characters sent are incorrect, due to an obscure aspect
|
108807
|
1484 of the terminal behavior not described in an obvious way by termcap.
|
25853
|
1485
|
|
1486 This case is hard. It will be necessary to think of a way for
|
|
1487 Emacs to distinguish between terminals with this kind of behavior
|
|
1488 and other terminals that behave subtly differently but are
|
|
1489 classified the same by termcap; or else find an algorithm for
|
|
1490 Emacs to use that avoids the difference. Such changes must be
|
|
1491 tested on many kinds of terminals.
|
|
1492
|
|
1493 3) The termcap entry is wrong.
|
|
1494
|
|
1495 See the file etc/TERMS for information on changes
|
|
1496 that are known to be needed in commonly used termcap entries
|
|
1497 for certain terminals.
|
|
1498
|
|
1499 4) The characters sent are incorrect, and clearly cannot be
|
|
1500 right for any terminal with the termcap entry you were using.
|
|
1501
|
|
1502 This is unambiguously an Emacs bug, and can probably be fixed
|
|
1503 in termcap.c, tparam.c, term.c, scroll.c, cm.c or dispnew.c.
|
|
1504
|
56734
|
1505 ** Control-S and Control-Q commands are ignored completely on a net connection.
|
|
1506
|
|
1507 Some versions of rlogin (and possibly telnet) do not pass flow
|
|
1508 control characters to the remote system to which they connect.
|
|
1509 On such systems, emacs on the remote system cannot disable flow
|
108807
|
1510 control on the local system. Sometimes `rlogin -8' will avoid this problem.
|
56734
|
1511
|
|
1512 One way to cure this is to disable flow control on the local host
|
|
1513 (the one running rlogin, not the one running rlogind) using the
|
|
1514 stty command, before starting the rlogin process. On many systems,
|
103445
|
1515 "stty start u stop u" will do this. On some systems, use
|
109478
2660703dfff3
* PROBLEMS: Add note about use of backslashes in Windows paths.
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
1516 "stty -ixon" instead.
|
56734
|
1517
|
|
1518 Some versions of tcsh will prevent even this from working. One way
|
|
1519 around this is to start another shell before starting rlogin, and
|
|
1520 issue the stty command to disable flow control from that shell.
|
|
1521
|
|
1522 If none of these methods work, the best solution is to type
|
|
1523 M-x enable-flow-control at the beginning of your emacs session, or
|
|
1524 if you expect the problem to continue, add a line such as the
|
|
1525 following to your .emacs (on the host running rlogind):
|
|
1526
|
|
1527 (enable-flow-control-on "vt200" "vt300" "vt101" "vt131")
|
|
1528
|
108807
|
1529 See the entry about spontaneous display of I-search (above) for more info.
|
56734
|
1530
|
|
1531 ** Output from Control-V is slow.
|
25853
|
1532
|
|
1533 On many bit-map terminals, scrolling operations are fairly slow.
|
|
1534 Often the termcap entry for the type of terminal in use fails
|
|
1535 to inform Emacs of this. The two lines at the bottom of the screen
|
|
1536 before a Control-V command are supposed to appear at the top after
|
|
1537 the Control-V command. If Emacs thinks scrolling the lines is fast,
|
|
1538 it will scroll them to the top of the screen.
|
|
1539
|
|
1540 If scrolling is slow but Emacs thinks it is fast, the usual reason is
|
|
1541 that the termcap entry for the terminal you are using does not
|
|
1542 specify any padding time for the `al' and `dl' strings. Emacs
|
|
1543 concludes that these operations take only as much time as it takes to
|
|
1544 send the commands at whatever line speed you are using. You must
|
|
1545 fix the termcap entry to specify, for the `al' and `dl', as much
|
|
1546 time as the operations really take.
|
|
1547
|
|
1548 Currently Emacs thinks in terms of serial lines which send characters
|
|
1549 at a fixed rate, so that any operation which takes time for the
|
|
1550 terminal to execute must also be padded. With bit-map terminals
|
|
1551 operated across networks, often the network provides some sort of
|
|
1552 flow control so that padding is never needed no matter how slow
|
|
1553 an operation is. You must still specify a padding time if you want
|
|
1554 Emacs to realize that the operation takes a long time. This will
|
|
1555 cause padding characters to be sent unnecessarily, but they do
|
|
1556 not really cost much. They will be transmitted while the scrolling
|
|
1557 is happening and then discarded quickly by the terminal.
|
|
1558
|
|
1559 Most bit-map terminals provide commands for inserting or deleting
|
|
1560 multiple lines at once. Define the `AL' and `DL' strings in the
|
|
1561 termcap entry to say how to do these things, and you will have
|
|
1562 fast output without wasted padding characters. These strings should
|
|
1563 each contain a single %-spec saying how to send the number of lines
|
|
1564 to be scrolled. These %-specs are like those in the termcap
|
|
1565 `cm' string.
|
|
1566
|
|
1567 You should also define the `IC' and `DC' strings if your terminal
|
|
1568 has a command to insert or delete multiple characters. These
|
|
1569 take the number of positions to insert or delete as an argument.
|
|
1570
|
|
1571 A `cs' string to set the scrolling region will reduce the amount
|
|
1572 of motion you see on the screen when part of the screen is scrolled.
|
|
1573
|
56734
|
1574 ** You type Control-H (Backspace) expecting to delete characters.
|
25853
|
1575
|
|
1576 Put `stty dec' in your .login file and your problems will disappear
|
|
1577 after a day or two.
|
|
1578
|
|
1579 The choice of Backspace for erasure was based on confusion, caused by
|
|
1580 the fact that backspacing causes erasure (later, when you type another
|
|
1581 character) on most display terminals. But it is a mistake. Deletion
|
|
1582 of text is not the same thing as backspacing followed by failure to
|
|
1583 overprint. I do not wish to propagate this confusion by conforming
|
|
1584 to it.
|
|
1585
|
|
1586 For this reason, I believe `stty dec' is the right mode to use,
|
|
1587 and I have designed Emacs to go with that. If there were a thousand
|
|
1588 other control characters, I would define Control-h to delete as well;
|
|
1589 but there are not very many other control characters, and I think
|
|
1590 that providing the most mnemonic possible Help character is more
|
|
1591 important than adapting to people who don't use `stty dec'.
|
|
1592
|
|
1593 If you are obstinate about confusing buggy overprinting with deletion,
|
|
1594 you can redefine Backspace in your .emacs file:
|
|
1595 (global-set-key "\b" 'delete-backward-char)
|
|
1596 You can probably access help-command via f1.
|
|
1597
|
56734
|
1598 ** Colors are not available on a tty or in xterm.
|
|
1599
|
|
1600 Emacs 21 supports colors on character terminals and terminal
|
|
1601 emulators, but this support relies on the terminfo or termcap database
|
|
1602 entry to specify that the display supports color. Emacs looks at the
|
|
1603 "Co" capability for the terminal to find out how many colors are
|
|
1604 supported; it should be non-zero to activate the color support within
|
|
1605 Emacs. (Most color terminals support 8 or 16 colors.) If your system
|
|
1606 uses terminfo, the name of the capability equivalent to "Co" is
|
|
1607 "colors".
|
|
1608
|
|
1609 In addition to the "Co" capability, Emacs needs the "op" (for
|
|
1610 ``original pair'') capability, which tells how to switch the terminal
|
|
1611 back to the default foreground and background colors. Emacs will not
|
|
1612 use colors if this capability is not defined. If your terminal entry
|
|
1613 doesn't provide such a capability, try using the ANSI standard escape
|
|
1614 sequence \E[00m (that is, define a new termcap/terminfo entry and make
|
|
1615 it use your current terminal's entry plus \E[00m for the "op"
|
|
1616 capability).
|
|
1617
|
|
1618 Finally, the "NC" capability (terminfo name: "ncv") tells Emacs which
|
|
1619 attributes cannot be used with colors. Setting this capability
|
|
1620 incorrectly might have the effect of disabling colors; try setting
|
|
1621 this capability to `0' (zero) and see if that helps.
|
|
1622
|
|
1623 Emacs uses the database entry for the terminal whose name is the value
|
|
1624 of the environment variable TERM. With `xterm', a common terminal
|
|
1625 entry that supports color is `xterm-color', so setting TERM's value to
|
|
1626 `xterm-color' might activate the color support on an xterm-compatible
|
|
1627 emulator.
|
|
1628
|
59996
|
1629 Beginning with version 22.1, Emacs supports the --color command-line
|
56734
|
1630 option which may be used to force Emacs to use one of a few popular
|
|
1631 modes for getting colors on a tty. For example, --color=ansi8 sets up
|
|
1632 for using the ANSI-standard escape sequences that support 8 colors.
|
|
1633
|
|
1634 Some modes do not use colors unless you turn on the Font-lock mode.
|
|
1635 Some people have long ago set their `~/.emacs' files to turn on
|
|
1636 Font-lock on X only, so they won't see colors on a tty. The
|
|
1637 recommended way of turning on Font-lock is by typing "M-x
|
|
1638 global-font-lock-mode RET" or by customizing the variable
|
|
1639 `global-font-lock-mode'.
|
|
1640
|
|
1641 * Runtime problems specific to individual Unix variants
|
|
1642
|
|
1643 ** GNU/Linux
|
|
1644
|
63126
|
1645 *** GNU/Linux: Process output is corrupted.
|
|
1646
|
|
1647 There is a bug in Linux kernel 2.6.10 PTYs that can cause emacs to
|
|
1648 read corrupted process output.
|
|
1649
|
|
1650 *** GNU/Linux: Remote access to CVS with SSH causes file corruption.
|
|
1651
|
|
1652 If you access a remote CVS repository via SSH, files may be corrupted
|
|
1653 due to bad interaction between CVS, SSH, and libc.
|
|
1654
|
|
1655 To fix the problem, save the following script into a file, make it
|
|
1656 executable, and set CVS_RSH environment variable to the file name of
|
|
1657 the script:
|
|
1658
|
|
1659 #!/bin/bash
|
|
1660 exec 2> >(exec cat >&2 2>/dev/null)
|
|
1661 exec ssh "$@"
|
|
1662
|
56734
|
1663 *** GNU/Linux: On Linux-based GNU systems using libc versions 5.4.19 through
|
|
1664 5.4.22, Emacs crashes at startup with a segmentation fault.
|
|
1665
|
|
1666 This problem happens if libc defines the symbol __malloc_initialized.
|
|
1667 One known solution is to upgrade to a newer libc version. 5.4.33 is
|
|
1668 known to work.
|
|
1669
|
|
1670 *** GNU/Linux: After upgrading to a newer version of Emacs,
|
|
1671 the Meta key stops working.
|
|
1672
|
|
1673 This was reported to happen on a GNU/Linux system distributed by
|
|
1674 Mandrake. The reason is that the previous version of Emacs was
|
|
1675 modified by Mandrake to make the Alt key act as the Meta key, on a
|
|
1676 keyboard where the Windows key is the one which produces the Meta
|
|
1677 modifier. A user who started using a newer version of Emacs, which
|
|
1678 was not hacked by Mandrake, expected the Alt key to continue to act as
|
|
1679 Meta, and was astonished when that didn't happen.
|
|
1680
|
|
1681 The solution is to find out what key on your keyboard produces the Meta
|
|
1682 modifier, and use that key instead. Try all of the keys to the left
|
|
1683 and to the right of the space bar, together with the `x' key, and see
|
|
1684 which combination produces "M-x" in the echo area. You can also use
|
|
1685 the `xmodmap' utility to show all the keys which produce a Meta
|
|
1686 modifier:
|
|
1687
|
|
1688 xmodmap -pk | egrep -i "meta|alt"
|
|
1689
|
|
1690 A more convenient way of finding out which keys produce a Meta modifier
|
|
1691 is to use the `xkbprint' utility, if it's available on your system:
|
|
1692
|
|
1693 xkbprint 0:0 /tmp/k.ps
|
|
1694
|
|
1695 This produces a PostScript file `/tmp/k.ps' with a picture of your
|
|
1696 keyboard; printing that file on a PostScript printer will show what
|
|
1697 keys can serve as Meta.
|
|
1698
|
|
1699 The `xkeycaps' also shows a visual representation of the current
|
|
1700 keyboard settings. It also allows to modify them.
|
|
1701
|
71200
|
1702 *** GNU/Linux: slow startup on Linux-based GNU systems.
|
56734
|
1703
|
|
1704 People using systems based on the Linux kernel sometimes report that
|
|
1705 startup takes 10 to 15 seconds longer than `usual'.
|
|
1706
|
|
1707 This is because Emacs looks up the host name when it starts.
|
|
1708 Normally, this takes negligible time; the extra delay is due to
|
|
1709 improper system configuration. This problem can occur for both
|
|
1710 networked and non-networked machines.
|
|
1711
|
|
1712 Here is how to fix the configuration. It requires being root.
|
|
1713
|
|
1714 **** Networked Case.
|
|
1715
|
|
1716 First, make sure the files `/etc/hosts' and `/etc/host.conf' both
|
|
1717 exist. The first line in the `/etc/hosts' file should look like this
|
|
1718 (replace HOSTNAME with your host name):
|
|
1719
|
|
1720 127.0.0.1 HOSTNAME
|
|
1721
|
|
1722 Also make sure that the `/etc/host.conf' files contains the following
|
|
1723 lines:
|
|
1724
|
|
1725 order hosts, bind
|
|
1726 multi on
|
|
1727
|
|
1728 Any changes, permanent and temporary, to the host name should be
|
|
1729 indicated in the `/etc/hosts' file, since it acts a limited local
|
|
1730 database of addresses and names (e.g., some SLIP connections
|
|
1731 dynamically allocate ip addresses).
|
|
1732
|
|
1733 **** Non-Networked Case.
|
|
1734
|
|
1735 The solution described in the networked case applies here as well.
|
|
1736 However, if you never intend to network your machine, you can use a
|
|
1737 simpler solution: create an empty `/etc/host.conf' file. The command
|
|
1738 `touch /etc/host.conf' suffices to create the file. The `/etc/hosts'
|
|
1739 file is not necessary with this approach.
|
|
1740
|
|
1741 *** GNU/Linux: Emacs on a tty switches the cursor to large blinking block.
|
|
1742
|
|
1743 This was reported to happen on some GNU/Linux systems which use
|
|
1744 ncurses version 5.0, but could be relevant for other versions as well.
|
|
1745 These versions of ncurses come with a `linux' terminfo entry, where
|
|
1746 the "cvvis" capability (termcap "vs") is defined as "\E[?25h\E[?8c"
|
|
1747 (show cursor, change size). This escape sequence switches on a
|
|
1748 blinking hardware text-mode cursor whose size is a full character
|
|
1749 cell. This blinking cannot be stopped, since a hardware cursor
|
|
1750 always blinks.
|
|
1751
|
|
1752 A work-around is to redefine the "cvvis" capability so that it
|
|
1753 enables a *software* cursor. The software cursor works by inverting
|
|
1754 the colors of the character at point, so what you see is a block
|
|
1755 cursor that doesn't blink. For this to work, you need to redefine
|
|
1756 the "cnorm" capability as well, so that it operates on the software
|
|
1757 cursor instead of the hardware cursor.
|
|
1758
|
|
1759 To this end, run "infocmp linux > linux-term", edit the file
|
|
1760 `linux-term' to make both the "cnorm" and "cvvis" capabilities send
|
|
1761 the sequence "\E[?25h\E[?17;0;64c", and then run "tic linux-term" to
|
|
1762 produce a modified terminfo entry.
|
|
1763
|
|
1764 Alternatively, if you want a blinking underscore as your Emacs cursor,
|
|
1765 change the "cvvis" capability to send the "\E[?25h\E[?0c" command.
|
|
1766
|
|
1767 *** GNU/Linux: Error messages `internal facep []' happen on GNU/Linux systems.
|
|
1768
|
|
1769 There is a report that replacing libc.so.5.0.9 with libc.so.5.2.16
|
|
1770 caused this to start happening. People are not sure why, but the
|
|
1771 problem seems unlikely to be in Emacs itself. Some suspect that it
|
|
1772 is actually Xlib which won't work with libc.so.5.2.16.
|
|
1773
|
|
1774 Using the old library version is a workaround.
|
|
1775
|
|
1776 ** FreeBSD
|
|
1777
|
|
1778 *** FreeBSD 2.1.5: useless symbolic links remain in /tmp or other
|
|
1779 directories that have the +t bit.
|
|
1780
|
|
1781 This is because of a kernel bug in FreeBSD 2.1.5 (fixed in 2.2).
|
|
1782 Emacs uses symbolic links to implement file locks. In a directory
|
|
1783 with +t bit, the directory owner becomes the owner of the symbolic
|
|
1784 link, so that it cannot be removed by anyone else.
|
|
1785
|
|
1786 If you don't like those useless links, you can let Emacs not to using
|
|
1787 file lock by adding #undef CLASH_DETECTION to config.h.
|
|
1788
|
|
1789 *** FreeBSD: Getting a Meta key on the console.
|
|
1790
|
|
1791 By default, neither Alt nor any other key acts as a Meta key on
|
|
1792 FreeBSD, but this can be changed using kbdcontrol(1). Dump the
|
|
1793 current keymap to a file with the command
|
|
1794
|
|
1795 $ kbdcontrol -d >emacs.kbd
|
|
1796
|
|
1797 Edit emacs.kbd, and give the key you want to be the Meta key the
|
|
1798 definition `meta'. For instance, if your keyboard has a ``Windows''
|
|
1799 key with scan code 105, change the line for scan code 105 in emacs.kbd
|
|
1800 to look like this
|
|
1801
|
|
1802 105 meta meta meta meta meta meta meta meta O
|
|
1803
|
|
1804 to make the Windows key the Meta key. Load the new keymap with
|
|
1805
|
|
1806 $ kbdcontrol -l emacs.kbd
|
|
1807
|
|
1808 ** HP-UX
|
|
1809
|
|
1810 *** HP/UX : Shell mode gives the message, "`tty`: Ambiguous".
|
|
1811
|
|
1812 christos@theory.tn.cornell.edu says:
|
|
1813
|
|
1814 The problem is that in your .cshrc you have something that tries to
|
|
1815 execute `tty`. If you are not running the shell on a real tty then
|
|
1816 tty will print "not a tty". Csh expects one word in some places,
|
|
1817 but tty is giving it back 3.
|
|
1818
|
|
1819 The solution is to add a pair of quotes around `tty` to make it a single
|
|
1820 word:
|
|
1821
|
|
1822 if (`tty` == "/dev/console")
|
|
1823
|
|
1824 should be changed to:
|
|
1825
|
|
1826 if ("`tty`" == "/dev/console")
|
|
1827
|
|
1828 Even better, move things that set up terminal sections out of .cshrc
|
|
1829 and into .login.
|
|
1830
|
|
1831 *** HP/UX: `Pid xxx killed due to text modification or page I/O error'.
|
|
1832
|
|
1833 On HP/UX, you can get that error when the Emacs executable is on an NFS
|
|
1834 file system. HP/UX responds this way if it tries to swap in a page and
|
|
1835 does not get a response from the server within a timeout whose default
|
|
1836 value is just ten seconds.
|
|
1837
|
|
1838 If this happens to you, extend the timeout period.
|
|
1839
|
|
1840 *** HP/UX: The right Alt key works wrong on German HP keyboards (and perhaps
|
|
1841 other non-English HP keyboards too).
|
|
1842
|
|
1843 This is because HP-UX defines the modifiers wrong in X. Here is a
|
|
1844 shell script to fix the problem; be sure that it is run after VUE
|
|
1845 configures the X server.
|
|
1846
|
|
1847 xmodmap 2> /dev/null - << EOF
|
|
1848 keysym Alt_L = Meta_L
|
|
1849 keysym Alt_R = Meta_R
|
|
1850 EOF
|
|
1851
|
|
1852 xmodmap - << EOF
|
|
1853 clear mod1
|
|
1854 keysym Mode_switch = NoSymbol
|
|
1855 add mod1 = Meta_L
|
|
1856 keysym Meta_R = Mode_switch
|
|
1857 add mod2 = Mode_switch
|
|
1858 EOF
|
|
1859
|
|
1860 *** HP/UX: "Cannot find callback list" messages from dialog boxes in
|
|
1861 Emacs built with Motif.
|
|
1862
|
|
1863 This problem resulted from a bug in GCC 2.4.5. Newer GCC versions
|
|
1864 such as 2.7.0 fix the problem.
|
|
1865
|
|
1866 *** HP/UX: Emacs does not recognize the AltGr key.
|
|
1867
|
|
1868 To fix this, set up a file ~/.dt/sessions/sessionetc with executable
|
|
1869 rights, containing this text:
|
|
1870
|
|
1871 --------------------------------
|
|
1872 xmodmap 2> /dev/null - << EOF
|
|
1873 keysym Alt_L = Meta_L
|
|
1874 keysym Alt_R = Meta_R
|
|
1875 EOF
|
|
1876
|
|
1877 xmodmap - << EOF
|
|
1878 clear mod1
|
|
1879 keysym Mode_switch = NoSymbol
|
|
1880 add mod1 = Meta_L
|
|
1881 keysym Meta_R = Mode_switch
|
|
1882 add mod2 = Mode_switch
|
|
1883 EOF
|
|
1884 --------------------------------
|
|
1885
|
|
1886 *** HP/UX 11.0: Emacs makes HP/UX 11.0 crash.
|
|
1887
|
|
1888 This is a bug in HPUX; HPUX patch PHKL_16260 is said to fix it.
|
|
1889
|
|
1890 ** AIX
|
|
1891
|
|
1892 *** AIX: Trouble using ptys.
|
|
1893
|
|
1894 People often install the pty devices on AIX incorrectly.
|
|
1895 Use `smit pty' to reinstall them properly.
|
|
1896
|
|
1897 *** AIXterm: Your Delete key sends a Backspace to the terminal.
|
|
1898
|
|
1899 The solution is to include in your .Xdefaults the lines:
|
|
1900
|
|
1901 *aixterm.Translations: #override <Key>BackSpace: string(0x7f)
|
|
1902 aixterm*ttyModes: erase ^?
|
|
1903
|
|
1904 This makes your Backspace key send DEL (ASCII 127).
|
|
1905
|
|
1906 *** AIX: If linking fails because libXbsd isn't found, check if you
|
|
1907 are compiling with the system's `cc' and CFLAGS containing `-O5'. If
|
|
1908 so, you have hit a compiler bug. Please make sure to re-configure
|
|
1909 Emacs so that it isn't compiled with `-O5'.
|
|
1910
|
|
1911 *** AIX 4.3.x or 4.4: Compiling fails.
|
|
1912
|
|
1913 This could happen if you use /bin/c89 as your compiler, instead of
|
|
1914 the default `cc'. /bin/c89 treats certain warnings, such as benign
|
|
1915 redefinitions of macros, as errors, and fails the build. A solution
|
|
1916 is to use the default compiler `cc'.
|
|
1917
|
|
1918 *** AIX 4: Some programs fail when run in a Shell buffer
|
|
1919 with an error message like No terminfo entry for "unknown".
|
|
1920
|
|
1921 On AIX, many terminal type definitions are not installed by default.
|
|
1922 `unknown' is one of them. Install the "Special Generic Terminal
|
|
1923 Definitions" to make them defined.
|
|
1924
|
|
1925 ** Solaris
|
|
1926
|
108807
|
1927 We list bugs in current versions here. See also the section on legacy
|
|
1928 systems.
|
56734
|
1929
|
|
1930 *** On Solaris, C-x doesn't get through to Emacs when you use the console.
|
|
1931
|
|
1932 This is a Solaris feature (at least on Intel x86 cpus). Type C-r
|
|
1933 C-r C-t, to toggle whether C-x gets through to Emacs.
|
|
1934
|
|
1935 *** Problem with remote X server on Suns.
|
|
1936
|
|
1937 On a Sun, running Emacs on one machine with the X server on another
|
|
1938 may not work if you have used the unshared system libraries. This
|
|
1939 is because the unshared libraries fail to use YP for host name lookup.
|
|
1940 As a result, the host name you specify may not be recognized.
|
|
1941
|
108807
|
1942 *** Solaris 2.6: Emacs crashes with SIGBUS or SIGSEGV on Solaris after you delete a frame.
|
56914
|
1943
|
|
1944 We suspect that this is a bug in the X libraries provided by
|
|
1945 Sun. There is a report that one of these patches fixes the bug and
|
|
1946 makes the problem stop:
|
|
1947
|
|
1948 105216-01 105393-01 105518-01 105621-01 105665-01 105615-02 105216-02
|
|
1949 105667-01 105401-08 105615-03 105621-02 105686-02 105736-01 105755-03
|
|
1950 106033-01 105379-01 105786-01 105181-04 105379-03 105786-04 105845-01
|
|
1951 105284-05 105669-02 105837-01 105837-02 105558-01 106125-02 105407-01
|
|
1952
|
|
1953 Another person using a newer system (kernel patch level Generic_105181-06)
|
|
1954 suspects that the bug was fixed by one of these more recent patches:
|
|
1955
|
|
1956 106040-07 SunOS 5.6: X Input & Output Method patch
|
|
1957 106222-01 OpenWindows 3.6: filemgr (ff.core) fixes
|
|
1958 105284-12 Motif 1.2.7: sparc Runtime library patch
|
|
1959
|
|
1960 *** Solaris 7 or 8: Emacs reports a BadAtom error (from X)
|
56734
|
1961
|
|
1962 This happens when Emacs was built on some other version of Solaris.
|
|
1963 Rebuild it on Solaris 8.
|
|
1964
|
56914
|
1965 *** When using M-x dbx with the SparcWorks debugger, the `up' and `down'
|
|
1966 commands do not move the arrow in Emacs.
|
|
1967
|
|
1968 You can fix this by adding the following line to `~/.dbxinit':
|
|
1969
|
|
1970 dbxenv output_short_file_name off
|
|
1971
|
56734
|
1972 *** On Solaris, CTRL-t is ignored by Emacs when you use
|
|
1973 the fr.ISO-8859-15 locale (and maybe other related locales).
|
|
1974
|
|
1975 You can fix this by editing the file:
|
|
1976
|
97732
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
1977 /usr/openwin/lib/locale/iso8859-15/Compose
|
56734
|
1978
|
|
1979 Near the bottom there is a line that reads:
|
|
1980
|
97732
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
1981 Ctrl<t> <quotedbl> <Y> : "\276" threequarters
|
56734
|
1982
|
|
1983 that should read:
|
|
1984
|
97732
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
1985 Ctrl<T> <quotedbl> <Y> : "\276" threequarters
|
56734
|
1986
|
|
1987 Note the lower case <t>. Changing this line should make C-t work.
|
|
1988
|
80121
|
1989 *** On Solaris, Emacs fails to set menu-bar-update-hook on startup, with error
|
|
1990 "Error in menu-bar-update-hook: (error Point before start of properties)".
|
|
1991 This seems to be a GCC optimization bug that occurs for GCC 4.1.2 (-g
|
|
1992 and -g -O2) and GCC 4.2.3 (-g -O and -g -O2). You can fix this by
|
|
1993 compiling with GCC 4.2.3 or CC 5.7, with no optimizations.
|
|
1994
|
56734
|
1995 ** Irix
|
|
1996
|
|
1997 *** Irix 6.5: Emacs crashes on the SGI R10K, when compiled with GCC.
|
|
1998
|
|
1999 This seems to be fixed in GCC 2.95.
|
|
2000
|
56914
|
2001 *** Irix: Trouble using ptys, or running out of ptys.
|
56734
|
2002
|
|
2003 The program mkpts (which may be in `/usr/adm' or `/usr/sbin') needs to
|
|
2004 be set-UID to root, or non-root programs like Emacs will not be able
|
|
2005 to allocate ptys reliably.
|
|
2006
|
|
2007 * Runtime problems specific to MS-Windows
|
|
2008
|
101624
6033e5211761
* PROBLEMS (Windows): Add entry about TCC/4NT and App Paths keys.
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
2009 ** PATH can contain unexpanded environment variables
|
6033e5211761
* PROBLEMS (Windows): Add entry about TCC/4NT and App Paths keys.
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
2010
|
6033e5211761
* PROBLEMS (Windows): Add entry about TCC/4NT and App Paths keys.
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
2011 Old releases of TCC (version 9) and 4NT (up to version 8) do not correctly
|
6033e5211761
* PROBLEMS (Windows): Add entry about TCC/4NT and App Paths keys.
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
2012 expand App Paths entries of type REG_EXPAND_SZ. When Emacs is run from TCC
|
6033e5211761
* PROBLEMS (Windows): Add entry about TCC/4NT and App Paths keys.
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
2013 and such an entry exists for emacs.exe, exec-path will contain the
|
6033e5211761
* PROBLEMS (Windows): Add entry about TCC/4NT and App Paths keys.
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
2014 unexpanded entry. This has been fixed in TCC 10. For more information,
|
6033e5211761
* PROBLEMS (Windows): Add entry about TCC/4NT and App Paths keys.
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
2015 see bug#2062.
|
6033e5211761
* PROBLEMS (Windows): Add entry about TCC/4NT and App Paths keys.
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
2016
|
101445
|
2017 ** Setting w32-pass-rwindow-to-system and w32-pass-lwindow-to-system to nil
|
|
2018 does not prevent the Start menu from popping up when the left or right
|
|
2019 ``Windows'' key is pressed.
|
|
2020
|
|
2021 This was reported to happen when XKeymacs is installed. At least with
|
|
2022 XKeymacs Version 3.47, deactivating XKeymacs when Emacs is active is
|
|
2023 not enough to avoid its messing with the keyboard input. Exiting
|
|
2024 XKeymacs completely is reported to solve the problem.
|
|
2025
|
71902
|
2026 ** Windows 95 and networking.
|
|
2027
|
|
2028 To support server sockets, Emacs 22.1 loads ws2_32.dll. If this file
|
|
2029 is missing, all Emacs networking features are disabled.
|
|
2030
|
|
2031 Old versions of Windows 95 may not have the required DLL. To use
|
|
2032 Emacs' networking features on Windows 95, you must install the
|
|
2033 "Windows Socket 2" update available from MicroSoft's support Web.
|
|
2034
|
56734
|
2035 ** Emacs exits with "X protocol error" when run with an X server for MS-Windows.
|
|
2036
|
|
2037 A certain X server for Windows had a bug which caused this.
|
|
2038 Supposedly the newer 32-bit version of this server doesn't have the
|
|
2039 problem.
|
|
2040
|
80730
|
2041 ** Emacs crashes when opening a file with a UNC path and rails-mode is loaded.
|
|
2042
|
|
2043 Loading rails-mode seems to interfere with UNC path handling. This has been
|
|
2044 reported as a bug against both Emacs and rails-mode, so look for an updated
|
|
2045 rails-mode that avoids this crash, or avoid using UNC paths if using
|
|
2046 rails-mode.
|
|
2047
|
|
2048 ** Known problems with the MS-Windows port of Emacs 22.3
|
66452
50f2dd53cf9a
Added note about create-fontset-from-ascii-font problem on MS-Windows.
Jason Rumney <jasonr@gnu.org>
diff
changeset
|
2049
|
80338
|
2050 M-x term does not work on MS-Windows. TTY emulation on Windows is
|
|
2051 undocumented, and programs such as stty which are used on posix platforms
|
|
2052 to control tty emulation do not exist for native windows terminals.
|
|
2053
|
66452
50f2dd53cf9a
Added note about create-fontset-from-ascii-font problem on MS-Windows.
Jason Rumney <jasonr@gnu.org>
diff
changeset
|
2054 Using create-fontset-from-ascii-font or the --font startup parameter
|
50f2dd53cf9a
Added note about create-fontset-from-ascii-font problem on MS-Windows.
Jason Rumney <jasonr@gnu.org>
diff
changeset
|
2055 with a Chinese, Japanese or Korean font leads to display problems.
|
50f2dd53cf9a
Added note about create-fontset-from-ascii-font problem on MS-Windows.
Jason Rumney <jasonr@gnu.org>
diff
changeset
|
2056 Use a Latin-only font as your default font. If you want control over
|
50f2dd53cf9a
Added note about create-fontset-from-ascii-font problem on MS-Windows.
Jason Rumney <jasonr@gnu.org>
diff
changeset
|
2057 which font is used to display Chinese, Japanese or Korean character,
|
50f2dd53cf9a
Added note about create-fontset-from-ascii-font problem on MS-Windows.
Jason Rumney <jasonr@gnu.org>
diff
changeset
|
2058 use create-fontset-from-fontset-spec to define a fontset.
|
56734
|
2059
|
|
2060 Frames are not refreshed while the File or Font dialog or a pop-up menu
|
|
2061 is displayed. This also means help text for pop-up menus is not
|
|
2062 displayed at all. This is because message handling under Windows is
|
|
2063 synchronous, so we cannot handle repaint (or any other) messages while
|
|
2064 waiting for a system function to return the result of the dialog or
|
|
2065 pop-up menu interaction.
|
|
2066
|
|
2067 Windows 95 and Windows NT up to version 4.0 do not support help text
|
|
2068 for menus. Help text is only available in later versions of Windows.
|
|
2069
|
77076
|
2070 When "ClearType" method is selected as the "method to smooth edges of
|
|
2071 screen fonts" (in Display Properties, Appearance tab, under
|
|
2072 "Effects"), there are various problems related to display of
|
80125
|
2073 characters: Bold fonts can be hard to read, small portions of some
|
|
2074 characters could appear chopped, etc. This happens because, under
|
|
2075 ClearType, characters are drawn outside their advertised bounding box.
|
|
2076 Emacs 21 disabled the use of ClearType, whereas Emacs 22 allows it and
|
|
2077 has some code to enlarge the width of the bounding box. Apparently,
|
|
2078 this display feature needs more changes to get it 100% right. A
|
|
2079 workaround is to disable ClearType.
|
77076
|
2080
|
56734
|
2081 There are problems with display if mouse-tracking is enabled and the
|
|
2082 mouse is moved off a frame, over another frame then back over the first
|
|
2083 frame. A workaround is to click the left mouse button inside the frame
|
|
2084 after moving back into it.
|
|
2085
|
|
2086 Some minor flickering still persists during mouse-tracking, although
|
|
2087 not as severely as in 21.1.
|
|
2088
|
|
2089 An inactive cursor remains in an active window after the Windows
|
|
2090 Manager driven switch of the focus, until a key is pressed.
|
|
2091
|
77047
|
2092 Windows input methods are not recognized by Emacs. However, some
|
56734
|
2093 of these input methods cause the keyboard to send characters encoded
|
|
2094 in the appropriate coding system (e.g., ISO 8859-1 for Latin-1
|
77047
|
2095 characters, ISO 8859-8 for Hebrew characters, etc.). To make these
|
|
2096 input methods work with Emacs, set the keyboard coding system to the
|
|
2097 appropriate value after you activate the Windows input method. For
|
|
2098 example, if you activate the Hebrew input method, type this:
|
|
2099
|
|
2100 C-x RET k hebrew-iso-8bit RET
|
|
2101
|
|
2102 (Emacs ought to recognize the Windows language-change event and set up
|
|
2103 the appropriate keyboard encoding automatically, but it doesn't do
|
|
2104 that yet.) In addition, to use these Windows input methods, you
|
|
2105 should set your "Language for non-Unicode programs" (on Windows XP,
|
|
2106 this is on the Advanced tab of Regional Settings) to the language of
|
|
2107 the input method.
|
56734
|
2108
|
76824
|
2109 To bind keys that produce non-ASCII characters with modifiers, you
|
|
2110 must specify raw byte codes. For instance, if you want to bind
|
|
2111 META-a-grave to a command, you need to specify this in your `~/.emacs':
|
|
2112
|
|
2113 (global-set-key [?\M-\340] ...)
|
|
2114
|
|
2115 The above example is for the Latin-1 environment where the byte code
|
|
2116 of the encoded a-grave is 340 octal. For other environments, use the
|
|
2117 encoding appropriate to that environment.
|
|
2118
|
56734
|
2119 The %b specifier for format-time-string does not produce abbreviated
|
|
2120 month names with consistent widths for some locales on some versions
|
|
2121 of Windows. This is caused by a deficiency in the underlying system
|
|
2122 library function.
|
|
2123
|
79164
|
2124 The function set-time-zone-rule gives incorrect results for many
|
|
2125 non-US timezones. This is due to over-simplistic handling of
|
|
2126 daylight savings switchovers by the Windows libraries.
|
79130
|
2127
|
77518
|
2128 Files larger than 4GB cause overflow in the size (represented as a
|
|
2129 32-bit integer) reported by `file-attributes'. This affects Dired as
|
|
2130 well, since the Windows port uses a Lisp emulation of `ls' that relies
|
|
2131 on `file-attributes'.
|
|
2132
|
78014
|
2133 Sound playing is not supported with the `:data DATA' key-value pair.
|
|
2134 You _must_ use the `:file FILE' method.
|
|
2135
|
56734
|
2136 ** Typing Alt-Shift has strange effects on MS-Windows.
|
|
2137
|
|
2138 This combination of keys is a command to change keyboard layout. If
|
|
2139 you proceed to type another non-modifier key before you let go of Alt
|
|
2140 and Shift, the Alt and Shift act as modifiers in the usual way. A
|
|
2141 more permanent work around is to change it to another key combination,
|
79444
2eb513da4da5
Provide exact information about customizing Alt-Shift on Windows XP.
Eli Zaretskii <eliz@gnu.org>
diff
changeset
|
2142 or disable it in the "Regional and Language Options" applet of the
|
2eb513da4da5
Provide exact information about customizing Alt-Shift on Windows XP.
Eli Zaretskii <eliz@gnu.org>
diff
changeset
|
2143 Control Panel. (The exact sequence of mouse clicks in the "Regional
|
2eb513da4da5
Provide exact information about customizing Alt-Shift on Windows XP.
Eli Zaretskii <eliz@gnu.org>
diff
changeset
|
2144 and Language Options" applet needed to find the key combination that
|
2eb513da4da5
Provide exact information about customizing Alt-Shift on Windows XP.
Eli Zaretskii <eliz@gnu.org>
diff
changeset
|
2145 changes the keyboard layout depends on your Windows version; for XP,
|
2eb513da4da5
Provide exact information about customizing Alt-Shift on Windows XP.
Eli Zaretskii <eliz@gnu.org>
diff
changeset
|
2146 in the Languages tab, click "Details" and then "Key Settings".)
|
56734
|
2147
|
|
2148 ** Interrupting Cygwin port of Bash from Emacs doesn't work.
|
|
2149
|
|
2150 Cygwin 1.x builds of the ported Bash cannot be interrupted from the
|
|
2151 MS-Windows version of Emacs. This is due to some change in the Bash
|
|
2152 port or in the Cygwin library which apparently make Bash ignore the
|
|
2153 keyboard interrupt event sent by Emacs to Bash. (Older Cygwin ports
|
|
2154 of Bash, up to b20.1, did receive SIGINT from Emacs.)
|
|
2155
|
|
2156 ** Accessing remote files with ange-ftp hangs the MS-Windows version of Emacs.
|
|
2157
|
|
2158 If the FTP client is the Cygwin port of GNU `ftp', this appears to be
|
|
2159 due to some bug in the Cygwin DLL or some incompatibility between it
|
|
2160 and the implementation of asynchronous subprocesses in the Windows
|
|
2161 port of Emacs. Specifically, some parts of the FTP server responses
|
|
2162 are not flushed out, apparently due to buffering issues, which
|
|
2163 confuses ange-ftp.
|
|
2164
|
|
2165 The solution is to downgrade to an older version of the Cygwin DLL
|
|
2166 (version 1.3.2 was reported to solve the problem), or use the stock
|
|
2167 Windows FTP client, usually found in the `C:\WINDOWS' or 'C:\WINNT'
|
|
2168 directory. To force ange-ftp use the stock Windows client, set the
|
|
2169 variable `ange-ftp-ftp-program-name' to the absolute file name of the
|
|
2170 client's executable. For example:
|
|
2171
|
|
2172 (setq ange-ftp-ftp-program-name "c:/windows/ftp.exe")
|
|
2173
|
|
2174 If you want to stick with the Cygwin FTP client, you can work around
|
|
2175 this problem by putting this in your `.emacs' file:
|
|
2176
|
|
2177 (setq ange-ftp-ftp-program-args '("-i" "-n" "-g" "-v" "--prompt" "")
|
|
2178
|
|
2179 ** lpr commands don't work on MS-Windows with some cheap printers.
|
|
2180
|
|
2181 This problem may also strike other platforms, but the solution is
|
|
2182 likely to be a global one, and not Emacs specific.
|
|
2183
|
|
2184 Many cheap inkjet, and even some cheap laser printers, do not
|
|
2185 print plain text anymore, they will only print through graphical
|
|
2186 printer drivers. A workaround on MS-Windows is to use Windows' basic
|
|
2187 built in editor to print (this is possibly the only useful purpose it
|
|
2188 has):
|
|
2189
|
|
2190 (setq printer-name "") ;; notepad takes the default
|
|
2191 (setq lpr-command "notepad") ;; notepad
|
|
2192 (setq lpr-switches nil) ;; not needed
|
|
2193 (setq lpr-printer-switch "/P") ;; run notepad as batch printer
|
|
2194
|
|
2195 ** Antivirus software interacts badly with the MS-Windows version of Emacs.
|
|
2196
|
|
2197 The usual manifestation of these problems is that subprocesses don't
|
|
2198 work or even wedge the entire system. In particular, "M-x shell RET"
|
|
2199 was reported to fail to work. But other commands also sometimes don't
|
|
2200 work when an antivirus package is installed.
|
|
2201
|
|
2202 The solution is to switch the antivirus software to a less aggressive
|
|
2203 mode (e.g., disable the ``auto-protect'' feature), or even uninstall
|
|
2204 or disable it entirely.
|
|
2205
|
|
2206 ** Pressing the mouse button on MS-Windows does not give a mouse-2 event.
|
|
2207
|
|
2208 This is usually a problem with the mouse driver. Because most Windows
|
|
2209 programs do not do anything useful with the middle mouse button, many
|
|
2210 mouse drivers allow you to define the wheel press to do something
|
|
2211 different. Some drivers do not even have the option to generate a
|
|
2212 middle button press. In such cases, setting the wheel press to
|
|
2213 "scroll" sometimes works if you press the button twice. Trying a
|
|
2214 generic mouse driver might help.
|
|
2215
|
|
2216 ** Scrolling the mouse wheel on MS-Windows always scrolls the top window.
|
|
2217
|
|
2218 This is another common problem with mouse drivers. Instead of
|
|
2219 generating scroll events, some mouse drivers try to fake scroll bar
|
|
2220 movement. But they are not intelligent enough to handle multiple
|
|
2221 scroll bars within a frame. Trying a generic mouse driver might help.
|
|
2222
|
|
2223 ** Mail sent through Microsoft Exchange in some encodings appears to be
|
|
2224 mangled and is not seen correctly in Rmail or Gnus. We don't know
|
|
2225 exactly what happens, but it isn't an Emacs problem in cases we've
|
|
2226 seen.
|
|
2227
|
|
2228 ** On MS-Windows, you cannot use the right-hand ALT key and the left-hand
|
|
2229 CTRL key together to type a Control-Meta character.
|
|
2230
|
|
2231 This is a consequence of a misfeature beyond Emacs's control.
|
|
2232
|
|
2233 Under Windows, the AltGr key on international keyboards generates key
|
|
2234 events with the modifiers Right-Alt and Left-Ctrl. Since Emacs cannot
|
|
2235 distinguish AltGr from an explicit Right-Alt and Left-Ctrl
|
|
2236 combination, whenever it sees Right-Alt and Left-Ctrl it assumes that
|
|
2237 AltGr has been pressed. The variable `w32-recognize-altgr' can be set
|
|
2238 to nil to tell Emacs that AltGr is really Ctrl and Alt.
|
|
2239
|
|
2240 ** Under some X-servers running on MS-Windows, Emacs' display is incorrect.
|
|
2241
|
|
2242 The symptoms are that Emacs does not completely erase blank areas of the
|
|
2243 screen during scrolling or some other screen operations (e.g., selective
|
|
2244 display or when killing a region). M-x recenter will cause the screen
|
|
2245 to be completely redisplayed and the "extra" characters will disappear.
|
|
2246
|
|
2247 This is known to occur under Exceed 6, and possibly earlier versions
|
|
2248 as well; it is reportedly solved in version 6.2.0.16 and later. The
|
|
2249 problem lies in the X-server settings.
|
|
2250
|
|
2251 There are reports that you can solve the problem with Exceed by
|
|
2252 running `Xconfig' from within NT, choosing "X selection", then
|
|
2253 un-checking the boxes "auto-copy X selection" and "auto-paste to X
|
|
2254 selection".
|
|
2255
|
|
2256 Of this does not work, please inform bug-gnu-emacs@gnu.org. Then
|
|
2257 please call support for your X-server and see if you can get a fix.
|
108807
|
2258 If you do, please send it to bug-gnu-emacs@gnu.org so we can list it here.
|
56734
|
2259
|
|
2260 * Build-time problems
|
|
2261
|
|
2262 ** Configuration
|
|
2263
|
|
2264 *** The `configure' script doesn't find the jpeg library.
|
|
2265
|
|
2266 There are reports that this happens on some systems because the linker
|
|
2267 by default only looks for shared libraries, but jpeg distribution by
|
|
2268 default only installs a nonshared version of the library, `libjpeg.a'.
|
|
2269
|
|
2270 If this is the problem, you can configure the jpeg library with the
|
|
2271 `--enable-shared' option and then rebuild libjpeg. This produces a
|
|
2272 shared version of libjpeg, which you need to install. Finally, rerun
|
|
2273 the Emacs configure script, which should now find the jpeg library.
|
|
2274 Alternatively, modify the generated src/Makefile to link the .a file
|
|
2275 explicitly, and edit src/config.h to define HAVE_JPEG.
|
|
2276
|
76934
6586f81fbf80
(Configuration): Add entries on compiler/preprocessor mismatch, and on
Glenn Morris <rgm@gnu.org>
diff
changeset
|
2277 *** `configure' warns ``accepted by the compiler, rejected by the preprocessor''.
|
6586f81fbf80
(Configuration): Add entries on compiler/preprocessor mismatch, and on
Glenn Morris <rgm@gnu.org>
diff
changeset
|
2278
|
6586f81fbf80
(Configuration): Add entries on compiler/preprocessor mismatch, and on
Glenn Morris <rgm@gnu.org>
diff
changeset
|
2279 This indicates a mismatch between the C compiler and preprocessor that
|
6586f81fbf80
(Configuration): Add entries on compiler/preprocessor mismatch, and on
Glenn Morris <rgm@gnu.org>
diff
changeset
|
2280 configure is using. For example, on Solaris 10 trying to use
|
6586f81fbf80
(Configuration): Add entries on compiler/preprocessor mismatch, and on
Glenn Morris <rgm@gnu.org>
diff
changeset
|
2281 CC=/opt/SUNWspro/bin/cc (the Sun Studio compiler) together with
|
6586f81fbf80
(Configuration): Add entries on compiler/preprocessor mismatch, and on
Glenn Morris <rgm@gnu.org>
diff
changeset
|
2282 CPP=/usr/ccs/lib/cpp can result in errors of this form (you may also
|
6586f81fbf80
(Configuration): Add entries on compiler/preprocessor mismatch, and on
Glenn Morris <rgm@gnu.org>
diff
changeset
|
2283 see the error ``"/usr/include/sys/isa_defs.h", line 500: undefined control'').
|
6586f81fbf80
(Configuration): Add entries on compiler/preprocessor mismatch, and on
Glenn Morris <rgm@gnu.org>
diff
changeset
|
2284
|
6586f81fbf80
(Configuration): Add entries on compiler/preprocessor mismatch, and on
Glenn Morris <rgm@gnu.org>
diff
changeset
|
2285 The solution is to tell configure to use the correct C preprocessor
|
6586f81fbf80
(Configuration): Add entries on compiler/preprocessor mismatch, and on
Glenn Morris <rgm@gnu.org>
diff
changeset
|
2286 for your C compiler (CPP="/opt/SUNWspro/bin/cc -E" in the above
|
6586f81fbf80
(Configuration): Add entries on compiler/preprocessor mismatch, and on
Glenn Morris <rgm@gnu.org>
diff
changeset
|
2287 example).
|
6586f81fbf80
(Configuration): Add entries on compiler/preprocessor mismatch, and on
Glenn Morris <rgm@gnu.org>
diff
changeset
|
2288
|
56734
|
2289 ** Compilation
|
|
2290
|
|
2291 *** Building Emacs over NFS fails with ``Text file busy''.
|
|
2292
|
|
2293 This was reported to happen when building Emacs on a GNU/Linux system
|
77139
|
2294 (Red Hat Linux 6.2) using a build directory automounted from Solaris
|
56734
|
2295 (SunOS 5.6) file server, but it might not be limited to that
|
|
2296 configuration alone. Presumably, the NFS server doesn't commit the
|
|
2297 files' data to disk quickly enough, and the Emacs executable file is
|
|
2298 left ``busy'' for several seconds after Emacs has finished dumping
|
|
2299 itself. This causes the subsequent commands which invoke the dumped
|
|
2300 Emacs executable to fail with the above message.
|
|
2301
|
|
2302 In some of these cases, a time skew between the NFS server and the
|
|
2303 machine where Emacs is built is detected and reported by GNU Make
|
|
2304 (it says that some of the files have modification time in the future).
|
|
2305 This might be a symptom of NFS-related problems.
|
|
2306
|
|
2307 If the NFS server runs on Solaris, apply the Solaris patch 105379-05
|
|
2308 (Sunos 5.6: /kernel/misc/nfssrv patch). If that doesn't work, or if
|
|
2309 you have a different version of the OS or the NFS server, you can
|
|
2310 force the NFS server to use 1KB blocks, which was reported to fix the
|
|
2311 problem albeit at a price of slowing down file I/O. You can force 1KB
|
|
2312 blocks by specifying the "-o rsize=1024,wsize=1024" options to the
|
|
2313 `mount' command, or by adding ",rsize=1024,wsize=1024" to the mount
|
|
2314 options in the appropriate system configuration file, such as
|
|
2315 `/etc/auto.home'.
|
|
2316
|
|
2317 Alternatively, when Make fails due to this problem, you could wait for
|
|
2318 a few seconds and then invoke Make again. In one particular case,
|
|
2319 waiting for 10 or more seconds between the two Make invocations seemed
|
|
2320 to work around the problem.
|
|
2321
|
|
2322 Similar problems can happen if your machine NFS-mounts a directory
|
|
2323 onto itself. Suppose the Emacs sources live in `/usr/local/src' and
|
|
2324 you are working on the host called `marvin'. Then an entry in the
|
|
2325 `/etc/fstab' file like the following is asking for trouble:
|
|
2326
|
|
2327 marvin:/usr/local/src /usr/local/src ...options.omitted...
|
|
2328
|
|
2329 The solution is to remove this line from `etc/fstab'.
|
|
2330
|
75211
|
2331 *** Building a 32-bit executable on a 64-bit GNU/Linux architecture.
|
|
2332
|
|
2333 First ensure that the necessary 32-bit system libraries and include
|
|
2334 files are installed. Then use:
|
|
2335
|
|
2336 env CC="gcc -m32" ./configure --build=i386-linux-gnu \
|
|
2337 --x-libraries=/usr/X11R6/lib
|
|
2338
|
|
2339 (using the location of the 32-bit X libraries on your system).
|
|
2340
|
109245
|
2341 *** Building Emacs for Cygwin can fail with GCC 3
|
|
2342
|
|
2343 As of Emacs 22.1, there have been stability problems with Cygwin
|
|
2344 builds of Emacs using GCC 3. Cygwin users are advised to use GCC 4.
|
73673
|
2345
|
109692
|
2346 *** Building Emacs 23.3 and later will fail under Cygwin 1.5.19
|
|
2347
|
|
2348 This is a consequence of a change to src/dired.c on 2010-07-27. The
|
|
2349 issue is that Cygwin 1.5.19 did not have d_ino in 'struct dirent'.
|
|
2350 See
|
|
2351
|
|
2352 http://lists.gnu.org/archive/html/emacs-devel/2010-07/msg01266.html
|
|
2353
|
107685
|
2354 *** Building the native MS-Windows port fails due to unresolved externals
|
|
2355
|
|
2356 The linker error messages look like this:
|
|
2357
|
|
2358 oo-spd/i386/ctags.o:ctags.c:(.text+0x156e): undefined reference to `_imp__re_set_syntax'
|
|
2359 collect2: ld returned 1 exit status
|
|
2360
|
|
2361 This happens because GCC finds an incompatible header regex.h
|
|
2362 somewhere on the include path, before the version of regex.h supplied
|
|
2363 with Emacs. One such incompatible version of regex.h is part of the
|
|
2364 GnuWin32 Regex package.
|
|
2365
|
|
2366 The solution is to remove the incompatible regex.h from the include
|
|
2367 path, when compiling Emacs. Alternatively, re-run the configure.bat
|
|
2368 script with the "-isystem C:/GnuWin32/include" switch (adapt for your
|
|
2369 system's place where you keep the GnuWin32 include files) -- this will
|
|
2370 cause the compiler to search headers in the directories specified by
|
|
2371 the Emacs Makefile _before_ it looks in the GnuWin32 include
|
|
2372 directories.
|
|
2373
|
73673
|
2374 *** Building the native MS-Windows port with Cygwin GCC can fail.
|
56734
|
2375
|
80126
|
2376 Emacs may not build using some Cygwin builds of GCC, such as Cygwin
|
56734
|
2377 version 1.1.8, using the default configure settings. It appears to be
|
|
2378 necessary to specify the -mwin32 flag when compiling, and define
|
|
2379 __MSVCRT__, like so:
|
|
2380
|
|
2381 configure --with-gcc --cflags -mwin32 --cflags -D__MSVCRT__
|
|
2382
|
|
2383 *** Building the MS-Windows port fails with a CreateProcess failure.
|
|
2384
|
|
2385 Some versions of mingw32 make on some versions of Windows do not seem
|
|
2386 to detect the shell correctly. Try "make SHELL=cmd.exe", or if that
|
|
2387 fails, try running make from Cygwin bash instead.
|
|
2388
|
|
2389 *** Building `ctags' for MS-Windows with the MinGW port of GCC fails.
|
|
2390
|
|
2391 This might happen due to a bug in the MinGW header assert.h, which
|
|
2392 defines the `assert' macro with a trailing semi-colon. The following
|
|
2393 patch to assert.h should solve this:
|
|
2394
|
76275
|
2395 *** include/assert.h.orig Sun Nov 7 02:41:36 1999
|
|
2396 --- include/assert.h Mon Jan 29 11:49:10 2001
|
|
2397 ***************
|
|
2398 *** 41,47 ****
|
|
2399 /*
|
|
2400 * If not debugging, assert does nothing.
|
|
2401 */
|
|
2402 ! #define assert(x) ((void)0);
|
|
2403
|
|
2404 #else /* debugging enabled */
|
|
2405
|
|
2406 --- 41,47 ----
|
|
2407 /*
|
|
2408 * If not debugging, assert does nothing.
|
|
2409 */
|
|
2410 ! #define assert(x) ((void)0)
|
|
2411
|
|
2412 #else /* debugging enabled */
|
|
2413
|
|
2414
|
76273
|
2415 *** Building the MS-Windows port with Visual Studio 2005 fails.
|
|
2416
|
|
2417 Microsoft no longer ships the single threaded version of the C library
|
|
2418 with their compiler, and the multithreaded static library is missing
|
76275
|
2419 some functions that Microsoft have deemed non-threadsafe. The
|
76273
|
2420 dynamically linked C library has all the functions, but there is a
|
|
2421 conflict between the versions of malloc in the DLL and in Emacs, which
|
|
2422 is not resolvable due to the way Windows does dynamic linking.
|
|
2423
|
101793
|
2424 We recommend the use of the MinGW port of GCC for compiling Emacs, as
|
76273
|
2425 not only does it not suffer these problems, but it is also Free
|
|
2426 software like Emacs.
|
|
2427
|
101793
|
2428 *** Building the MS-Windows port with Visual Studio fails compiling emacs.rc
|
|
2429
|
|
2430 If the build fails with the following message then the problem
|
|
2431 described here most likely applies:
|
|
2432
|
|
2433 ../nt/emacs.rc(1) : error RC2176 : old DIB in icons\emacs.ico; pass it
|
|
2434 through SDKPAINT
|
|
2435
|
|
2436 The Emacs icon contains a high resolution PNG icon for Vista, which is
|
|
2437 not recognized by older versions of the resource compiler. There are
|
|
2438 several workarounds for this problem:
|
|
2439 1. Use Free MinGW tools to compile, which do not have this problem.
|
|
2440 2. Install the latest Windows SDK.
|
|
2441 3. Replace emacs.ico with an older or edited icon.
|
|
2442
|
109478
2660703dfff3
* PROBLEMS: Add note about use of backslashes in Windows paths.
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
2443 *** Building the MS-Windows port complains about unknown escape sequences.
|
2660703dfff3
* PROBLEMS: Add note about use of backslashes in Windows paths.
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
2444
|
2660703dfff3
* PROBLEMS: Add note about use of backslashes in Windows paths.
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
2445 Errors and warnings can look like this:
|
2660703dfff3
* PROBLEMS: Add note about use of backslashes in Windows paths.
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
2446
|
2660703dfff3
* PROBLEMS: Add note about use of backslashes in Windows paths.
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
2447 w32.c:1959:27: error: \x used with no following hex digits
|
2660703dfff3
* PROBLEMS: Add note about use of backslashes in Windows paths.
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
2448 w32.c:1959:27: warning: unknown escape sequence '\i'
|
2660703dfff3
* PROBLEMS: Add note about use of backslashes in Windows paths.
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
2449
|
2660703dfff3
* PROBLEMS: Add note about use of backslashes in Windows paths.
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
2450 This happens when paths using backslashes are passed to the compiler or
|
2660703dfff3
* PROBLEMS: Add note about use of backslashes in Windows paths.
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
2451 linker (via -I and possibly other compiler flags); when these paths are
|
2660703dfff3
* PROBLEMS: Add note about use of backslashes in Windows paths.
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
2452 included in source code, the backslashes are interpreted as escape sequences.
|
2660703dfff3
* PROBLEMS: Add note about use of backslashes in Windows paths.
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
2453 See http://lists.gnu.org/archive/html/emacs-devel/2010-07/msg00995.html
|
2660703dfff3
* PROBLEMS: Add note about use of backslashes in Windows paths.
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
2454
|
2660703dfff3
* PROBLEMS: Add note about use of backslashes in Windows paths.
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
2455 The fix is to use forward slashes in all paths passed to the compiler.
|
2660703dfff3
* PROBLEMS: Add note about use of backslashes in Windows paths.
Juanma Barranquero <lekktu@gmail.com>
diff
changeset
|
2456
|
56734
|
2457 ** Linking
|
|
2458
|
|
2459 *** Building Emacs with a system compiler fails to link because of an
|
|
2460 undefined symbol such as __eprintf which does not appear in Emacs.
|
|
2461
|
|
2462 This can happen if some of the libraries linked into Emacs were built
|
|
2463 with GCC, but Emacs itself is being linked with a compiler other than
|
|
2464 GCC. Object files compiled with GCC might need some helper functions
|
|
2465 from libgcc.a, the library which comes with GCC, but the system
|
|
2466 compiler does not instruct the linker to search libgcc.a during the
|
|
2467 link stage.
|
|
2468
|
|
2469 A solution is to link with GCC, like this:
|
|
2470
|
97732
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
2471 make CC=gcc
|
56734
|
2472
|
|
2473 Since the .o object files already exist, this will not recompile Emacs
|
|
2474 with GCC, but just restart by trying again to link temacs.
|
|
2475
|
|
2476 *** Sun with acc: Link failure when using acc on a Sun.
|
|
2477
|
|
2478 To use acc, you need additional options just before the libraries, such as
|
|
2479
|
|
2480 /usr/lang/SC2.0.1/values-Xt.o -L/usr/lang/SC2.0.1/cg87 -L/usr/lang/SC2.0.1
|
|
2481
|
|
2482 and you need to add -lansi just before -lc.
|
|
2483
|
|
2484 The precise file names depend on the compiler version, so we
|
|
2485 cannot easily arrange to supply them.
|
|
2486
|
|
2487 *** Linking says that the functions insque and remque are undefined.
|
|
2488
|
|
2489 Change oldXMenu/Makefile by adding insque.o to the variable OBJS.
|
|
2490
|
|
2491 *** `tparam' reported as a multiply-defined symbol when linking with ncurses.
|
|
2492
|
|
2493 This problem results from an incompatible change in ncurses, in
|
|
2494 version 1.9.9e approximately. This version is unable to provide a
|
|
2495 definition of tparm without also defining tparam. This is also
|
|
2496 incompatible with Terminfo; as a result, the Emacs Terminfo support
|
|
2497 does not work with this version of ncurses.
|
|
2498
|
|
2499 The fix is to install a newer version of ncurses, such as version 4.2.
|
|
2500
|
97990
|
2501 ** Bootstrapping
|
|
2502
|
|
2503 Bootstrapping (compiling the .el files) is normally only necessary
|
108807
|
2504 with development builds, since the .elc files are pre-compiled in releases.
|
97990
|
2505
|
|
2506 *** "No rule to make target" with Ubuntu 8.04 make 3.81-3build1
|
|
2507
|
|
2508 Compiling the lisp files fails at random places, complaining:
|
|
2509 "No rule to make target `/path/to/some/lisp.elc'".
|
|
2510 The causes of this problem are not understood. Using GNU make 3.81 compiled
|
|
2511 from source, rather than the Ubuntu version, worked. See Bug#327,821.
|
|
2512
|
56734
|
2513 ** Dumping
|
|
2514
|
|
2515 *** Linux: Segfault during `make bootstrap' under certain recent versions of the Linux kernel.
|
|
2516
|
77139
|
2517 With certain recent Linux kernels (like the one of Red Hat Fedora Core
|
63968
|
2518 1 and newer), the new "Exec-shield" functionality is enabled by default, which
|
63969
|
2519 creates a different memory layout that breaks the emacs dumper. Emacs tries
|
|
2520 to handle this at build time, but if the workaround used fails, these
|
|
2521 instructions can be useful.
|
63968
|
2522 The work-around explained here is not enough on Fedora Core 4 (and possible
|
|
2523 newer). Read the next item.
|
56734
|
2524
|
57229
|
2525 Configure can overcome the problem of exec-shield if the architecture is
|
|
2526 x86 and the program setarch is present. On other architectures no
|
|
2527 workaround is known.
|
|
2528
|
56734
|
2529 You can check the Exec-shield state like this:
|
|
2530
|
|
2531 cat /proc/sys/kernel/exec-shield
|
|
2532
|
57229
|
2533 It returns non-zero when Exec-shield is enabled, 0 otherwise. Please
|
56734
|
2534 read your system documentation for more details on Exec-shield and
|
57229
|
2535 associated commands. Exec-shield can be turned off with this command:
|
|
2536
|
|
2537 echo "0" > /proc/sys/kernel/exec-shield
|
56734
|
2538
|
|
2539 When Exec-shield is enabled, building Emacs will segfault during the
|
|
2540 execution of this command:
|
|
2541
|
57229
|
2542 ./temacs --batch --load loadup [dump|bootstrap]
|
56734
|
2543
|
|
2544 To work around this problem, it is necessary to temporarily disable
|
57229
|
2545 Exec-shield while building Emacs, or, on x86, by using the `setarch'
|
|
2546 command when running temacs like this:
|
|
2547
|
|
2548 setarch i386 ./temacs --batch --load loadup [dump|bootstrap]
|
|
2549
|
71902
|
2550
|
63968
|
2551 *** Fedora Core 4 GNU/Linux: Segfault during dumping.
|
|
2552
|
|
2553 In addition to exec-shield explained above "Linux: Segfault during
|
|
2554 `make bootstrap' under certain recent versions of the Linux kernel"
|
|
2555 item, Linux kernel shipped with Fedora Core 4 randomizes the virtual
|
|
2556 address space of a process. As the result dumping may fail even if
|
|
2557 you turn off exec-shield. In this case, use the -R option to the setarch
|
|
2558 command:
|
|
2559
|
64489
|
2560 setarch i386 -R ./temacs --batch --load loadup [dump|bootstrap]
|
63968
|
2561
|
|
2562 or
|
|
2563
|
71902
|
2564 setarch i386 -R make bootstrap
|
63968
|
2565
|
56734
|
2566 *** Fatal signal in the command temacs -l loadup inc dump.
|
|
2567
|
|
2568 This command is the final stage of building Emacs. It is run by the
|
97142
|
2569 Makefile in the src subdirectory.
|
56734
|
2570
|
|
2571 It has been known to get fatal errors due to insufficient swapping
|
|
2572 space available on the machine.
|
|
2573
|
|
2574 On 68000s, it has also happened because of bugs in the
|
|
2575 subroutine `alloca'. Verify that `alloca' works right, even
|
|
2576 for large blocks (many pages).
|
|
2577
|
|
2578 *** test-distrib says that the distribution has been clobbered.
|
|
2579 *** or, temacs prints "Command key out of range 0-127".
|
|
2580 *** or, temacs runs and dumps emacs, but emacs totally fails to work.
|
|
2581 *** or, temacs gets errors dumping emacs.
|
|
2582
|
|
2583 This can be because the .elc files have been garbled. Do not be
|
|
2584 fooled by the fact that most of a .elc file is text: these are
|
|
2585 binary files and can contain all 256 byte values.
|
|
2586
|
|
2587 In particular `shar' cannot be used for transmitting GNU Emacs.
|
|
2588 It typically truncates "lines". What appear to be "lines" in
|
|
2589 a binary file can of course be of any length. Even once `shar'
|
|
2590 itself is made to work correctly, `sh' discards null characters
|
|
2591 when unpacking the shell archive.
|
|
2592
|
|
2593 I have also seen character \177 changed into \377. I do not know
|
|
2594 what transfer means caused this problem. Various network
|
|
2595 file transfer programs are suspected of clobbering the high bit.
|
|
2596
|
|
2597 If you have a copy of Emacs that has been damaged in its
|
|
2598 nonprinting characters, you can fix them:
|
|
2599
|
|
2600 1) Record the names of all the .elc files.
|
|
2601 2) Delete all the .elc files.
|
|
2602 3) Recompile alloc.c with a value of PURESIZE twice as large.
|
|
2603 (See puresize.h.) You might as well save the old alloc.o.
|
|
2604 4) Remake emacs. It should work now.
|
|
2605 5) Running emacs, do Meta-x byte-compile-file repeatedly
|
|
2606 to recreate all the .elc files that used to exist.
|
|
2607 You may need to increase the value of the variable
|
|
2608 max-lisp-eval-depth to succeed in running the compiler interpreted
|
|
2609 on certain .el files. 400 was sufficient as of last report.
|
|
2610 6) Reinstall the old alloc.o (undoing changes to alloc.c if any)
|
|
2611 and remake temacs.
|
|
2612 7) Remake emacs. It should work now, with valid .elc files.
|
|
2613
|
|
2614 *** temacs prints "Pure Lisp storage exhausted".
|
|
2615
|
108807
|
2616 This means that the Lisp code loaded from the .elc and .el files
|
|
2617 during temacs -l loadup inc dump took up more space than was allocated.
|
56734
|
2618
|
|
2619 This could be caused by
|
|
2620 1) adding code to the preloaded Lisp files
|
|
2621 2) adding more preloaded files in loadup.el
|
|
2622 3) having a site-init.el or site-load.el which loads files.
|
|
2623 Note that ANY site-init.el or site-load.el is nonstandard;
|
108807
|
2624 if you have received Emacs from some other site and it contains a
|
|
2625 site-init.el or site-load.el file, consider deleting that file.
|
56734
|
2626 4) getting the wrong .el or .elc files
|
|
2627 (not from the directory you expected).
|
|
2628 5) deleting some .elc files that are supposed to exist.
|
|
2629 This would cause the source files (.el files) to be
|
|
2630 loaded instead. They take up more room, so you lose.
|
108807
|
2631 6) a bug in the Emacs distribution which underestimates the space required.
|
56734
|
2632
|
|
2633 If the need for more space is legitimate, change the definition
|
|
2634 of PURESIZE in puresize.h.
|
|
2635
|
|
2636 But in some of the cases listed above, this problem is a consequence
|
108807
|
2637 of something else that is wrong. Be sure to check and fix the real problem.
|
56734
|
2638
|
|
2639 *** Linux: Emacs crashes when dumping itself on Mac PPC running Yellow Dog GNU/Linux.
|
|
2640
|
|
2641 The crashes happen inside the function Fmake_symbol; here's a typical
|
|
2642 C backtrace printed by GDB:
|
|
2643
|
|
2644 0x190c0c0 in Fmake_symbol ()
|
|
2645 (gdb) where
|
|
2646 #0 0x190c0c0 in Fmake_symbol ()
|
|
2647 #1 0x1942ca4 in init_obarray ()
|
|
2648 #2 0x18b3500 in main ()
|
|
2649 #3 0x114371c in __libc_start_main (argc=5, argv=0x7ffff5b4, envp=0x7ffff5cc,
|
|
2650
|
|
2651 This could happen because GCC version 2.95 and later changed the base
|
|
2652 of the load address to 0x10000000. Emacs needs to be told about this,
|
|
2653 but we currently cannot do that automatically, because that breaks
|
|
2654 other versions of GNU/Linux on the MacPPC. Until we find a way to
|
|
2655 distinguish between the Yellow Dog and the other varieties of
|
|
2656 GNU/Linux systems on the PPC, you will have to manually uncomment the
|
|
2657 following section near the end of the file src/m/macppc.h in the Emacs
|
|
2658 distribution:
|
|
2659
|
|
2660 #if 0 /* This breaks things on PPC GNU/Linux except for Yellowdog,
|
97732
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
2661 even with identical GCC, as, ld. Let's take it out until we
|
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
2662 know what's really going on here. */
|
56734
|
2663 /* GCC 2.95 and newer on GNU/Linux PPC changed the load address to
|
|
2664 0x10000000. */
|
|
2665 #if defined __linux__
|
|
2666 #if __GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 95)
|
|
2667 #define DATA_SEG_BITS 0x10000000
|
|
2668 #endif
|
|
2669 #endif
|
|
2670 #endif /* 0 */
|
|
2671
|
|
2672 Remove the "#if 0" and "#endif" directives which surround this, save
|
|
2673 the file, and then reconfigure and rebuild Emacs. The dumping process
|
|
2674 should now succeed.
|
|
2675
|
77736
|
2676 *** OpenBSD 4.0 macppc: Segfault during dumping.
|
|
2677
|
|
2678 The build aborts with signal 11 when the command `./temacs --batch
|
77746
|
2679 --load loadup bootstrap' tries to load files.el. A workaround seems
|
|
2680 to be to reduce the level of compiler optimization used during the
|
|
2681 build (from -O2 to -O1). It is possible this is an OpenBSD
|
77736
|
2682 GCC problem specific to the macppc architecture, possibly only
|
77746
|
2683 occurring with older versions of GCC (e.g. 3.3.5).
|
77736
|
2684
|
79018
|
2685 *** openSUSE 10.3: Segfault in bcopy during dumping.
|
|
2686
|
|
2687 This is due to a bug in the bcopy implementation in openSUSE 10.3.
|
|
2688 It is/will be fixed in an openSUSE update.
|
|
2689
|
56734
|
2690 ** Installation
|
|
2691
|
|
2692 *** Installing Emacs gets an error running `install-info'.
|
|
2693
|
|
2694 You need to install a recent version of Texinfo; that package
|
|
2695 supplies the `install-info' command.
|
|
2696
|
76755
|
2697 *** Installing to a directory with spaces in the name fails.
|
|
2698
|
|
2699 For example, if you call configure with a directory-related option
|
|
2700 with spaces in the value, eg --enable-locallisppath='/path/with\ spaces'.
|
|
2701 Using directory paths with spaces is not supported at this time: you
|
|
2702 must re-configure without using spaces.
|
|
2703
|
77791
2281fafb5f9d
Add "Installing to a directory with non-ASCII characters in the name fails".
Chong Yidong <cyd@stupidchicken.com>
diff
changeset
|
2704 *** Installing to a directory with non-ASCII characters in the name fails.
|
2281fafb5f9d
Add "Installing to a directory with non-ASCII characters in the name fails".
Chong Yidong <cyd@stupidchicken.com>
diff
changeset
|
2705
|
2281fafb5f9d
Add "Installing to a directory with non-ASCII characters in the name fails".
Chong Yidong <cyd@stupidchicken.com>
diff
changeset
|
2706 Installation may fail, or the Emacs executable may not start
|
2281fafb5f9d
Add "Installing to a directory with non-ASCII characters in the name fails".
Chong Yidong <cyd@stupidchicken.com>
diff
changeset
|
2707 correctly, if a directory name containing non-ASCII characters is used
|
2281fafb5f9d
Add "Installing to a directory with non-ASCII characters in the name fails".
Chong Yidong <cyd@stupidchicken.com>
diff
changeset
|
2708 as a `configure' argument (e.g. `--prefix'). The problem can also
|
2281fafb5f9d
Add "Installing to a directory with non-ASCII characters in the name fails".
Chong Yidong <cyd@stupidchicken.com>
diff
changeset
|
2709 occur if a non-ASCII directory is specified in the EMACSLOADPATH
|
2281fafb5f9d
Add "Installing to a directory with non-ASCII characters in the name fails".
Chong Yidong <cyd@stupidchicken.com>
diff
changeset
|
2710 envvar.
|
2281fafb5f9d
Add "Installing to a directory with non-ASCII characters in the name fails".
Chong Yidong <cyd@stupidchicken.com>
diff
changeset
|
2711
|
77601
|
2712 *** On Solaris, use GNU Make when installing an out-of-tree build
|
|
2713
|
|
2714 The Emacs configuration process allows you to configure the
|
|
2715 build environment so that you can build emacs in a directory
|
|
2716 outside of the distribution tree. When installing Emacs from an
|
|
2717 out-of-tree build directory on Solaris, you may need to use GNU
|
|
2718 make. The make programs bundled with Solaris support the VPATH
|
|
2719 macro but use it differently from the way the VPATH macro is
|
|
2720 used by GNU make. The differences will cause the "make install"
|
|
2721 step to fail, leaving you with an incomplete emacs
|
|
2722 installation. GNU make is available in /usr/sfw/bin on Solaris
|
|
2723 10 and can be installed as /opt/sfw/bin/gmake from the Solaris 9
|
|
2724 Software Companion CDROM.
|
|
2725
|
|
2726 The problems due to the VPATH processing differences affect only
|
|
2727 out of tree builds so, if you are on a Solaris installation
|
|
2728 without GNU make, you can install Emacs completely by installing
|
|
2729 from a build environment using the original emacs distribution tree.
|
|
2730
|
56734
|
2731 ** First execution
|
|
2732
|
|
2733 *** Emacs binary is not in executable format, and cannot be run.
|
|
2734
|
|
2735 This was reported to happen when Emacs is built in a directory mounted
|
|
2736 via NFS, for some combinations of NFS client and NFS server.
|
|
2737 Usually, the file `emacs' produced in these cases is full of
|
|
2738 binary null characters, and the `file' utility says:
|
|
2739
|
|
2740 emacs: ASCII text, with no line terminators
|
|
2741
|
|
2742 We don't know what exactly causes this failure. A work-around is to
|
|
2743 build Emacs in a directory on a local disk.
|
|
2744
|
|
2745 *** The dumped Emacs crashes when run, trying to write pure data.
|
|
2746
|
|
2747 Two causes have been seen for such problems.
|
|
2748
|
|
2749 1) On a system where getpagesize is not a system call, it is defined
|
109628
|
2750 as a macro. If the definition (in both unex*.c and malloc.c) is wrong,
|
56734
|
2751 it can cause problems like this. You might be able to find the correct
|
|
2752 value in the man page for a.out (5).
|
|
2753
|
|
2754 2) Some systems allocate variables declared static among the
|
|
2755 initialized variables. Emacs makes all initialized variables in most
|
|
2756 of its files pure after dumping, but the variables declared static and
|
|
2757 not initialized are not supposed to be pure. On these systems you
|
|
2758 may need to add "#define static" to the m- or the s- file.
|
|
2759
|
|
2760 * Runtime problems on legacy systems
|
|
2761
|
|
2762 This section covers bugs reported on very old hardware or software.
|
|
2763 If you are using hardware and an operating system shipped after 2000,
|
|
2764 it is unlikely you will see any of these.
|
|
2765
|
108807
|
2766 *** OPENSTEP 4.2: Compiling syntax.c with gcc 2.7.2.1 fails.
|
56734
|
2767
|
|
2768 The compiler was reported to crash while compiling syntax.c with the
|
|
2769 following message:
|
|
2770
|
|
2771 cc: Internal compiler error: program cc1obj got fatal signal 11
|
|
2772
|
|
2773 To work around this, replace the macros UPDATE_SYNTAX_TABLE_FORWARD,
|
|
2774 INC_BOTH, and INC_FROM with functions. To this end, first define 3
|
|
2775 functions, one each for every macro. Here's an example:
|
|
2776
|
|
2777 static int update_syntax_table_forward(int from)
|
|
2778 {
|
|
2779 return(UPDATE_SYNTAX_TABLE_FORWARD(from));
|
|
2780 }/*update_syntax_table_forward*/
|
|
2781
|
|
2782 Then replace all references to UPDATE_SYNTAX_TABLE_FORWARD in syntax.c
|
|
2783 with a call to the function update_syntax_table_forward.
|
|
2784
|
|
2785 *** Solaris 2.x
|
|
2786
|
|
2787 **** Strange results from format %d in a few cases, on a Sun.
|
|
2788
|
|
2789 Sun compiler version SC3.0 has been found to miscompile part of
|
|
2790 editfns.c. The workaround is to compile with some other compiler such
|
|
2791 as GCC.
|
|
2792
|
|
2793 **** On Solaris, Emacs dumps core if lisp-complete-symbol is called.
|
|
2794
|
|
2795 If you compile Emacs with the -fast or -xO4 option with version 3.0.2
|
|
2796 of the Sun C compiler, Emacs dumps core when lisp-complete-symbol is
|
|
2797 called. The problem does not happen if you compile with GCC.
|
|
2798
|
|
2799 **** On Solaris, Emacs crashes if you use (display-time).
|
|
2800
|
|
2801 This can happen if you configure Emacs without specifying the precise
|
|
2802 version of Solaris that you are using.
|
|
2803
|
|
2804 **** Solaris 2.x: GCC complains "64 bit integer types not supported".
|
|
2805
|
|
2806 This suggests that GCC is not installed correctly. Most likely you
|
|
2807 are using GCC 2.7.2.3 (or earlier) on Solaris 2.6 (or later); this
|
|
2808 does not work without patching. To run GCC 2.7.2.3 on Solaris 2.6 or
|
|
2809 later, you must patch fixinc.svr4 and reinstall GCC from scratch as
|
|
2810 described in the Solaris FAQ
|
|
2811 <http://www.wins.uva.nl/pub/solaris/solaris2.html>. A better fix is
|
|
2812 to upgrade to GCC 2.8.1 or later.
|
|
2813
|
|
2814 **** Solaris 2.7: Building Emacs with WorkShop Compilers 5.0 98/12/15
|
|
2815 C 5.0 failed, apparently with non-default CFLAGS, most probably due to
|
|
2816 compiler bugs. Using Sun Solaris 2.7 Sun WorkShop 6 update 1 C
|
|
2817 release was reported to work without problems. It worked OK on
|
|
2818 another system with Solaris 8 using apparently the same 5.0 compiler
|
|
2819 and the default CFLAGS.
|
|
2820
|
|
2821 **** Solaris 2.x: Emacs dumps core when built with Motif.
|
|
2822
|
|
2823 The Solaris Motif libraries are buggy, at least up through Solaris 2.5.1.
|
|
2824 Install the current Motif runtime library patch appropriate for your host.
|
|
2825 (Make sure the patch is current; some older patch versions still have the bug.)
|
|
2826 You should install the other patches recommended by Sun for your host, too.
|
|
2827 You can obtain Sun patches from ftp://sunsolve.sun.com/pub/patches/;
|
|
2828 look for files with names ending in `.PatchReport' to see which patches
|
|
2829 are currently recommended for your host.
|
|
2830
|
|
2831 On Solaris 2.6, Emacs is said to work with Motif when Solaris patch
|
|
2832 105284-12 is installed, but fail when 105284-15 is installed.
|
|
2833 105284-18 might fix it again.
|
|
2834
|
56914
|
2835 **** Solaris 2.6 and 7: the Compose key does not work.
|
56734
|
2836
|
|
2837 This is a bug in Motif in Solaris. Supposedly it has been fixed for
|
|
2838 the next major release of Solaris. However, if someone with Sun
|
|
2839 support complains to Sun about the bug, they may release a patch.
|
|
2840 If you do this, mention Sun bug #4188711.
|
|
2841
|
|
2842 One workaround is to use a locale that allows non-ASCII characters.
|
|
2843 For example, before invoking emacs, set the LC_ALL environment
|
|
2844 variable to "en_US" (American English). The directory /usr/lib/locale
|
|
2845 lists the supported locales; any locale other than "C" or "POSIX"
|
|
2846 should do.
|
|
2847
|
|
2848 pen@lysator.liu.se says (Feb 1998) that the Compose key does work
|
108807
|
2849 if you link with the MIT X11 libraries instead of the Solaris X11 libraries.
|
56914
|
2850
|
|
2851 *** HP/UX 10: Large file support is disabled.
|
108807
|
2852 (HP/UX 10 was end-of-lifed in May 1999.)
|
108799
|
2853 See the comments in src/s/hpux10-20.h.
|
56914
|
2854
|
|
2855 *** HP/UX: Emacs is slow using X11R5.
|
|
2856
|
|
2857 This happens if you use the MIT versions of the X libraries--it
|
|
2858 doesn't run as fast as HP's version. People sometimes use the version
|
|
2859 because they see the HP version doesn't have the libraries libXaw.a,
|
|
2860 libXmu.a, libXext.a and others. HP/UX normally doesn't come with
|
|
2861 those libraries installed. To get good performance, you need to
|
|
2862 install them and rebuild Emacs.
|
|
2863
|
108807
|
2864 *** UnixWare 2.1: Error 12 (virtual memory exceeded) when dumping Emacs.
|
56914
|
2865
|
|
2866 Paul Abrahams (abrahams@acm.org) reports that with the installed
|
|
2867 virtual memory settings for UnixWare 2.1.2, an Error 12 occurs during
|
|
2868 the "make" that builds Emacs, when running temacs to dump emacs. That
|
|
2869 error indicates that the per-process virtual memory limit has been
|
|
2870 exceeded. The default limit is probably 32MB. Raising the virtual
|
|
2871 memory limit to 40MB should make it possible to finish building Emacs.
|
|
2872
|
|
2873 You can do this with the command `ulimit' (sh) or `limit' (csh).
|
|
2874 But you have to be root to do it.
|
|
2875
|
|
2876 According to Martin Sohnius, you can also retune this in the kernel:
|
|
2877
|
|
2878 # /etc/conf/bin/idtune SDATLIM 33554432 ## soft data size limit
|
|
2879 # /etc/conf/bin/idtune HDATLIM 33554432 ## hard "
|
|
2880 # /etc/conf/bin/idtune SVMMSIZE unlimited ## soft process size limit
|
|
2881 # /etc/conf/bin/idtune HVMMSIZE unlimited ## hard "
|
|
2882 # /etc/conf/bin/idbuild -B
|
|
2883
|
|
2884 (He recommends you not change the stack limit, though.)
|
|
2885 These changes take effect when you reboot.
|
|
2886
|
108807
|
2887 ** MS-Windows 95, 98, ME, and NT
|
56914
|
2888
|
|
2889 *** MS-Windows NT/95: Problems running Perl under Emacs
|
|
2890
|
|
2891 `perl -de 0' just hangs when executed in an Emacs subshell.
|
|
2892 The fault lies with Perl (indirectly with Windows NT/95).
|
|
2893
|
|
2894 The problem is that the Perl debugger explicitly opens a connection to
|
|
2895 "CON", which is the DOS/NT equivalent of "/dev/tty", for interacting
|
|
2896 with the user.
|
|
2897
|
|
2898 On Unix, this is okay, because Emacs (or the shell?) creates a
|
|
2899 pseudo-tty so that /dev/tty is really the pipe Emacs is using to
|
|
2900 communicate with the subprocess.
|
|
2901
|
|
2902 On NT, this fails because CON always refers to the handle for the
|
|
2903 relevant console (approximately equivalent to a tty), and cannot be
|
|
2904 redirected to refer to the pipe Emacs assigned to the subprocess as
|
|
2905 stdin.
|
|
2906
|
|
2907 A workaround is to modify perldb.pl to use STDIN/STDOUT instead of CON.
|
|
2908
|
|
2909 For Perl 4:
|
|
2910
|
|
2911 *** PERL/LIB/PERLDB.PL.orig Wed May 26 08:24:18 1993
|
|
2912 --- PERL/LIB/PERLDB.PL Mon Jul 01 15:28:16 1996
|
|
2913 ***************
|
|
2914 *** 68,74 ****
|
97732
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
2915 $rcfile=".perldb";
|
56914
|
2916 }
|
|
2917 else {
|
|
2918 ! $console = "con";
|
97732
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
2919 $rcfile="perldb.ini";
|
56914
|
2920 }
|
|
2921
|
|
2922 --- 68,74 ----
|
97732
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
2923 $rcfile=".perldb";
|
56914
|
2924 }
|
|
2925 else {
|
|
2926 ! $console = "";
|
97732
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
2927 $rcfile="perldb.ini";
|
56914
|
2928 }
|
|
2929
|
|
2930
|
|
2931 For Perl 5:
|
|
2932 *** perl/5.001/lib/perl5db.pl.orig Sun Jun 04 21:13:40 1995
|
|
2933 --- perl/5.001/lib/perl5db.pl Mon Jul 01 17:00:08 1996
|
|
2934 ***************
|
|
2935 *** 22,28 ****
|
97732
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
2936 $rcfile=".perldb";
|
56914
|
2937 }
|
|
2938 elsif (-e "con") {
|
|
2939 ! $console = "con";
|
97732
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
2940 $rcfile="perldb.ini";
|
56914
|
2941 }
|
|
2942 else {
|
|
2943 --- 22,28 ----
|
97732
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
2944 $rcfile=".perldb";
|
56914
|
2945 }
|
|
2946 elsif (-e "con") {
|
|
2947 ! $console = "";
|
97732
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
2948 $rcfile="perldb.ini";
|
56914
|
2949 }
|
|
2950 else {
|
|
2951
|
|
2952 *** MS-Windows 95: Alt-f6 does not get through to Emacs.
|
|
2953
|
|
2954 This character seems to be trapped by the kernel in Windows 95.
|
|
2955 You can enter M-f6 by typing ESC f6.
|
|
2956
|
|
2957 *** MS-Windows 95/98/ME: subprocesses do not terminate properly.
|
|
2958
|
|
2959 This is a limitation of the Operating System, and can cause problems
|
|
2960 when shutting down Windows. Ensure that all subprocesses are exited
|
|
2961 cleanly before exiting Emacs. For more details, see the FAQ at
|
|
2962 http://www.gnu.org/software/emacs/windows/.
|
|
2963
|
|
2964 *** MS-Windows 95/98/ME: crashes when Emacs invokes non-existent programs.
|
|
2965
|
|
2966 When a program you are trying to run is not found on the PATH,
|
|
2967 Windows might respond by crashing or locking up your system. In
|
|
2968 particular, this has been reported when trying to compile a Java
|
108807
|
2969 program in JDEE when javac.exe is installed, but not on the system PATH.
|
56914
|
2970
|
56734
|
2971 ** MS-DOS
|
|
2972
|
100561
|
2973 *** When compiling with DJGPP on MS-Windows NT or later, "config msdos" fails.
|
56734
|
2974
|
|
2975 If the error message is "VDM has been already loaded", this is because
|
|
2976 Windows has a program called `redir.exe' that is incompatible with a
|
|
2977 program by the same name supplied with DJGPP, which is used by
|
|
2978 config.bat. To resolve this, move the DJGPP's `bin' subdirectory to
|
|
2979 the front of your PATH environment variable.
|
|
2980
|
102250
|
2981 *** When Emacs compiled with DJGPP runs on Windows 2000 and later, it cannot
|
|
2982 find your HOME directory.
|
|
2983
|
|
2984 This was reported to happen when you click on "Save for future
|
|
2985 sessions" button in a Customize buffer. You might see an error
|
|
2986 message like this one:
|
|
2987
|
|
2988 basic-save-buffer-2: c:/FOO/BAR/~dosuser/: no such directory
|
|
2989
|
|
2990 (The telltale sign is the "~USER" part at the end of the directory
|
|
2991 Emacs complains about, where USER is your username or the literal
|
|
2992 string "dosuser", which is the default username set up by the DJGPP
|
|
2993 startup file DJGPP.ENV.)
|
|
2994
|
|
2995 This happens when the functions `user-login-name' and
|
|
2996 `user-real-login-name' return different strings for your username as
|
|
2997 Emacs sees it. To correct this, make sure both USER and USERNAME
|
|
2998 environment variables are set to the same value. Windows 2000 and
|
|
2999 later sets USERNAME, so if you want to keep that, make sure USER is
|
|
3000 set to the same value. If you don't want to set USER globally, you
|
|
3001 can do it in the [emacs] section of your DJGPP.ENV file.
|
|
3002
|
100561
|
3003 *** When Emacs compiled with DJGPP runs on Vista, it runs out of memory.
|
|
3004
|
|
3005 If Emacs running on Vista displays "!MEM FULL!" in the mode line, you
|
|
3006 are hitting the memory allocation bugs in the Vista DPMI server. See
|
|
3007 msdos/INSTALL for how to work around these bugs (search for "Vista").
|
|
3008
|
56734
|
3009 *** When compiling with DJGPP on MS-Windows 95, Make fails for some targets
|
|
3010 like make-docfile.
|
|
3011
|
|
3012 This can happen if long file name support (the setting of environment
|
|
3013 variable LFN) when Emacs distribution was unpacked and during
|
100561
|
3014 compilation are not the same. See msdos/INSTALL for the explanation
|
|
3015 of how to avoid this problem.
|
56734
|
3016
|
|
3017 *** Emacs compiled with DJGPP complains at startup:
|
|
3018
|
|
3019 "Wrong type of argument: internal-facep, msdos-menu-active-face"
|
|
3020
|
|
3021 This can happen if you define an environment variable `TERM'. Emacs
|
|
3022 on MSDOS uses an internal terminal emulator which is disabled if the
|
|
3023 value of `TERM' is anything but the string "internal". Emacs then
|
|
3024 works as if its terminal were a dumb glass teletype that doesn't
|
|
3025 support faces. To work around this, arrange for `TERM' to be
|
|
3026 undefined when Emacs runs. The best way to do that is to add an
|
|
3027 [emacs] section to the DJGPP.ENV file which defines an empty value for
|
|
3028 `TERM'; this way, only Emacs gets the empty value, while the rest of
|
|
3029 your system works as before.
|
|
3030
|
|
3031 *** MS-DOS: Emacs crashes at startup.
|
|
3032
|
|
3033 Some users report that Emacs 19.29 requires dpmi memory management,
|
108807
|
3034 and crashes on startup if the system does not have it. We don't
|
56734
|
3035 know why this happens--perhaps these machines don't have enough real
|
|
3036 memory, or perhaps something is wrong in Emacs or the compiler.
|
|
3037 However, arranging to use dpmi support is a workaround.
|
|
3038
|
|
3039 You can find out if you have a dpmi host by running go32 without
|
|
3040 arguments; it will tell you if it uses dpmi memory. For more
|
|
3041 information about dpmi memory, consult the djgpp FAQ. (djgpp
|
|
3042 is the GNU C compiler as packaged for MSDOS.)
|
|
3043
|
|
3044 Compiling Emacs under MSDOS is extremely sensitive for proper memory
|
|
3045 configuration. If you experience problems during compilation, consider
|
|
3046 removing some or all memory resident programs (notably disk caches)
|
|
3047 and make sure that your memory managers are properly configured. See
|
|
3048 the djgpp faq for configuration hints.
|
|
3049
|
|
3050 *** Emacs compiled with DJGPP for MS-DOS/MS-Windows cannot access files
|
|
3051 in the directory with the special name `dev' under the root of any
|
|
3052 drive, e.g. `c:/dev'.
|
|
3053
|
|
3054 This is an unfortunate side-effect of the support for Unix-style
|
|
3055 device names such as /dev/null in the DJGPP runtime library. A
|
|
3056 work-around is to rename the problem directory to another name.
|
|
3057
|
108807
|
3058 *** MS-DOS+DJGPP: Problems on MS-DOS if DJGPP v2.0 is used to compile Emacs.
|
56734
|
3059
|
|
3060 There are two DJGPP library bugs which cause problems:
|
|
3061
|
|
3062 * Running `shell-command' (or `compile', or `grep') you get
|
|
3063 `Searching for program: permission denied (EACCES), c:/command.com';
|
|
3064 * After you shell to DOS, Ctrl-Break kills Emacs.
|
|
3065
|
|
3066 To work around these bugs, you can use two files in the msdos
|
|
3067 subdirectory: `is_exec.c' and `sigaction.c'. Compile them and link
|
|
3068 them into the Emacs executable `temacs'; then they will replace the
|
|
3069 incorrect library functions.
|
|
3070
|
|
3071 *** MS-DOS: Emacs compiled for MSDOS cannot find some Lisp files, or other
|
|
3072 run-time support files, when long filename support is enabled.
|
|
3073
|
|
3074 Usually, this problem will manifest itself when Emacs exits
|
|
3075 immediately after flashing the startup screen, because it cannot find
|
|
3076 the Lisp files it needs to load at startup. Redirect Emacs stdout
|
|
3077 and stderr to a file to see the error message printed by Emacs.
|
|
3078
|
|
3079 Another manifestation of this problem is that Emacs is unable to load
|
108807
|
3080 the support for editing program sources in languages such as C and Lisp.
|
56734
|
3081
|
|
3082 This can happen if the Emacs distribution was unzipped without LFN
|
|
3083 support, thus causing long filenames to be truncated to the first 6
|
|
3084 characters and a numeric tail that Windows 95 normally attaches to it.
|
|
3085 You should unzip the files again with a utility that supports long
|
|
3086 filenames (such as djtar from DJGPP or InfoZip's UnZip program
|
100561
|
3087 compiled with DJGPP v2). The file msdos/INSTALL explains this issue
|
|
3088 in more detail.
|
56734
|
3089
|
|
3090 Another possible reason for such failures is that Emacs compiled for
|
|
3091 MSDOS is used on Windows NT, where long file names are not supported
|
|
3092 by this version of Emacs, but the distribution was unpacked by an
|
|
3093 unzip program that preserved the long file names instead of truncating
|
|
3094 them to DOS 8+3 limits. To be useful on NT, the MSDOS port of Emacs
|
|
3095 must be unzipped by a DOS utility, so that long file names are
|
|
3096 properly truncated.
|
|
3097
|
|
3098 ** Archaic window managers and toolkits
|
|
3099
|
|
3100 *** OpenLook: Under OpenLook, the Emacs window disappears when you type M-q.
|
|
3101
|
|
3102 Some versions of the Open Look window manager interpret M-q as a quit
|
|
3103 command for whatever window you are typing at. If you want to use
|
|
3104 Emacs with that window manager, you should try to configure the window
|
|
3105 manager to use some other command. You can disable the
|
|
3106 shortcut keys entirely by adding this line to ~/.OWdefaults:
|
|
3107
|
|
3108 OpenWindows.WindowMenuAccelerators: False
|
|
3109
|
108807
|
3110 *** twm: A position you specified in .Xdefaults is ignored, using twm.
|
56734
|
3111
|
|
3112 twm normally ignores "program-specified" positions.
|
|
3113 You can tell it to obey them with this command in your `.twmrc' file:
|
|
3114
|
|
3115 UsePPosition "on" #allow clients to request a position
|
|
3116
|
|
3117 ** Bugs related to old DEC hardware
|
|
3118
|
|
3119 *** The Compose key on a DEC keyboard does not work as Meta key.
|
|
3120
|
|
3121 This shell command should fix it:
|
|
3122
|
|
3123 xmodmap -e 'keycode 0xb1 = Meta_L'
|
|
3124
|
|
3125 *** Keyboard input gets confused after a beep when using a DECserver
|
|
3126 as a concentrator.
|
|
3127
|
|
3128 This problem seems to be a matter of configuring the DECserver to use
|
|
3129 7 bit characters rather than 8 bit characters.
|
|
3130
|
|
3131 * Build problems on legacy systems
|
|
3132
|
|
3133 ** SunOS: Emacs gets error message from linker on Sun.
|
|
3134
|
|
3135 If the error message says that a symbol such as `f68881_used' or
|
|
3136 `ffpa_used' or `start_float' is undefined, this probably indicates
|
|
3137 that you have compiled some libraries, such as the X libraries,
|
|
3138 with a floating point option other than the default.
|
|
3139
|
|
3140 It's not terribly hard to make this work with small changes in
|
|
3141 crt0.c together with linking with Fcrt1.o, Wcrt1.o or Mcrt1.o.
|
|
3142 However, the easiest approach is to build Xlib with the default
|
|
3143 floating point option: -fsoft.
|
|
3144
|
56914
|
3145 ** HPUX 10.20: Emacs crashes during dumping on the HPPA machine.
|
|
3146
|
|
3147 This seems to be due to a GCC bug; it is fixed in GCC 2.8.1.
|
|
3148
|
56734
|
3149 ** Vax C compiler bugs affecting Emacs.
|
25853
|
3150
|
|
3151 You may get one of these problems compiling Emacs:
|
|
3152
|
|
3153 foo.c line nnn: compiler error: no table entry for op STASG
|
|
3154 foo.c: fatal error in /lib/ccom
|
|
3155
|
|
3156 These are due to bugs in the C compiler; the code is valid C.
|
|
3157 Unfortunately, the bugs are unpredictable: the same construct
|
|
3158 may compile properly or trigger one of these bugs, depending
|
|
3159 on what else is in the source file being compiled. Even changes
|
|
3160 in header files that should not affect the file being compiled
|
|
3161 can affect whether the bug happens. In addition, sometimes files
|
|
3162 that compile correctly on one machine get this bug on another machine.
|
|
3163
|
|
3164 As a result, it is hard for me to make sure this bug will not affect
|
|
3165 you. I have attempted to find and alter these constructs, but more
|
|
3166 can always appear. However, I can tell you how to deal with it if it
|
|
3167 should happen. The bug comes from having an indexed reference to an
|
|
3168 array of Lisp_Objects, as an argument in a function call:
|
|
3169 Lisp_Object *args;
|
|
3170 ...
|
|
3171 ... foo (5, args[i], ...)...
|
|
3172 putting the argument into a temporary variable first, as in
|
|
3173 Lisp_Object *args;
|
|
3174 Lisp_Object tem;
|
|
3175 ...
|
|
3176 tem = args[i];
|
|
3177 ... foo (r, tem, ...)...
|
|
3178 causes the problem to go away.
|
|
3179 The `contents' field of a Lisp vector is an array of Lisp_Objects,
|
|
3180 so you may see the problem happening with indexed references to that.
|
|
3181
|
56734
|
3182 ** 68000 C compiler problems
|
25853
|
3183
|
|
3184 Various 68000 compilers have different problems.
|
|
3185 These are some that have been observed.
|
|
3186
|
56734
|
3187 *** Using value of assignment expression on union type loses.
|
25853
|
3188 This means that x = y = z; or foo (x = z); does not work
|
|
3189 if x is of type Lisp_Object.
|
|
3190
|
56734
|
3191 *** "cannot reclaim" error.
|
25853
|
3192
|
|
3193 This means that an expression is too complicated. You get the correct
|
|
3194 line number in the error message. The code must be rewritten with
|
|
3195 simpler expressions.
|
|
3196
|
56734
|
3197 *** XCONS, XSTRING, etc macros produce incorrect code.
|
25853
|
3198
|
|
3199 If temacs fails to run at all, this may be the cause.
|
|
3200 Compile this test program and look at the assembler code:
|
|
3201
|
|
3202 struct foo { char x; unsigned int y : 24; };
|
|
3203
|
|
3204 lose (arg)
|
|
3205 struct foo arg;
|
|
3206 {
|
|
3207 test ((int *) arg.y);
|
|
3208 }
|
|
3209
|
|
3210 If the code is incorrect, your compiler has this problem.
|
|
3211 In the XCONS, etc., macros in lisp.h you must replace (a).u.val with
|
|
3212 ((a).u.val + coercedummy) where coercedummy is declared as int.
|
|
3213
|
96602
|
3214 This problem will only happen if USE_LISP_UNION_TYPE is manually
|
|
3215 defined in lisp.h.
|
25853
|
3216
|
108807
|
3217 ** C compilers lose on returning unions.
|
25853
|
3218
|
|
3219 I hear that some C compilers cannot handle returning a union type.
|
|
3220 Most of the functions in GNU Emacs return type Lisp_Object, which is
|
|
3221 defined as a union on some rare architectures.
|
|
3222
|
96602
|
3223 This problem will only happen if USE_LISP_UNION_TYPE is manually
|
|
3224 defined in lisp.h.
|
25853
|
3225
|
41836
|
3226
|
75774
|
3227 This file is part of GNU Emacs.
|
|
3228
|
95004
|
3229 GNU Emacs is free software: you can redistribute it and/or modify
|
75774
|
3230 it under the terms of the GNU General Public License as published by
|
95004
|
3231 the Free Software Foundation, either version 3 of the License, or
|
|
3232 (at your option) any later version.
|
75774
|
3233
|
|
3234 GNU Emacs is distributed in the hope that it will be useful,
|
|
3235 but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
3236 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
3237 GNU General Public License for more details.
|
|
3238
|
|
3239 You should have received a copy of the GNU General Public License
|
95004
|
3240 along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>.
|
75774
|
3241
|
|
3242
|
41836
|
3243 Local variables:
|
|
3244 mode: outline
|
97732
8a5e7f0bc116
Prevent pasting a region twice on an xterm or rxvt in X.
Robert J. Chassell <bob@rattlesnake.com>
diff
changeset
|
3245 paragraph-separate: "[ ]*$"
|
41836
|
3246 end:
|
52401
|
3247
|
|
3248 arch-tag: 49fc0d95-88cb-4715-b21c-f27fb5a4764a
|