| 1 | This file describes various problems that have been encountered |
| 2 | in compiling, installing and running GNU Emacs. |
| 3 | |
| 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 | |
| 13 | * `expand-file-name' fails to work on any but the machine you dumped Emacs on. |
| 14 | |
| 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 |
| 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 | |
| 20 | The solution? Don't use expand-file-name in site-init.el, or in |
| 21 | anything it loads. Yuck - some solution. |
| 22 | |
| 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. |
| 27 | |
| 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 |
| 44 | similar version of the unshared library which Emacs uses. |
| 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 | |
| 68 | People often install the pty devices on AIX incorrectly. |
| 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 |
| 126 | floating point option: -fsoft. |
| 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 | |
| 298 | Emacs should print a warning when loading a .elc file which is older |
| 299 | than the corresponding .el file. |
| 300 | |
| 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 |
| 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: |
| 445 | |
| 446 | (enable-flow-control-on "vt200" "vt300" "vt101" "vt131") |
| 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 | |
| 461 | I have no intention of ever redesigning the Emacs command set for |
| 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 | |
| 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. |
| 741 | |
| 742 | This problem will not happen if the m-...h file for your type |
| 743 | of machine defines NO_UNION_TYPE. |
| 744 | |