1858
|
1 This file describes various problems that have been encountered
|
|
2 in compiling, installing and running GNU Emacs.
|
|
3
|
1950
|
4 * `Pid xxx killed due to text modification or page I/O error'
|
|
5
|
|
6 On HP/UX, you can get that error when the Emacs executable is on an NFS
|
|
7 file system. HP/UX responds this way if it tries to swap in a page and
|
|
8 does not get a response from the server within a timeout whose default
|
|
9 value is just ten seconds.
|
|
10
|
|
11 If this happens to you, extend the timeout period.
|
|
12
|
1949
|
13 * `expand-file-name' fails to work on any but the machine you dumped Emacs on.
|
|
14
|
2098
|
15 On Ultrix, if you use any of the functions which look up information
|
|
16 in the passwd database before dumping Emacs (say, by using
|
1949
|
17 expand-file-name in site-init.el), then those functions will not work
|
|
18 in the dumped Emacs on any host but the one Emacs was dumped on.
|
|
19
|
2098
|
20 The solution? Don't use expand-file-name in site-init.el, or in
|
|
21 anything it loads. Yuck - some solution.
|
1949
|
22
|
2098
|
23 I'm not sure why this happens; if you can find out exactly what is
|
|
24 going on, and perhaps find a fix or a workaround, please let us know.
|
|
25 Perhaps the YP functions cache some information, the cache is included
|
|
26 in the dumped Emacs, and is then inaccurate on any other host.
|
1949
|
27
|
1858
|
28 * On some variants of SVR4, Emacs does not work at all with X.
|
|
29
|
|
30 Try defining BROKEN_FIONREAD in your config.h file. If this solves
|
|
31 the problem, please send a bug report to tell us this is needed; be
|
|
32 sure to say exactly what type of machine and system you are using.
|
|
33
|
|
34 * Linking says that the functions insque and remque are undefined.
|
|
35
|
|
36 Change oldXMenu/Makefile by adding insque.o to the variable OBJS.
|
|
37
|
|
38 * Emacs fails to understand most Internet host names, even though
|
|
39 the names work properly with other programs on the same system.
|
|
40
|
|
41 This typically happens on Suns and other systems that use shared
|
|
42 libraries. The cause is that the site has installed a version of the
|
|
43 shared library which uses a name server--but has not installed a
|
3591
|
44 similar version of the unshared library which Emacs uses.
|
1858
|
45
|
|
46 The result is that most programs, using the shared library, work with
|
|
47 the nameserver, but Emacs does not.
|
|
48
|
|
49 The fix is to install an unshared library that corresponds to what you
|
|
50 installed in the shared library, and then relink Emacs.
|
|
51
|
|
52 * On a Sun running SunOS 4.1.1, you get this error message from GNU ld:
|
|
53
|
|
54 /lib/libc.a(_Q_sub.o): Undefined symbol __Q_get_rp_rd referenced from text segment
|
|
55
|
|
56 The problem is in the Sun shared C library, not in GNU ld.
|
|
57
|
|
58 The solution is to install Patch-ID# 100267-03 from Sun.
|
|
59
|
|
60 * Self documentation messages are garbled.
|
|
61
|
|
62 This means that the file `etc/DOC-...' doesn't properly correspond
|
|
63 with the Emacs executable. Redumping Emacs and then installing the
|
|
64 corresponding pair of files should fix the problem.
|
|
65
|
|
66 * Trouble using ptys on AIX.
|
|
67
|
3591
|
68 People often install the pty devices on AIX incorrectly.
|
1858
|
69 Use `smit pty' to reinstall them properly.
|
|
70
|
|
71 * Shell mode on HP/UX gives the message, "`tty`: Ambiguous".
|
|
72
|
|
73 christos@theory.tn.cornell.edu says:
|
|
74
|
|
75 The problem is that in your .cshrc you have something that tries to
|
|
76 execute `tty`. If you are not running the shell on a real tty then
|
|
77 tty will print "not a tty". Csh expects one word in some places,
|
|
78 but tty is giving it back 3.
|
|
79
|
|
80 The solution is to add a pair of quotes around `tty` to make it a single
|
|
81 word:
|
|
82
|
|
83 if (`tty` == "/dev/console")
|
|
84
|
|
85 should be changed to:
|
|
86
|
|
87 if ("`tty`" == "/dev/console")
|
|
88
|
|
89 Even better, move things that set up terminal sections out of .cshrc
|
|
90 and into .login.
|
|
91
|
|
92 * Using X Windows, control-shift-leftbutton makes Emacs hang.
|
|
93
|
|
94 Use the shell command `xset bc' to make the old X Menu package work.
|
|
95
|
|
96 * Emacs running under X Windows does not handle mouse clicks.
|
|
97 * `emacs -geometry 80x20' finds a file named `80x20'.
|
|
98
|
|
99 One cause of such problems is having (setq term-file-prefix nil) in
|
|
100 your .emacs file. Another cause is a bad value of EMACSLOADPATH in
|
|
101 the environment.
|
|
102
|
|
103 * Emacs starts in a directory other than the one that is current in the shell.
|
|
104
|
|
105 If the PWD environment variable exists, Emacs uses this variable as
|
|
106 the initial working directory.
|
|
107
|
|
108 Some shells automatically update this variable, while other shells fail
|
|
109 to do so. If you use two such shells in combination, the variable can
|
|
110 end up wrong. This confuses Emacs.
|
|
111
|
|
112 The solution is to put something in the start-up file for the shell
|
|
113 that does not update PWD, to get rid of that environment variable.
|
|
114 For example, in csh, use `unsetenv PWD'.
|
|
115
|
|
116 * Emacs gets error message from linker on Sun.
|
|
117
|
|
118 If the error message says that a symbol such as `f68881_used' or
|
|
119 `ffpa_used' or `start_float' is undefined, this probably indicates
|
|
120 that you have compiled some libraries, such as the X libraries,
|
|
121 with a floating point option other than the default.
|
|
122
|
|
123 It's not terribly hard to make this work with small changes in
|
|
124 crt0.c together with linking with Fcrt1.o, Wcrt1.o or Mcrt1.o.
|
|
125 However, the easiest approach is to build Xlib with the default
|
1949
|
126 floating point option: -fsoft.
|
1858
|
127
|
|
128 * Emacs fails to get default settings from X Windows server.
|
|
129
|
|
130 The X library in X11R4 has a bug; it interchanges the 2nd and 3rd
|
|
131 arguments to XGetDefaults. Define the macro XBACKWARDS in config.h to
|
|
132 tell Emacs to compensate for this.
|
|
133
|
|
134 I don't believe there is any way Emacs can determine for itself
|
|
135 whether this problem is present on a given system.
|
|
136
|
|
137 * Keyboard input gets confused after a beep when using a DECserver
|
|
138 as a concentrator.
|
|
139
|
|
140 This problem seems to be a matter of configuring the DECserver to use
|
|
141 7 bit characters rather than 8 bit characters.
|
|
142
|
|
143 * M-x shell persistently reports "Process shell exited abnormally with code 1".
|
|
144
|
|
145 This happened on Suns as a result of what is said to be a bug in Sunos
|
|
146 version 4.0.x. The only fix was to reboot the machine.
|
|
147
|
|
148 * Programs running under terminal emulator do not recognize `emacs'
|
|
149 terminal type.
|
|
150
|
|
151 The cause of this is a shell startup file that sets the TERMCAP
|
|
152 environment variable. The terminal emulator uses that variable to
|
|
153 provide the information on the special terminal type that Emacs
|
|
154 emulates.
|
|
155
|
|
156 Rewrite your shell startup file so that it does not change TERMCAP
|
|
157 in such a case. You could use the following conditional which sets
|
|
158 it only if it is undefined.
|
|
159
|
|
160 if ( ! ${?TERMCAP} ) setenv TERMCAP ~/my-termcap-file
|
|
161
|
|
162 Or you could set TERMCAP only when you set TERM--which should not
|
|
163 happen in a non-login shell.
|
|
164
|
|
165 * X Windows doesn't work if DISPLAY uses a hostname.
|
|
166
|
|
167 People have reported kernel bugs in certain systems that cause Emacs
|
|
168 not to work with X Windows if DISPLAY is set using a host name. But
|
|
169 the problem does not occur if DISPLAY is set to `unix:0.0'. I think
|
|
170 the bug has to do with SIGIO or FIONREAD.
|
|
171
|
|
172 You may be able to compensate for the bug by doing (set-input-mode nil nil).
|
|
173 However, that has the disadvantage of turning off interrupts, so that
|
|
174 you are unable to quit out of a Lisp program by typing C-g.
|
|
175
|
|
176 The easy way to do this is to put
|
|
177
|
|
178 (setq x-sigio-bug t)
|
|
179
|
|
180 in your site-init.el file.
|
|
181
|
|
182 * Problem with remote X server on Suns.
|
|
183
|
|
184 On a Sun, running Emacs on one machine with the X server on another
|
|
185 may not work if you have used the unshared system libraries. This
|
|
186 is because the unshared libraries fail to use YP for host name lookup.
|
|
187 As a result, the host name you specify may not be recognized.
|
|
188
|
|
189 * Watch out for .emacs files and EMACSLOADPATH environment vars
|
|
190
|
|
191 These control the actions of Emacs.
|
|
192 ~/.emacs is your Emacs init file.
|
|
193 EMACSLOADPATH overrides which directories the function
|
|
194 "load" will search.
|
|
195
|
|
196 If you observe strange problems, check for these and get rid
|
|
197 of them, then try again.
|
|
198
|
|
199 * Shell mode ignores interrupts on Apollo Domain
|
|
200
|
|
201 You may find that M-x shell prints the following message:
|
|
202
|
|
203 Warning: no access to tty; thus no job control in this shell...
|
|
204
|
|
205 This can happen if there are not enough ptys on your system.
|
|
206 Here is how to make more of them.
|
|
207
|
|
208 % cd /dev
|
|
209 % ls pty*
|
|
210 # shows how many pty's you have. I had 8, named pty0 to pty7)
|
|
211 % /etc/crpty 8
|
|
212 # creates eight new pty's
|
|
213
|
|
214 * Fatal signal in the command temacs -l loadup inc dump
|
|
215
|
|
216 This command is the final stage of building Emacs. It is run by the
|
|
217 Makefile in the src subdirectory, or by build.com on VMS.
|
|
218
|
|
219 It has been known to get fatal errors due to insufficient swapping
|
|
220 space available on the machine.
|
|
221
|
|
222 On 68000's, it has also happened because of bugs in the
|
|
223 subroutine `alloca'. Verify that `alloca' works right, even
|
|
224 for large blocks (many pages).
|
|
225
|
|
226 * test-distrib says that the distribution has been clobbered
|
|
227 * or, temacs prints "Command key out of range 0-127"
|
|
228 * or, temacs runs and dumps xemacs, but xemacs totally fails to work.
|
|
229 * or, temacs gets errors dumping xemacs
|
|
230
|
|
231 This can be because the .elc files have been garbled. Do not be
|
|
232 fooled by the fact that most of a .elc file is text: these are
|
|
233 binary files and can contain all 256 byte values.
|
|
234
|
|
235 In particular `shar' cannot be used for transmitting GNU Emacs.
|
|
236 It typically truncates "lines". What appear to be "lines" in
|
|
237 a binary file can of course be of any length. Even once `shar'
|
|
238 itself is made to work correctly, `sh' discards null characters
|
|
239 when unpacking the shell archive.
|
|
240
|
|
241 I have also seen character \177 changed into \377. I do not know
|
|
242 what transfer means caused this problem. Various network
|
|
243 file transfer programs are suspected of clobbering the high bit.
|
|
244
|
|
245 If you have a copy of Emacs that has been damaged in its
|
|
246 nonprinting characters, you can fix them:
|
|
247
|
|
248 1) Record the names of all the .elc files.
|
|
249 2) Delete all the .elc files.
|
|
250 3) Recompile alloc.c with a value of PURESIZE twice as large.
|
|
251 You might as well save the old alloc.o.
|
|
252 4) Remake xemacs. It should work now.
|
|
253 5) Running xemacs, do Meta-x byte-compile-file repeatedly
|
|
254 to recreate all the .elc files that used to exist.
|
|
255 You may need to increase the value of the variable
|
|
256 max-lisp-eval-depth to succeed in running the compiler interpreted
|
|
257 on certain .el files. 400 was sufficient as of last report.
|
|
258 6) Reinstall the old alloc.o (undoing changes to alloc.c if any)
|
|
259 and remake temacs.
|
|
260 7) Remake xemacs. It should work now, with valid .elc files.
|
|
261
|
|
262 * temacs prints "Pure Lisp storage exhausted"
|
|
263
|
|
264 This means that the Lisp code loaded from the .elc and .el
|
|
265 files during temacs -l loadup inc dump took up more
|
|
266 space than was allocated.
|
|
267
|
|
268 This could be caused by
|
|
269 1) adding code to the preloaded Lisp files
|
|
270 2) adding more preloaded files in loadup.el
|
|
271 3) having a site-init.el or site-load.el which loads files.
|
|
272 Note that ANY site-init.el or site-load.el is nonstandard;
|
|
273 if you have received Emacs from some other site
|
|
274 and it contains a site-init.el or site-load.el file, consider
|
|
275 deleting that file.
|
|
276 4) getting the wrong .el or .elc files
|
|
277 (not from the directory you expected).
|
|
278 5) deleting some .elc files that are supposed to exist.
|
|
279 This would cause the source files (.el files) to be
|
|
280 loaded instead. They take up more room, so you lose.
|
|
281 6) a bug in the Emacs distribution which underestimates
|
|
282 the space required.
|
|
283
|
|
284 If the need for more space is legitimate, change the definition
|
|
285 of PURESIZE in puresize.h.
|
|
286
|
|
287 But in some of the cases listed above, this problem is a consequence
|
|
288 of something else that is wrong. Be sure to check and fix the real
|
|
289 problem.
|
|
290
|
|
291 * Changes made to .el files do not take effect.
|
|
292
|
|
293 You may have forgotten to recompile them into .elc files.
|
|
294 Then the old .elc files will be loaded, and your changes
|
|
295 will not be seen. To fix this, do M-x byte-recompile-directory
|
|
296 and specify the directory that contains the Lisp files.
|
|
297
|
2860
|
298 Emacs should print a warning when loading a .elc file which is older
|
|
299 than the corresponding .el file.
|
|
300
|
1858
|
301 * The dumped Emacs (xemacs) crashes when run, trying to write pure data.
|
|
302
|
|
303 Two causes have been seen for such problems.
|
|
304
|
|
305 1) On a system where getpagesize is not a system call, it is defined
|
|
306 as a macro. If the definition (in both unexec.c and malloc.c) is wrong,
|
|
307 it can cause problems like this. You might be able to find the correct
|
|
308 value in the man page for a.out (5).
|
|
309
|
|
310 2) Some systems allocate variables declared static among the
|
|
311 initialized variables. Emacs makes all initialized variables in most
|
|
312 of its files pure after dumping, but the variables declared static and
|
|
313 not initialized are not supposed to be pure. On these systems you
|
|
314 may need to add "#define static" to the m- or the s- file.
|
|
315
|
|
316 * Compilation errors on VMS.
|
|
317
|
|
318 You will get warnings when compiling on VMS because there are
|
|
319 variable names longer than 32 (or whatever it is) characters.
|
|
320 This is not an error. Ignore it.
|
|
321
|
|
322 VAX C does not support #if defined(foo). Uses of this construct
|
|
323 were removed, but some may have crept back in. They must be rewritten.
|
|
324
|
|
325 There is a bug in the C compiler which fails to sign extend characters
|
|
326 in conditional expressions. The bug is:
|
|
327 char c = -1, d = 1;
|
|
328 int i;
|
|
329
|
|
330 i = d ? c : d;
|
|
331 The result is i == 255; the fix is to typecast the char in the
|
|
332 conditional expression as an (int). Known occurrences of such
|
|
333 constructs in Emacs have been fixed.
|
|
334
|
|
335 * rmail gets error getting new mail
|
|
336
|
|
337 rmail gets new mail from /usr/spool/mail/$USER using a program
|
|
338 called `movemail'. This program interlocks with /bin/mail using
|
|
339 the protocol defined by /bin/mail.
|
|
340
|
|
341 There are two different protocols in general use. One of them uses
|
|
342 the `flock' system call. The other involves creating a lock file;
|
|
343 `movemail' must be able to write in /usr/spool/mail in order to do
|
|
344 this. You control which one is used by defining, or not defining,
|
|
345 the macro MAIL_USE_FLOCK in config.h or the m- or s- file it includes.
|
|
346 IF YOU DON'T USE THE FORM OF INTERLOCKING THAT IS NORMAL ON YOUR
|
|
347 SYSTEM, YOU CAN LOSE MAIL!
|
|
348
|
|
349 If your system uses the lock file protocol, and fascist restrictions
|
|
350 prevent ordinary users from writing the lock files in /usr/spool/mail,
|
|
351 you may need to make `movemail' setgid to a suitable group such as
|
|
352 `mail'. You can use these commands (as root):
|
|
353
|
|
354 chgrp mail movemail
|
|
355 chmod 2755 movemail
|
|
356
|
|
357 * Emacs won't work with X-windows if the value of DISPLAY is HOSTNAME:0.
|
|
358 * GNUs can't make contact with the specified host for nntp.
|
|
359
|
|
360 Some people have found that Emacs was unable to connect to the local
|
|
361 host by name, as in DISPLAY=prep:0 if you are running on prep, but
|
|
362 could handle DISPLAY=unix:0. Here is what tale@rpi.edu said:
|
|
363
|
|
364 Seems as
|
|
365 though gethostbyname was bombing somewhere along the way. Well, we
|
|
366 had just upgrade from SunOS 3.5 (which X11 was built under) to SunOS
|
|
367 4.0.1. Any new X applications which tried to be built with the pre
|
|
368 OS-upgrade libraries had the same problems which Emacs was having.
|
|
369 Missing /etc/resolv.conf for a little while (when one of the libraries
|
|
370 was built?) also might have had a hand in it.
|
|
371
|
|
372 The result of all of this (with some speculation) was that we rebuilt
|
|
373 X and then rebuilt Emacs with the new libraries. Works as it should
|
|
374 now. Hoorah.
|
|
375
|
|
376 If you have already installed the name resolver in the file libresolv.a,
|
|
377 then you need to compile Emacs to use that library. The easiest way to
|
|
378 do this is to add to config.h a definition of LIBS_SYSTEM, LIBS_MACHINE
|
|
379 or LIB_STANDARD which uses -lresolv. Watch out! If you redefine a macro
|
|
380 that is already in use in your configuration to supply some other libraries,
|
|
381 be careful not to lose the others.
|
|
382
|
|
383 Thus, you could start by adding this to config.h:
|
|
384
|
|
385 #define LIBS_SYSTEM -lresolv
|
|
386
|
|
387 Then if this gives you an error for redefining a macro, and you see that
|
|
388 the s- file defines LIBS_SYSTEM as -lfoo -lbar, you could change config.h
|
|
389 again to say this:
|
|
390
|
|
391 #define LIBS_SYSTEM -lresolv -lfoo -lbar
|
|
392
|
|
393 * Emacs spontaneously displays "I-search: " at the bottom of the screen.
|
|
394
|
|
395 This means that Control-S/Control-Q "flow control" is being used.
|
|
396 C-s/C-q flow control is bad for Emacs editors because it takes away
|
|
397 C-s and C-q as user commands. Since editors do not output long streams
|
|
398 of text without user commands, there is no need for a user-issuable
|
|
399 "stop output" command in an editor; therefore, a properly designed
|
|
400 flow control mechanism would transmit all possible input characters
|
|
401 without interference. Designing such a mechanism is easy, for a person
|
|
402 with at least half a brain.
|
|
403
|
|
404 There are three possible reasons why flow control could be taking place:
|
|
405
|
|
406 1) Terminal has not been told to disable flow control
|
|
407 2) Insufficient padding for the terminal in use
|
|
408 3) Some sort of terminal concentrator or line switch is responsible
|
|
409
|
|
410 First of all, many terminals have a set-up mode which controls
|
|
411 whether they generate flow control characters. This must be
|
|
412 set to "no flow control" in order for Emacs to work. Sometimes
|
|
413 there is an escape sequence that the computer can send to turn
|
|
414 flow control off and on. If so, perhaps the termcap `ti' string
|
|
415 should turn flow control off, and the `te' string should turn it on.
|
|
416
|
|
417 Once the terminal has been told "no flow control", you may find it
|
|
418 needs more padding. The amount of padding Emacs sends is controlled
|
|
419 by the termcap entry for the terminal in use, and by the output baud
|
|
420 rate as known by the kernel. The shell command `stty' will print
|
|
421 your output baud rate; `stty' with suitable arguments will set it if
|
|
422 it is wrong. Setting to a higher speed causes increased padding. If
|
|
423 the results are wrong for the correct speed, there is probably a
|
|
424 problem in the termcap entry. You must speak to a local Unix wizard
|
|
425 to fix this. Perhaps you are just using the wrong terminal type.
|
|
426
|
|
427 For terminals that lack a "no flow control" mode, sometimes just
|
|
428 giving lots of padding will prevent actual generation of flow control
|
|
429 codes. You might as well try it.
|
|
430
|
|
431 If you are really unlucky, your terminal is connected to the computer
|
|
432 through a concentrator which sends flow control to the computer, or it
|
|
433 insists on sending flow control itself no matter how much padding you
|
|
434 give it. You are screwed! You should replace the terminal or
|
|
435 concentrator with a properly designed one. In the mean time,
|
|
436 some drastic measures can make Emacs semi-work.
|
|
437
|
|
438 One drastic measure to ignore C-s and C-q, while sending enough
|
2860
|
439 padding that the terminal will not really lose any output. To make
|
|
440 such an adjustment, you need only invoke the function
|
|
441 enable-flow-control-on with a list of terminal types in your own
|
|
442 .emacs file. As arguments, give it the names of one or more terminal
|
|
443 types you use which require flow control adjustments.
|
|
444 Here's an example:
|
1858
|
445
|
2860
|
446 (enable-flow-control-on "vt200" "vt300" "vt101" "vt131")
|
1858
|
447
|
|
448 An even more drastic measure is to make Emacs use flow control.
|
|
449 To do this, evaluate the Lisp expression (set-input-mode nil t).
|
|
450 Emacs will then interpret C-s and C-q as flow control commands. (More
|
|
451 precisely, it will allow the kernel to do so as it usually does.) You
|
|
452 will lose the ability to use them for Emacs commands. Also, as a
|
|
453 consequence of using CBREAK mode, the terminal's Meta-key, if any,
|
|
454 will not work, and C-g will be liable to cause a loss of output which
|
|
455 will produce garbage on the screen. (These problems apply to 4.2BSD;
|
|
456 they may not happen in 4.3 or VMS, and I don't know what would happen
|
|
457 in sysV.) You can use keyboard-translate-table, as shown above,
|
|
458 to map two other input characters (such as C-^ and C-\) into C-s and
|
|
459 C-q, so that you can still search and quote.
|
|
460
|
3591
|
461 I have no intention of ever redesigning the Emacs command set for
|
1858
|
462 the assumption that terminals use C-s/C-q flow control. This
|
|
463 flow control technique is a bad design, and terminals that need
|
|
464 it are bad merchandise and should not be purchased. If you can
|
|
465 get some use out of GNU Emacs on inferior terminals, I am glad,
|
|
466 but I will not make Emacs worse for properly designed systems
|
|
467 for the sake of inferior systems.
|
|
468
|
|
469 * Control-S and Control-Q commands are ignored completely.
|
|
470
|
|
471 For some reason, your system is using brain-damaged C-s/C-q flow
|
|
472 control despite Emacs's attempts to turn it off. Perhaps your
|
|
473 terminal is connected to the computer through a concentrator
|
|
474 that wants to use flow control.
|
|
475
|
|
476 You should first try to tell the concentrator not to use flow control.
|
|
477 If you succeed in this, try making the terminal work without
|
|
478 flow control, as described in the preceding section.
|
|
479
|
|
480 If that line of approach is not successful, map some other characters
|
|
481 into C-s and C-q using keyboard-translate-table. The example above
|
|
482 shows how to do this with C-^ and C-\.
|
|
483
|
|
484 * Control-S and Control-Q commands are ignored completely on a net connection.
|
|
485
|
|
486 Some versions of rlogin (and possibly telnet) do not pass flow
|
|
487 control characters to the remote system to which they connect.
|
|
488 On such systems, emacs on the remote system cannot disable flow
|
|
489 control on the local system.
|
|
490
|
|
491 One way to cure this is to disable flow control on the local host
|
|
492 (the one running rlogin, not the one running rlogind) using the
|
|
493 stty command, before starting the rlogin process. On many systems,
|
|
494 "stty start u stop u" will do this.
|
|
495
|
|
496 Some versions of tcsh will prevent even this from working. One way
|
|
497 around this is to start another shell before starting rlogin, and
|
|
498 issue the stty command to disable flow control from that shell.
|
|
499
|
|
500 * Screen is updated wrong, but only on one kind of terminal.
|
|
501
|
|
502 This could mean that the termcap entry you are using for that
|
|
503 terminal is wrong, or it could mean that Emacs has a bug handing
|
|
504 the combination of features specified for that terminal.
|
|
505
|
|
506 The first step in tracking this down is to record what characters
|
|
507 Emacs is sending to the terminal. Execute the Lisp expression
|
|
508 (open-termscript "./emacs-script") to make Emacs write all
|
|
509 terminal output into the file ~/emacs-script as well; then do
|
|
510 what makes the screen update wrong, and look at the file
|
|
511 and decode the characters using the manual for the terminal.
|
|
512 There are several possibilities:
|
|
513
|
|
514 1) The characters sent are correct, according to the terminal manual.
|
|
515
|
|
516 In this case, there is no obvious bug in Emacs, and most likely you
|
|
517 need more padding, or possibly the terminal manual is wrong.
|
|
518
|
|
519 2) The characters sent are incorrect, due to an obscure aspect
|
|
520 of the terminal behavior not described in an obvious way
|
|
521 by termcap.
|
|
522
|
|
523 This case is hard. It will be necessary to think of a way for
|
|
524 Emacs to distinguish between terminals with this kind of behavior
|
|
525 and other terminals that behave subtly differently but are
|
|
526 classified the same by termcap; or else find an algorithm for
|
|
527 Emacs to use that avoids the difference. Such changes must be
|
|
528 tested on many kinds of terminals.
|
|
529
|
|
530 3) The termcap entry is wrong.
|
|
531
|
|
532 See the file etc/TERMS for information on changes
|
|
533 that are known to be needed in commonly used termcap entries
|
|
534 for certain terminals.
|
|
535
|
|
536 4) The characters sent are incorrect, and clearly cannot be
|
|
537 right for any terminal with the termcap entry you were using.
|
|
538
|
|
539 This is unambiguously an Emacs bug, and can probably be fixed
|
|
540 in termcap.c, tparam.c, term.c, scroll.c, cm.c or dispnew.c.
|
|
541
|
|
542 * Output from Control-V is slow.
|
|
543
|
|
544 On many bit-map terminals, scrolling operations are fairly slow.
|
|
545 Often the termcap entry for the type of terminal in use fails
|
|
546 to inform Emacs of this. The two lines at the bottom of the screen
|
|
547 before a Control-V command are supposed to appear at the top after
|
|
548 the Control-V command. If Emacs thinks scrolling the lines is fast,
|
|
549 it will scroll them to the top of the screen.
|
|
550
|
|
551 If scrolling is slow but Emacs thinks it is fast, the usual reason is
|
|
552 that the termcap entry for the terminal you are using does not
|
|
553 specify any padding time for the `al' and `dl' strings. Emacs
|
|
554 concludes that these operations take only as much time as it takes to
|
|
555 send the commands at whatever line speed you are using. You must
|
|
556 fix the termcap entry to specify, for the `al' and `dl', as much
|
|
557 time as the operations really take.
|
|
558
|
|
559 Currently Emacs thinks in terms of serial lines which send characters
|
|
560 at a fixed rate, so that any operation which takes time for the
|
|
561 terminal to execute must also be padded. With bit-map terminals
|
|
562 operated across networks, often the network provides some sort of
|
|
563 flow control so that padding is never needed no matter how slow
|
|
564 an operation is. You must still specify a padding time if you want
|
|
565 Emacs to realize that the operation takes a long time. This will
|
|
566 cause padding characters to be sent unnecessarily, but they do
|
|
567 not really cost much. They will be transmitted while the scrolling
|
|
568 is happening and then discarded quickly by the terminal.
|
|
569
|
|
570 Most bit-map terminals provide commands for inserting or deleting
|
|
571 multiple lines at once. Define the `AL' and `DL' strings in the
|
|
572 termcap entry to say how to do these things, and you will have
|
|
573 fast output without wasted padding characters. These strings should
|
|
574 each contain a single %-spec saying how to send the number of lines
|
|
575 to be scrolled. These %-specs are like those in the termcap
|
|
576 `cm' string.
|
|
577
|
|
578 You should also define the `IC' and `DC' strings if your terminal
|
|
579 has a command to insert or delete multiple characters. These
|
|
580 take the number of positions to insert or delete as an argument.
|
|
581
|
|
582 A `cs' string to set the scrolling region will reduce the amount
|
|
583 of motion you see on the screen when part of the screen is scrolled.
|
|
584
|
|
585 * Your Delete key sends a Backspace to the terminal, using an AIXterm.
|
|
586
|
|
587 The solution is to include in your .Xdefaults the lines:
|
|
588
|
|
589 *aixterm.Translations: #override <Key>BackSpace: string(0x7f)
|
|
590 aixterm*ttyModes: erase ^?
|
|
591
|
|
592 This makes your Backspace key send DEL (ASCII 127).
|
|
593
|
|
594 * You type Control-H (Backspace) expecting to delete characters.
|
|
595
|
|
596 Put `stty dec' in your .login file and your problems will disappear
|
|
597 after a day or two.
|
|
598
|
|
599 The choice of Backspace for erasure was based on confusion, caused by
|
|
600 the fact that backspacing causes erasure (later, when you type another
|
|
601 character) on most display terminals. But it is a mistake. Deletion
|
|
602 of text is not the same thing as backspacing followed by failure to
|
|
603 overprint. I do not wish to propagate this confusion by conforming
|
|
604 to it.
|
|
605
|
|
606 For this reason, I believe `stty dec' is the right mode to use,
|
|
607 and I have designed Emacs to go with that. If there were a thousand
|
|
608 other control characters, I would define Control-h to delete as well;
|
|
609 but there are not very many other control characters, and I think
|
|
610 that providing the most mnemonic possible Help character is more
|
|
611 important than adapting to people who don't use `stty dec'.
|
|
612
|
|
613 If you are obstinate about confusing buggy overprinting with deletion,
|
|
614 you can redefine Backspace in your .emacs file:
|
|
615 (global-set-key "\b" 'delete-backward-char)
|
|
616 You may then wish to put the function help-command on some
|
|
617 other key. I leave to you the task of deciding which key.
|
|
618
|
|
619 * Editing files through RFS gives spurious "file has changed" warnings.
|
|
620 It is possible that a change in Emacs 18.37 gets around this problem,
|
|
621 but in case not, here is a description of how to fix the RFS bug that
|
|
622 causes it.
|
|
623
|
|
624 There was a serious pair of bugs in the handling of the fsync() system
|
|
625 call in the RFS server.
|
|
626
|
|
627 The first is that the fsync() call is handled as another name for the
|
|
628 close() system call (!!). It appears that fsync() is not used by very
|
|
629 many programs; Emacs version 18 does an fsync() before closing files
|
|
630 to make sure that the bits are on the disk.
|
|
631
|
|
632 This is fixed by the enclosed patch to the RFS server.
|
|
633
|
|
634 The second, more serious problem, is that fsync() is treated as a
|
|
635 non-blocking system call (i.e., it's implemented as a message that
|
|
636 gets sent to the remote system without waiting for a reply). Fsync is
|
|
637 a useful tool for building atomic file transactions. Implementing it
|
|
638 as a non-blocking RPC call (when the local call blocks until the sync
|
|
639 is done) is a bad idea; unfortunately, changing it will break the RFS
|
|
640 protocol. No fix was supplied for this problem.
|
|
641
|
|
642 (as always, your line numbers may vary)
|
|
643
|
|
644 % rcsdiff -c -r1.2 serversyscall.c
|
|
645 RCS file: RCS/serversyscall.c,v
|
|
646 retrieving revision 1.2
|
|
647 diff -c -r1.2 serversyscall.c
|
|
648 *** /tmp/,RCSt1003677 Wed Jan 28 15:15:02 1987
|
|
649 --- serversyscall.c Wed Jan 28 15:14:48 1987
|
|
650 ***************
|
|
651 *** 163,169 ****
|
|
652 /*
|
|
653 * No return sent for close or fsync!
|
|
654 */
|
|
655 ! if (syscall == RSYS_close || syscall == RSYS_fsync)
|
|
656 proc->p_returnval = deallocate_fd(proc, msg->m_args[0]);
|
|
657 else
|
|
658 {
|
|
659 --- 166,172 ----
|
|
660 /*
|
|
661 * No return sent for close or fsync!
|
|
662 */
|
|
663 ! if (syscall == RSYS_close)
|
|
664 proc->p_returnval = deallocate_fd(proc, msg->m_args[0]);
|
|
665 else
|
|
666 {
|
|
667
|
|
668 * Vax C compiler bugs affecting Emacs.
|
|
669
|
|
670 You may get one of these problems compiling Emacs:
|
|
671
|
|
672 foo.c line nnn: compiler error: no table entry for op STASG
|
|
673 foo.c: fatal error in /lib/ccom
|
|
674
|
|
675 These are due to bugs in the C compiler; the code is valid C.
|
|
676 Unfortunately, the bugs are unpredictable: the same construct
|
|
677 may compile properly or trigger one of these bugs, depending
|
|
678 on what else is in the source file being compiled. Even changes
|
|
679 in header files that should not affect the file being compiled
|
|
680 can affect whether the bug happens. In addition, sometimes files
|
|
681 that compile correctly on one machine get this bug on another machine.
|
|
682
|
|
683 As a result, it is hard for me to make sure this bug will not affect
|
|
684 you. I have attempted to find and alter these constructs, but more
|
|
685 can always appear. However, I can tell you how to deal with it if it
|
|
686 should happen. The bug comes from having an indexed reference to an
|
|
687 array of Lisp_Objects, as an argument in a function call:
|
|
688 Lisp_Object *args;
|
|
689 ...
|
|
690 ... foo (5, args[i], ...)...
|
|
691 putting the argument into a temporary variable first, as in
|
|
692 Lisp_Object *args;
|
|
693 Lisp_Object tem;
|
|
694 ...
|
|
695 tem = args[i];
|
|
696 ... foo (r, tem, ...)...
|
|
697 causes the problem to go away.
|
|
698 The `contents' field of a Lisp vector is an array of Lisp_Objects,
|
|
699 so you may see the problem happening with indexed references to that.
|
|
700
|
|
701 * 68000 C compiler problems
|
|
702
|
|
703 Various 68000 compilers have different problems.
|
|
704 These are some that have been observed.
|
|
705
|
|
706 ** Using value of assignment expression on union type loses.
|
|
707 This means that x = y = z; or foo (x = z); does not work
|
|
708 if x is of type Lisp_Object.
|
|
709
|
|
710 ** "cannot reclaim" error.
|
|
711
|
|
712 This means that an expression is too complicated. You get the correct
|
|
713 line number in the error message. The code must be rewritten with
|
|
714 simpler expressions.
|
|
715
|
|
716 ** XCONS, XSTRING, etc macros produce incorrect code.
|
|
717
|
|
718 If temacs fails to run at all, this may be the cause.
|
|
719 Compile this test program and look at the assembler code:
|
|
720
|
|
721 struct foo { char x; unsigned int y : 24; };
|
|
722
|
|
723 lose (arg)
|
|
724 struct foo arg;
|
|
725 {
|
|
726 test ((int *) arg.y);
|
|
727 }
|
|
728
|
|
729 If the code is incorrect, your compiler has this problem.
|
|
730 In the XCONS, etc., macros in lisp.h you must replace (a).u.val with
|
|
731 ((a).u.val + coercedummy) where coercedummy is declared as int.
|
|
732
|
|
733 This problem will not happen if the m-...h file for your type
|
|
734 of machine defines NO_UNION_TYPE. That is the recommended setting now.
|
|
735
|
|
736 * C compilers lose on returning unions
|
|
737
|
2860
|
738 I hear that some C compilers cannot handle returning a union type.
|
|
739 Most of the functions in GNU Emacs return type Lisp_Object, which is
|
|
740 defined as a union on some rare architectures.
|
1858
|
741
|
|
742 This problem will not happen if the m-...h file for your type
|
2860
|
743 of machine defines NO_UNION_TYPE.
|
1858
|
744
|