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