Mercurial > hg > xemacs-beta
annotate PROBLEMS @ 4792:95b04754ea8c
Make #'equalp more compatible with CL; add a compiler macro, test & doc it.
lisp/ChangeLog addition:
2009-11-08 Aidan Kehoe <kehoea@parhasard.net>
* cl-extra.el (cl-string-vector-equalp)
(cl-bit-vector-vector-equalp, cl-vector-array-equalp)
(cl-hash-table-contents-equalp): New functions, to implement
equalp treating arrays with identical contents as equivalent, as
specified by Common Lisp.
(equalp): Revise this function to implement array equivalence,
and the hash-table equalp behaviour specified by CL.
* cl-macs.el (equalp): Add a compiler macro for this function,
used when one of the arguments is constant, and as such, its type
is known at compile time.
man/ChangeLog addition:
2009-11-08 Aidan Kehoe <kehoea@parhasard.net>
* lispref/objects.texi (Equality Predicates):
Document #'equalp here, as well as #'equal and #'eq.
tests/ChangeLog addition:
2009-12-31 Aidan Kehoe <kehoea@parhasard.net>
* automated/lisp-tests.el:
Test much of the functionality of equalp; add a pointer to Paul
Dietz' ANSI test suite for this function, converted to Emacs
Lisp. Not including the tests themselves in XEmacs because who
owns the copyright on the files is unclear and the GCL people
didn't respond to my queries.
| author | Aidan Kehoe <kehoea@parhasard.net> |
|---|---|
| date | Thu, 31 Dec 2009 15:09:41 +0000 |
| parents | dd933a82720c |
| children | 1d775c6304d1 |
| rev | line source |
|---|---|
| 278 | 1 -*- mode:outline -*- |
| 2 | |
| 0 | 3 This file describes various problems that have been encountered |
| 197 | 4 in compiling, installing and running XEmacs. It has been updated for |
|
4634
c064d7197712
Add historical deprecation to PROBLEMS.
Stephen J. Turnbull <stephen@xemacs.org>
parents:
3863
diff
changeset
|
5 XEmacs 21.5. Note that the issues are by now mainly historic; XEmacs |
|
c064d7197712
Add historical deprecation to PROBLEMS.
Stephen J. Turnbull <stephen@xemacs.org>
parents:
3863
diff
changeset
|
6 no longer depends on bleeding edge features of operating systems, but |
|
c064d7197712
Add historical deprecation to PROBLEMS.
Stephen J. Turnbull <stephen@xemacs.org>
parents:
3863
diff
changeset
|
7 rather is quite conservative. Operational issues (common user |
|
c064d7197712
Add historical deprecation to PROBLEMS.
Stephen J. Turnbull <stephen@xemacs.org>
parents:
3863
diff
changeset
|
8 misunderstandings and such) are described in the FAQ, not here. |
| 0 | 9 |
| 278 | 10 This file is rather large, but we have tried to sort the entries by |
| 11 their respective relevance for XEmacs, but may have not succeeded | |
| 12 completely in that task. The file is divided into four parts: | |
| 124 | 13 |
| 197 | 14 - Problems with building XEmacs |
| 15 - Problems with running XEmacs | |
| 16 - Compatibility problems | |
| 17 - Mule issues | |
| 120 | 18 |
| 197 | 19 Use `C-c C-f' to move to the next equal level of outline, and |
| 223 | 20 `C-c C-b' to move to previous equal level. `C-h m' will give more |
| 21 info about the Outline mode. | |
| 120 | 22 |
| 197 | 23 Also, Try finding the things you need using one of the search commands |
| 24 XEmacs provides (e.g. `C-s'). | |
| 25 | |
| 524 | 26 General advice: |
| 957 | 27 |
| 524 | 28 WATCH OUT for your init file! (~/.xemacs/init.el or ~/.emacs) If |
| 29 you observe strange problems, invoke XEmacs with the `-vanilla' | |
| 30 option and see if you can repeat the problem. | |
| 197 | 31 |
| 957 | 32 Note that most of the problems described here manifest at RUN |
| 33 time, even those described as BUILD problems. It is quite unusual | |
| 34 for a released XEmacs to fail to build. So a "build problem" | |
| 35 requires you to tweak the build environment, then rebuild XEmacs. | |
| 36 A "runtime problem" is one that can be fixed by proper | |
| 37 configuration of the existing build. Compatibility problems and | |
| 38 Mule issues are generally runtime problems, but are treated | |
| 39 separately for convenience. | |
| 40 | |
| 120 | 41 |
| 124 | 42 * Problems with building XEmacs |
| 197 | 43 =============================== |
| 0 | 44 |
| 373 | 45 ** General |
| 1245 | 46 |
| 915 | 47 Much general information is in INSTALL. If it's covered in |
| 48 INSTALL, we don't repeat it here. | |
| 49 | |
| 3404 | 50 *** X11/bitmaps/gray (or other X11-related file) not found. |
| 51 | |
| 52 The X11R6 distribution was monolithic, but the X11R7 distribution is | |
| 53 much more modular. Many OS distributions omit these bitmaps (assuming | |
| 54 nobody uses them, evidently). Your OS distribution should have a | |
| 55 developer's package containing these files, probably with a name | |
| 56 containing the string "bitmap". Known package names (you may need to | |
| 57 add an extension such as .deb or .rpm) include x11/xbitmaps (Ubuntu) | |
| 58 and xorg-x11-xbitmaps (Fedora Core 5). | |
| 59 | |
| 1098 | 60 *** How do I configure to get the buffer tabs/progress bars? |
| 915 | 61 |
| 62 These features depend on support for "native widgets". Use the | |
| 2648 | 63 --enable-widgets option to configure. Configuration of widgets is |
| 915 | 64 automatic for "modern" toolkits (MS Windows, GTK, and Motif), but if |
| 65 you are using Xt and the Athena widgets, you will probably want to | |
| 66 specify a "3d" widget set. See configure --usage, and don't forget to | |
| 67 install the corresponding development libraries. | |
| 68 | |
| 69 *** I know I have libfoo installed, but configure doesn't find it. | |
| 70 | |
| 71 Typical of Linux systems with package managers. To link with a shared | |
| 72 library, you only need the shared library. To compile objects that | |
| 73 link with it, you need the headers---and distros don't provide them with | |
| 74 the libraries. You need the additional "development" package, too. | |
| 75 | |
| 373 | 76 *** When using gcc, you get the error message "undefined symbol __fixunsdfsi". |
| 77 When using gcc, you get the error message "undefined symbol __main". | |
| 78 | |
| 79 This means that you need to link with the gcc library. It may be called | |
| 80 "gcc-gnulib" or "libgcc.a"; figure out where it is, and define LIB_GCC in | |
| 81 config.h to point to it. | |
| 82 | |
| 83 It may also work to use the GCC version of `ld' instead of the standard one. | |
| 84 | |
| 85 *** Excessive optimization with pgcc can break XEmacs | |
| 124 | 86 |
| 87 It has been reported on some systems that compiling with -O6 can lead | |
| 88 to XEmacs failures. The workaround is to use a lower optimization | |
| 89 level. -O2 and -O4 have been tested extensively. | |
| 90 | |
| 229 | 91 All of this depends heavily on the version of pgcc and the version |
| 92 of libc. Snapshots near the release of pgcc-1.0 have been tested | |
| 93 extensively and no sign of breakage has been seen on systems using | |
| 94 glibc-2. | |
| 95 | |
| 373 | 96 *** src/Makefile and lib-src/Makefile are truncated--most of the file missing. |
| 229 | 97 |
| 373 | 98 This can happen if configure uses GNU sed version 2.03. That version |
| 99 had a bug. GNU sed version 2.05 works properly. | |
| 124 | 100 |
| 373 | 101 *** When compiling with X11, you get "undefined symbol _XtStrings". |
| 124 | 102 |
| 373 | 103 This means that you are trying to link emacs against the X11r4 version of |
| 104 libXt.a, but you have compiled either Emacs or the code in the lwlib | |
| 105 subdirectory with the X11r5 header files. That doesn't work. | |
| 124 | 106 |
| 373 | 107 Remember, you can't compile lwlib for r4 and emacs for r5, or vice versa. |
| 108 They must be in sync. | |
| 124 | 109 |
| 373 | 110 *** test-distrib says that the distribution has been clobbered |
| 197 | 111 or, temacs prints "Command key out of range 0-127" |
| 112 or, temacs runs and dumps xemacs, but xemacs totally fails to work. | |
| 113 or, temacs gets errors dumping xemacs | |
| 114 | |
| 115 This can be because the .elc files have been garbled. Do not be | |
| 116 fooled by the fact that most of a .elc file is text: these are binary | |
| 117 files and can contain all 256 byte values. | |
| 118 | |
| 119 In particular `shar' cannot be used for transmitting GNU Emacs. It | |
| 120 typically truncates "lines". (this does not apply to GNU shar, which | |
| 121 uses uuencode to encode binary files.) | |
| 122 | |
| 123 If you have a copy of Emacs that has been damaged in its nonprinting | |
| 124 characters, you can fix them by running: | |
| 125 | |
| 126 make all-elc | |
| 127 | |
| 128 This will rebuild all the needed .elc files. | |
| 129 | |
| 1318 | 130 ** Intel Architecture General |
| 131 | |
| 132 *** Don't use -O2 or -O3 with Cygwin 1.0, CodeFusion-99070 or gcc 2.7.2 on x86 | |
| 133 without also using `-fno-strength-reduce'. | |
| 134 | |
| 135 gcc will generate incorrect code otherwise. This bug is present in at | |
| 136 least 2.6.x and 2.7.[0-2]. This bug has been fixed in GCC 2.7.2.1 and | |
| 137 later. This bug is O/S independent, but is limited to x86 architectures. | |
| 138 | |
| 139 This problem is known to be fixed in egcs (or pgcc) 1.0 or later. | |
| 140 | |
| 141 Unfortunately, later releases of Cygnus-released compilers (not the | |
| 142 Net-released ones) have a bug with the same `problem signature'. | |
| 143 | |
| 144 If you're lucky, you'll get an error while compiling that looks like: | |
| 145 | |
| 146 event-stream.c:3189: internal error--unrecognizable insn: | |
| 147 (insn 256 14 15 (set (reg/v:SI 24) | |
| 148 (minus:SI (reg/v:SI 25) | |
| 149 (const_int 2))) -1 (insn_list 11 (nil)) | |
| 150 (nil)) | |
| 151 0 0 [main] | |
| 152 | |
| 153 If you're unlucky, your code will simply execute incorrectly. | |
| 154 | |
| 155 *** Don't use -O2 with gcc 2.7.2 under Intel architectures without also | |
| 156 using `-fno-caller-saves'. | |
| 157 | |
| 158 gcc will generate incorrect code otherwise. This bug is still | |
| 159 present in gcc 2.7.2.3. There have been no reports to indicate the | |
| 160 bug is present in egcs 1.0 (or pgcc 1.0) or later. This bug is O/S | |
| 161 independent, but limited to x86 architectures. | |
| 162 | |
| 163 This problem is known to be fixed in egcs (or pgcc) 1.0 or later. | |
| 164 | |
| 373 | 165 *** `compress' and `uncompress' not found and XFree86 |
| 166 | |
| 167 XFree86 installs a very old version of libz.a by default ahead of where | |
| 168 more modern version of libz might be installed. This will cause problems | |
| 169 when attempting to link against libMagick. The fix is to remove the old | |
| 170 libz.a in the X11 binary directory. | |
| 171 | |
| 172 | |
| 3863 | 173 ** X11 and Motif |
| 1245 | 174 |
| 175 Motif is the X11 version of the Gnus torture test: if there's a way to | |
| 176 crash, Motif will find it. With the open source release of Motif, it | |
| 177 seems like a good idea to collect all Motif-related issues in one | |
| 3863 | 178 place. X11 itself is not all that safe, either. |
| 179 | |
| 180 You should also look in your OS's section, as it may not be the window | |
| 181 system (toolkit's) fault. | |
| 182 | |
| 183 *** XEmacs and the X server crash when inserting or displaying a TAB character. | |
| 184 | |
| 185 If you are using the XFree86 distribution, you need an X server with | |
| 186 this patch applied: | |
| 187 | |
| 188 https://bugs.freedesktop.org/attachment.cgi?id=2016 | |
| 189 | |
| 190 Versions of XFree86 previous to that crashed when an app tried to draw a | |
| 191 literal tab character using many fonts. | |
| 1245 | 192 |
| 193 *** XEmacs crashes on exit (#1). | |
| 194 | |
| 195 The backtrace is something like: | |
| 196 | |
| 197 (gdb) where | |
| 198 #0 0xfeb9a480 in _libc_kill () from /usr/lib/libc.so.1 | |
| 199 #1 0x000b0388 in fatal_error_signal () | |
| 200 #2 <signal handler called> | |
| 201 #3 YowIter (ht=0xb, id=0x0, v=0x74682074, client=0x47e3c0) | |
| 202 at ImageCache.c:1159 | |
| 203 #4 0xff26cc5c in _LTHashTableForEachItem (ht=0x4725e8, | |
| 204 iter=0xff26dda0 <YowIter>, ClientData=0x47e3c0) at Hash.c:671 | |
| 205 #5 0xff2a4664 in destroy (w=0x496550) at Screen.c:352 | |
| 206 #6 0xfef92118 in Phase2Destroy () from /usr/openwin/lib/libXt.so.4 | |
| 207 #7 0xfef91940 in Recursive () from /usr/openwin/lib/libXt.so.4 | |
| 208 #8 0xfef91e44 in XtPhase2Destroy () from /usr/openwin/lib/libXt.so.4 | |
| 209 #9 0xfef91ae8 in _XtDoPhase2Destroy () from /usr/openwin/lib/libXt.so.4 | |
| 210 #10 0xfef918cc in XtDestroyWidget () from /usr/openwin/lib/libXt.so.4 | |
| 211 #11 0xfef91438 in CloseDisplay () from /usr/openwin/lib/libXt.so.4 | |
| 212 #12 0xfef91394 in XtCloseDisplay () from /usr/openwin/lib/libXt.so.4 | |
| 213 #13 0x0025b8b0 in x_delete_device () | |
| 214 #14 0x000940b0 in delete_device_internal () | |
| 215 #15 0x000806a0 in delete_console_internal () | |
| 216 | |
| 217 This is known to happen with Lesstif version 0.93.36. Similar | |
| 218 backtraces have also been observed on HP/UX and Solaris. There is a | |
| 219 patch for Lesstif. (This is not a solution; it just stops the crash. | |
| 220 It may or may not be harmless, but "it works for the author".) | |
| 221 | |
| 222 Note that this backtrace looks a lot like the one in the next item. | |
| 223 However, this one is invulnerable to the Solaris patches mentioned there. | |
| 224 | |
| 225 Frank McIngvale <frankm@hiwaay.net> says: | |
| 226 | |
| 227 Ok, 0.93.34 works, and I tracked down the crash to a section | |
| 228 marked "experimental" in 0.93.36. Patch attached, "works for me". | |
| 229 | |
| 230 diff -u -r lesstif-0.93.36/lib/Xm/ImageCache.c lesstif-0.93.36-mod/lib/Xm/ImageCache.c | |
| 231 --- lesstif-0.93.36/lib/Xm/ImageCache.c 2002-08-05 14:53:24.000000000 -0500 | |
| 232 +++ lesstif-0.93.36-mod/lib/Xm/ImageCache.c 2002-11-11 11:13:12.000000000 -0600 | |
| 233 @@ -1166,5 +1166,4 @@ | |
| 234 DEBUGOUT(_LtDebug0(__FILE__, NULL, "_LtImageCacheScreenDestroy (XmGetPixmapByDepth) %p\n", | |
| 235 s)); | |
| 236 | |
| 237 - (void) _LTHashTableForEachItem(PixmapCache, YowIter, (XtPointer)s); | |
| 238 } | |
| 239 | |
| 240 *** XEmacs crashes on exit (#2) | |
| 241 | |
| 242 Especially frequent with multiple frames. Crashes that produce C | |
| 243 backtraces like this: | |
| 244 | |
| 245 #0 0xfec9a118 in _libc_kill () from /usr/lib/libc.so.1 | |
| 246 #1 0x77f48 in fatal_error_signal (sig=11) | |
| 247 at /codes/rpluim/xemacs-21.4/src/emacs.c:539 | |
| 248 #2 <signal handler called> | |
| 249 #3 0xfee929f4 in XFindContext () from /usr/openwin/lib/libX11.so.4 | |
| 250 #4 0xfee92930 in XFindContext () from /usr/openwin/lib/libX11.so.4 | |
| 251 #5 0xff297e54 in DisplayDestroy () from /usr/dt/lib/libXm.so.4 | |
| 252 #6 0xfefbece0 in XtCallCallbackList () from /usr/openwin/lib/libXt.so.4 | |
| 253 #7 0xfefc486c in XtPhase2Destroy () from /usr/openwin/lib/libXt.so.4 | |
| 254 #8 0xfefc45d0 in _XtDoPhase2Destroy () from /usr/openwin/lib/libXt.so.4 | |
| 255 #9 0xfefc43b4 in XtDestroyWidget () from /usr/openwin/lib/libXt.so.4 | |
| 256 #10 0x15cf9c in x_delete_device (d=0x523f00) | |
| 257 | |
| 258 are caused by buggy Motif libraries. Installing the following patches | |
| 259 has been reported to solve the problem on Solaris 2.7: | |
| 260 | |
| 261 107081-40 107656-07 | |
| 262 | |
| 263 For information (although they have not been confirmed to work), the | |
| 264 equivalent patches for Solaris 2.8 are: | |
| 265 | |
| 266 108940-33 108652-25 | |
| 267 | |
| 268 *** On HP-UX 11.0 XEmacs causes excessive X11 errors when running. | |
| 269 (also appears on AIX as reported in comp.emacs.xemacs) | |
| 270 | |
| 271 Marcus Thiessel <marcus@xemacs.org> | |
| 272 | |
| 273 Unfortunately, XEmacs releases prior to 21.0 don't work with | |
| 274 Motif2.1. It will compile but you will get excessive X11 errors like | |
| 275 | |
| 276 xemacs: X Error of failed request: BadGC (invalid GC parameter) | |
| 277 | |
| 278 and finally XEmacs gets killed. A workaround is to use the | |
| 279 Motif1.2_R6 libraries. You can the following line to your call to | |
| 280 configure: | |
| 281 | |
| 282 --x-libraries="/usr/lib/Motif1.2_R6 -L/usr/lib/X11R6" | |
| 283 | |
| 284 Make sure /usr/lib/Motif1.2_R6/libXm.sl is a link to | |
| 285 /usr/lib/Motif1.2_R6/libXm.3. | |
| 286 | |
| 287 *** On HP-UX 11.0: Object "" does not have windowed ancestor | |
| 288 | |
| 289 Marcus Thiessel <marcus@xemacs.org> | |
| 290 | |
| 291 XEmacs dies without core file and reports: | |
| 292 | |
| 293 Error: Object "" does not have windowed ancestor. | |
| 294 | |
| 295 This is a bug. Please apply the patch PHSS_19964 (check if | |
| 296 superseded). The other alternative is to link with Motif1.2_R6 (see | |
| 297 previous item). | |
| 298 | |
| 299 *** Motif dialog boxes lose on Irix. | |
| 300 | |
| 301 Larry Auton <lda@control.att.com> writes: | |
| 302 Beware of not specifying | |
| 303 | |
| 2648 | 304 --enable-dialogs=athena |
| 1245 | 305 |
| 306 if it builds with the motif dialogs [boom!] you're a dead man. | |
| 307 | |
| 308 | |
| 373 | 309 ** AIX |
| 1009 | 310 *** IBM compiler fails: "The character # is not a valid C source character." |
| 311 | |
| 312 Most recently observed in 21.5.9, due to USE_KKCC ifdefs (they just | |
| 313 happen to tickle the implementation). | |
| 314 | |
| 315 Valdis Kletnieks says: | |
| 316 | |
| 317 The problem is that IBM defines a *MACRO* called 'memcpy', and we | |
| 318 have stuck a #ifdef/#endif inside the macro call. As a workaround, | |
| 319 try adding '-U__STR__' to your CFLAGS - this will cause string.h to | |
| 320 not do a #define for strcpy() to __strcpy() - it uses this for | |
| 321 automatic inlining support. | |
| 322 | |
| 323 (For the record, the same issue affects a number of other functions | |
| 324 defined in string.h - basically anything the compiler knows how to | |
| 325 inline.) | |
| 326 | |
| 2648 | 327 *** On AIX 4.3, you must specify --enable-dialogs=athena with configure |
| 373 | 328 |
| 442 | 329 *** The libXt shipped with AIX 4.3 up to 4.3.2 is broken. This causes |
| 330 xemacs -nw to fail in various ways. The official APAR is this: | |
| 331 | |
| 332 APAR NUMBER: <IX89470> RESOLVED AS: PROGRAM ERROR | |
| 333 | |
| 334 ABSTRACT: | |
| 335 <IX89470>: LIBXT.A INCORRECT HANDLING OF EXCEPTIONS IN XTAPPADDINPUT | |
| 336 | |
| 337 The solution is to install X11.base.lib at version >=4.3.2.5. | |
| 392 | 338 |
| 373 | 339 *** On AIX, you get this compiler error message: |
| 340 | |
| 341 Processing include file ./XMenuInt.h | |
| 342 1501-106: (S) Include file X11/Xlib.h not found. | |
| 343 | |
| 344 This means your system was installed with only the X11 runtime i.d | |
| 345 libraries. You have to find your sipo (bootable tape) and install | |
| 346 X11Dev... with smit. | |
| 347 | |
| 348 *** On AIX 4.1.2, linker error messages such as | |
| 349 ld: 0711-212 SEVERE ERROR: Symbol .__quous, found in the global symbol table | |
| 350 of archive /usr/lib/libIM.a, was not defined in archive member shr.o. | |
| 351 | |
| 352 This is a problem in libIM.a. You can work around it by executing | |
| 353 these shell commands in the src subdirectory of the directory where | |
| 354 you build Emacs: | |
| 355 | |
| 356 cp /usr/lib/libIM.a . | |
| 357 chmod 664 libIM.a | |
| 358 ranlib libIM.a | |
| 359 | |
| 360 Then change -lIM to ./libIM.a in the command to link temacs (in | |
| 361 Makefile). | |
| 362 | |
| 363 *** Excessive optimization on AIX 4.2 can lead to compiler failure. | |
| 364 | |
| 365 Valdis.Kletnieks@vt.edu writes: | |
| 366 At least at the b34 level, and the latest-and-greatest IBM xlc | |
| 367 (3.1.4.4), there are problems with -O3. I haven't investigated | |
| 368 further. | |
| 369 | |
| 370 | |
| 371 ** SunOS/Solaris | |
| 1318 | 372 *** Don't use -O2 with gcc 2.8.1 and egcs 1.0 under SPARC architectures |
| 373 without also using `-fno-schedule-insns'. | |
| 374 | |
| 375 gcc will generate incorrect code otherwise, typically resulting in | |
| 376 crashes in the function skip-syntax-backward. | |
| 377 | |
| 378 *** Don't use gcc-2.95.2 with -mcpu=ultrasparc on Solaris 2.6. | |
| 379 | |
| 380 gcc will assume a 64-bit operating system, even though you've | |
| 381 merely told it to assume a 64-bit instruction set. | |
| 382 | |
| 454 | 383 *** Dumping error when using GNU binutils / GNU ld on a Sun. |
| 384 | |
| 385 Errors similar to the following: | |
| 386 | |
| 387 Dumping under the name xemacs unexec(): | |
| 388 dldump(/space/rpluim/xemacs-obj/src/xemacs): ld.so.1: ./temacs: | |
| 389 fatal: /space/rpluim/xemacs-obj/src/xemacs: unknown dynamic entry: | |
| 390 1879048176 | |
| 391 | |
| 392 are caused by using GNU ld. There are several workarounds available: | |
| 393 | |
| 394 In XEmacs 21.2 or later, configure using the new portable dumper | |
| 2648 | 395 (--enable-pdump). |
| 454 | 396 |
| 397 Alternatively, you can link using the Sun version of ld, which is | |
| 398 normally held in /usr/ccs/bin. This can be done by one of: | |
| 399 | |
| 400 - building gcc with these configure flags: | |
| 401 configure --with-ld=/usr/ccs/bin/ld --with-as=/usr/ccs/bin/as | |
| 402 | |
| 403 - adding -B/usr/ccs/bin/ to CFLAGS used to configure XEmacs | |
| 404 (Note: The trailing '/' there is significant.) | |
| 405 | |
| 406 - uninstalling GNU ld. | |
| 407 | |
| 408 The Solaris2 FAQ claims: | |
| 409 | |
| 410 When you install gcc, don't make the mistake of installing | |
| 411 GNU binutils or GNU libc, they are not as capable as their | |
| 412 counterparts you get with Solaris 2.x. | |
| 413 | |
| 373 | 414 *** Link failure when using acc on a Sun. |
| 415 | |
| 416 To use acc, you need additional options just before the libraries, such as | |
| 417 | |
| 418 /usr/lang/SC2.0.1/values-Xt.o -L/usr/lang/SC2.0.1/cg87 -L/usr/lang/SC2.0.1 | |
| 419 | |
| 420 and you need to add -lansi just before -lc. | |
| 421 | |
| 422 The precise file names depend on the compiler version, so we | |
| 423 cannot easily arrange to supply them. | |
| 424 | |
| 425 *** Problems finding X11 libraries on Solaris with Openwindows | |
| 426 | |
| 427 Some users have reported problems in this area. The reported solution | |
| 428 is to define the environment variable OPENWINHOME, even if you must set | |
| 429 it to `/usr/openwin'. | |
| 430 | |
| 431 *** Sed problems on Solaris 2.5 | |
| 432 | |
| 433 There have been reports of Sun sed truncating very lines in the | |
| 434 Makefile during configuration. The workaround is to use GNU sed or, | |
| 454 | 435 even better, think of a better way to generate Makefile, and send us a |
| 373 | 436 patch. :-) |
| 437 | |
| 438 *** On Solaris 2 I get undefined symbols from libcurses.a. | |
| 439 | |
| 440 You probably have /usr/ucblib/ on your LD_LIBRARY_PATH. Do the link with | |
| 441 LD_LIBRARY_PATH unset. Generally, avoid using any ucb* stuff when | |
| 442 building XEmacs. | |
| 443 | |
| 444 *** On Solaris 2 I cannot make alloc.o, glyphs.o or process.o. | |
| 445 | |
| 446 The SparcWorks C compiler may have difficulty building those modules | |
| 447 with optimization level -xO4. Try using only "-fast" optimization | |
| 448 for just those modules. (Or use gcc). | |
| 449 | |
| 450 *** Solaris 2.3 /bin/sh coredumps during configuration. | |
| 451 | |
| 452 This only occurs if you have LANG != C. This is a known bug with | |
| 453 /bin/sh fixed by installing Patch-ID# 101613-01. Or, you can use | |
| 1697 | 454 bash by setting the environment variable CONFIG_SHELL to /bin/bash |
| 455 | |
| 456 *** Solaris 2.x configure fails: ./config.status: test: argument expected | |
| 457 | |
| 458 This is a known bug with /bin/sh and /bin/test, i.e. they do not | |
| 459 support the XPG4 standard. You can use bash as a workaround or an | |
| 460 XPG4-compliant Bourne shell such as the Sun-supplied /usr/xpg4/bin/sh | |
| 461 by setting the environment variable CONFIG_SHELL to /usr/xpg4/bin/sh | |
| 373 | 462 |
| 463 *** On SunOS, you get linker errors | |
| 454 | 464 ld: Undefined symbol |
| 373 | 465 _get_wmShellWidgetClass |
| 466 _get_applicationShellWidgetClass | |
| 467 | |
| 468 The fix to this is to install patch 100573 for OpenWindows 3.0 | |
| 469 or link libXmu statically. | |
| 470 | |
| 471 *** On Sunos 4, you get the error ld: Undefined symbol __lib_version. | |
| 472 | |
| 473 This is the result of using cc or gcc with the shared library meant | |
| 474 for acc (the Sunpro compiler). Check your LD_LIBRARY_PATH and delete | |
| 475 /usr/lang/SC2.0.1 or some similar directory. | |
| 476 | |
| 477 *** Undefined symbols when linking on Sunos 4.1. | |
| 478 | |
| 479 If you get the undefined symbols _atowc _wcslen, _iswprint, _iswspace, | |
| 480 _iswcntrl, _wcscpy, and _wcsncpy, then you need to add -lXwchar after | |
| 481 -lXaw in the command that links temacs. | |
| 482 | |
| 483 This problem seems to arise only when the international language | |
| 484 extensions to X11R5 are installed. | |
| 485 | |
| 486 *** On a Sun running SunOS 4.1.1, you get this error message from GNU ld: | |
| 487 | |
| 454 | 488 /lib/libc.a(_Q_sub.o): Undefined symbol __Q_get_rp_rd referenced from text segment |
| 373 | 489 |
| 490 The problem is in the Sun shared C library, not in GNU ld. | |
| 491 | |
| 492 The solution is to install Patch-ID# 100267-03 from Sun. | |
| 493 | |
| 494 *** SunOS 4.1.2: undefined symbol _get_wmShellWidgetClass | |
| 495 | |
| 496 Apparently the version of libXmu.so.a that Sun ships is hosed: it's missing | |
| 454 | 497 some stuff that is in libXmu.a (the static version). Sun has a patch for |
| 373 | 498 this, but a workaround is to use the static version of libXmu, by changing |
| 499 the link command from "-lXmu" to "-Bstatic -lXmu -Bdynamic". If you have | |
| 500 OpenWindows 3.0, ask Sun for these patches: | |
| 501 100512-02 4.1.x OpenWindows 3.0 libXt Jumbo patch | |
| 502 100573-03 4.1.x OpenWindows 3.0 undefined symbols with shared libXmu | |
| 503 | |
| 504 *** Random other SunOS 4.1.[12] link errors. | |
| 505 | |
| 506 The X headers and libraries that Sun ships in /usr/{include,lib}/X11 are | |
| 507 broken. Use the ones in /usr/openwin/{include,lib} instead. | |
| 508 | |
| 509 ** Linux | |
| 1318 | 510 |
| 511 See also Intel Architecture General, above. | |
| 512 | |
| 513 *** egcs-1.1 on Alpha Linux | |
| 514 | |
| 515 There have been reports of egcs-1.1 not compiling XEmacs correctly on | |
| 516 Alpha Linux. There have also been reports that egcs-1.0.3a is O.K. | |
| 517 | |
| 373 | 518 *** Under Linux, you get "too many arguments to function `getpgrp'". |
| 519 | |
| 520 You have probably installed LessTiff under `/usr/local' and `libXm.so' | |
| 521 could not be found when linking `getpgrp()' test program, making XEmacs | |
| 522 think that `getpgrp()' takes an argument. Try adding `/usr/local/lib' | |
| 523 in `/etc/ld.so.conf' and run `ldconfig'. Then run XEmacs's `configure' | |
| 524 again. As with all problems of this type, reading the config.log file | |
| 525 generated from configure and seeing the log of how the test failed can | |
| 526 prove enlightening. | |
| 527 | |
| 528 *** `Error: No ExtNode to pop!' on Linux systems with Lesstif. | |
| 197 | 529 |
| 530 This error message has been observed with lesstif-0.75a. It does not | |
| 531 appear to cause any harm. | |
| 532 | |
| 373 | 533 *** xemacs: can't resolve symbol '__malloc_hook' |
| 534 | |
| 535 This is a Linux problem where you've compiled the XEmacs binary on a libc | |
| 536 5.4 with version higher than 5.4.19 and attempted to run the binary against | |
| 537 an earlier version. The solution is to upgrade your old library. | |
| 538 | |
| 539 ** IRIX | |
| 452 | 540 |
| 1098 | 541 *** More coredumping in Irix (6.5 known to be vulnerable) |
| 542 | |
| 543 No fix is known yet. Here's the best information we have: | |
| 544 | |
| 545 Valdis Kletnieks <Valdis.Kletnieks@vt.edu> writes: | |
| 546 | |
| 547 Were xemacs and [any 3rd party, locally-compiled] libraries [you use] | |
| 548 all compiled with the same ABI ( -o32, -n32, -64) and | |
| 549 mips2/mips3/mips4 flags, and are they appropriate for the machine in | |
| 550 question? I know the IP30 implies an Octane, so it should be an R10K | |
| 551 chipset and above such nonsense, but I've seen the most astoundingly | |
| 552 bizzare crashes when somebody managed to compile with -mips4 and get | |
| 553 it to run on an R4400 or R5K system. ;) | |
| 554 | |
| 555 Also, since you're using gcc, try re-running fixincludes and *then* | |
| 556 rebuilding xemacs and [any] libraries - mismatched headers can do that | |
| 557 sort of thing to you with little or no clue what's wrong (often you | |
| 558 get screwed when one routine does an malloc(sizeof(foo_struct)) and | |
| 559 passes the result to something that things foo_struct is a bit bigger, | |
| 560 trashing memory.... | |
| 561 | |
| 2648 | 562 Here's typical crash backtrace. With --enable-pdump, this occurs |
| 563 usually at startup under X windows and xemacs -nw at least starts, while | |
| 564 without --pdump a similar crash is observed during build. | |
| 1098 | 565 |
| 566 #0 0x0fa460b8 in kill () at regcomp.c:637 | |
| 567 637 regcomp.c: No such file or directory. | |
| 568 in regcomp.c | |
| 569 (gdb) where | |
| 570 #0 0x0fa460b8 in kill () at regcomp.c:637 | |
| 571 #1 0x10087f34 in fatal_error_signal () | |
| 572 (gdb) quit | |
| 573 | |
| 574 This is confusing because there is no such file in the XEmacs | |
| 575 distribution. This is seen on (at least) the following configurations: | |
| 576 | |
| 577 uname -a: IRIX64 oct202 6.5 01091821 IP30 | |
| 578 XEmacs 21.4.9 "Informed Management" configured for `mips-sgi-irix6.5'. | |
| 579 XEmacs 21.5-b9 "brussels sprouts" configured for `mips-sgi-irix6.5'. | |
| 580 | |
| 452 | 581 *** On Irix 6.5, the MIPSpro compiler gets an internal compiler error |
| 582 | |
| 583 The MIPSpro Compiler (at least version 7.2.1) can't seem to handle the | |
| 584 union type properly, and fails to compile src/glyphs.c. To avoid this | |
| 2648 | 585 problem, always build --enable-union-type=no (but that's the default, so |
| 452 | 586 you should only see this problem if you're an XEmacs maintainer). |
| 587 | |
| 373 | 588 *** Linking with -rpath on IRIX. |
| 124 | 589 |
| 590 Darrell Kindred <dkindred@cmu.edu> writes: | |
| 591 There are a couple of problems [with use of -rpath with Irix ld], though: | |
| 592 | |
| 593 1. The ld in IRIX 5.3 ignores all but the last -rpath | |
| 594 spec, so the patched configure spits out a warning | |
| 2648 | 595 if --x-libraries or --with-site-runtime-libraries are |
| 454 | 596 specified under irix 5.x, and it only adds -rpath |
| 2648 | 597 entries for the --with-site-runtime-libraries. This bug was |
| 124 | 598 fixed sometime between 5.3 and 6.2. |
| 599 | |
| 600 2. IRIX gcc 2.7.2 doesn't accept -rpath directly, so | |
| 601 it would have to be prefixed by -Xlinker or "-Wl,". | |
| 602 This would be fine, except that configure compiles with | |
| 603 ${CC-cc} $CFLAGS $LDFLAGS ... | |
| 604 rather than quoting $LDFLAGS with prefix-args, like | |
| 605 src/Makefile does. So if you specify --x-libraries | |
| 2648 | 606 or --with-site-runtime-libraries, you must use |
| 607 --with--gcc=no, or configure will fail. | |
| 124 | 608 |
| 373 | 609 *** On Irix 6.3, the SGI ld quits with segmentation fault when linking temacs |
| 207 | 610 |
| 611 This occurs if you use the SGI linker version 7.1. Installing the | |
| 612 patch SG0001872 fixes this problem. | |
| 197 | 613 |
| 373 | 614 *** On Irix 6.0, make tries (and fails) to build a program named unexelfsgi |
| 615 | |
| 616 A compiler bug inserts spaces into the string "unexelfsgi . o" | |
| 617 in src/Makefile. Edit src/Makefile, after configure is run, | |
| 618 find that string, and take out the spaces. | |
| 619 | |
| 620 Compiler fixes in Irix 6.0.1 should eliminate this problem. | |
| 124 | 621 |
| 373 | 622 *** On Irix 5.2, unexelfsgi.c can't find cmplrs/stsupport.h. |
| 124 | 623 |
| 373 | 624 The file cmplrs/stsupport.h was included in the wrong file set in the |
| 625 Irix 5.2 distribution. You can find it in the optional fileset | |
| 626 compiler_dev, or copy it from some other Irix 5.2 system. A kludgy | |
| 627 workaround is to change unexelfsgi.c to include sym.h instead of | |
| 628 syms.h. | |
| 124 | 629 |
| 373 | 630 *** Coredumping in Irix 6.2 |
| 124 | 631 |
| 373 | 632 Pete Forman <gsez020@compo.bedford.waii.com> writes: |
| 633 A problem noted by myself and others (I've lost the references) was | |
| 634 that XEmacs coredumped when the cut or copy toolbar buttons were | |
| 635 pressed. This has been fixed by loading the SGI patchset (Feb 98) | |
| 636 without having to recompile XEmacs. | |
| 124 | 637 |
| 373 | 638 My versions are XEmacs 20.3 (problem first noted in 19.15) and IRIX |
| 639 6.2, compiled using -n32. I'd guess that the relevant individual | |
| 640 patch was "SG0002580: multiple fixes for X libraries". SGI recommends | |
| 641 that the complete patch set be installed rather than parts of it. | |
| 124 | 642 |
| 373 | 643 ** Digital UNIX/OSF/VMS |
| 644 *** On Digital UNIX, the DEC C compiler might have a problem compiling | |
| 197 | 645 some files. |
| 124 | 646 |
| 647 In particular, src/extents.c and src/faces.c might cause the DEC C | |
| 648 compiler to abort. When this happens: cd src, compile the files by | |
| 649 hand, cd .., and redo the "make" command. When recompiling the files by | |
| 650 hand, use the old C compiler for the following versions of Digital UNIX: | |
| 651 - V3.n: Remove "-migrate" from the compile command. | |
| 652 - V4.n: Add "-oldc" to the compile command. | |
| 653 | |
| 197 | 654 A related compiler bug has been fixed by the DEC compiler team. The |
| 655 new versions of the compiler should run fine. | |
| 126 | 656 |
| 373 | 657 *** Under some versions of OSF XEmacs runs fine if built without |
| 658 optimization but will crash randomly if built with optimization. | |
| 659 | |
| 660 Using 'cc -g' is not sufficient to eliminate all optimization. Try | |
| 661 'cc -g -O0' instead. | |
| 662 | |
| 663 *** Compilation errors on VMS. | |
| 664 | |
| 665 Sorry, XEmacs does not work under VMS. You might consider working on | |
| 666 the port if you really want to have XEmacs work under VMS. | |
| 667 | |
| 668 ** HP-UX | |
| 669 *** On HPUX, the HP C compiler might have a problem compiling some files | |
| 278 | 670 with optimization. |
| 124 | 671 |
| 672 Richard Cognot <cognot@ensg.u-nancy.fr> writes: | |
| 673 | |
| 674 Had to drop once again to level 2 optimization, at least to | |
| 675 compile lstream.c. Otherwise, I get a "variable is void: \if" | |
| 676 problem while dumping (this is a problem I already reported | |
| 677 with vanilla hpux 10.01 and 9.07, which went away after | |
| 678 applying patches for the C compiler). Trouble is I still | |
| 679 haven't found the same patch for hpux 10.10, and I don't | |
| 680 remember the patch numbers. I think potential XEmacs builders | |
| 681 on HP should be warned about this. | |
| 682 | |
| 373 | 683 *** I don't have `xmkmf' and `imake' on my HP. |
| 124 | 684 |
| 304 | 685 You can get these standard X tools by anonymous FTP to |
| 686 hpcvaaz.cv.hp.com. Essentially all X programs need these. | |
| 124 | 687 |
| 373 | 688 *** On HP-UX, problems with make |
| 278 | 689 |
| 442 | 690 Marcus Thiessel <marcus@xemacs.org> |
| 278 | 691 |
| 304 | 692 Some releases of XEmacs (e.g. 20.4) require GNU make to build |
| 693 successfully. You don't need GNU make when building 21.x. | |
| 278 | 694 |
| 373 | 695 *** On HP-UX 9.05 XEmacs won't compile or coredump during the build. |
| 278 | 696 |
| 442 | 697 Marcus Thiessel <marcus@xemacs.org> |
| 278 | 698 |
| 699 This might be a sed problem. For your own safety make sure to use | |
| 700 GNU sed while dumping XEmacs. | |
| 701 | |
| 442 | 702 |
| 373 | 703 ** SCO OpenServer |
| 704 *** Native cc on SCO OpenServer 5 is now OK. Icc may still throw you | |
| 197 | 705 a curve. Here is what Robert Lipe <robertl@arnet.com> says: |
| 124 | 706 |
| 454 | 707 Unlike XEmacs 19.13, building with the native cc on SCO OpenServer 5 |
| 124 | 708 now produces a functional binary. I will typically build this |
| 709 configuration for COFF with: | |
| 710 | |
| 197 | 711 /path_to_xemacs_source/configure --with-gcc=no \ |
| 2648 | 712 --with-site-includes=/usr/local/include \ |
| 713 --with-site-libraries=/usr/local/lib \ | |
| 714 --with-xpm --with-xface --enable-sound=nas | |
| 124 | 715 |
| 454 | 716 This version now supports ELF builds. I highly recommend this to |
| 717 reduce the in-core footprint of XEmacs. This is now how I compile | |
| 124 | 718 all my test releases. Build it like this: |
| 719 | |
| 720 /path_to_XEmacs_source/configure --with-gcc=no \ | |
| 2648 | 721 --with-site-includes=/usr/local/include |
| 722 --with-site-libraries=/usr/local/lib \ | |
| 723 --with-xpm --with-xface --enable-sound=nas --with-dynamic | |
| 124 | 724 |
| 454 | 725 The compiler known as icc [ supplied with the OpenServer 5 Development |
| 124 | 726 System ] generates a working binary, but it takes forever to generate |
| 727 XEmacs. ICC also whines more about the code than /bin/cc does. I do | |
| 728 believe all its whining is legitimate, however. Note that you do | |
| 729 have to 'cd src ; make LD=icc' to avoid linker errors. | |
| 730 | |
| 731 The way I handle the build procedure is: | |
| 732 | |
| 733 /path_to_XEmacs_source/configure --with-gcc=no \ | |
| 2648 | 734 --with-site-includes=/usr/local/include \ |
| 735 --with-site-libraries=/usr/local/lib \ | |
| 736 --with-xpm --with-xface --enable-sound=nas --with-dynamic \ | |
| 737 --with-compiler="icc" | |
| 124 | 738 |
| 454 | 739 NOTE I have the xpm, xface, and audio libraries and includes in |
| 124 | 740 /usr/local/lib, /usr/local/include. If you don't have these, |
| 741 don't include the "--with-*" arguments in any of my examples. | |
| 742 | |
| 454 | 743 In previous versions of XEmacs, you had to override the defaults while |
| 124 | 744 compiling font-lock.o and extents.o when building with icc. This seems |
| 745 to no longer be true, but I'm including this old information in case it | |
| 746 resurfaces. The process I used was: | |
| 747 | |
| 454 | 748 make -k |
| 749 [ procure pizza, beer, repeat ] | |
| 124 | 750 cd src |
| 751 make CC="icc -W0,-mP1COPT_max_tree_size=3000" font-lock.o extents.o | |
| 752 make LD=icc | |
| 753 | |
| 454 | 754 If you want sound support, get the tls566 supplement from |
| 755 ftp.sco.com:/TLS or any of its mirrors. It works just groovy | |
| 124 | 756 with XEmacs. |
| 757 | |
| 758 The M-x manual-entry is known not to work. If you know Lisp and would | |
| 759 like help in making it work, e-mail me at <robertl@dgii.com>. | |
| 760 (UNCHECKED for 19.15 -- it might work). | |
| 761 | |
| 454 | 762 In earlier releases, gnuserv/gnuclient/gnudoit would open a frame |
| 124 | 763 just fine, but the client would lock up and the server would |
| 454 | 764 terminate when you used C-x # to close the frame. This is now |
| 124 | 765 fixed in XEmacs. |
| 766 | |
| 767 In etc/ there are two files of note. emacskeys.sco and emacsstrs.sco. | |
| 768 The comments at the top of emacskeys.sco describe its function, and | |
| 769 the emacstrs.sco is a suitable candidate for /usr/lib/keyboard/strings | |
| 770 to take advantage of the keyboard map in emacskeys.sco. | |
| 771 | |
| 373 | 772 Note: Much of the above entry is probably not valid for XEmacs 21.0 |
| 207 | 773 and later. |
| 197 | 774 |
| 1332 | 775 ** Windows |
| 776 | |
| 1441 | 777 *** XEmacs complains "No such file or directory, diff" |
| 778 | |
| 779 or "ispell" or other commands that seem related to whatever you just | |
| 780 tried to do. | |
| 781 | |
| 782 There are a large number of common (in the sense that "everyone has | |
| 783 these, really") Unix utilities that are not provided with XEmacs. The | |
| 784 GNU Project's implementations are available for Windows in the the | |
| 785 Cygwin distribution (http://www.cygwin.com/), which also provides a | |
| 786 complete Unix emulation environment (and thus makes ports of Unix | |
| 787 utilities nearly trivial). Another implementation is that from MinGW | |
| 788 (http://www.mingw.org/msys.shtml). | |
| 789 | |
| 1332 | 790 *** Weird crashes in pdump load or shortly after pdump load. |
| 791 | |
| 792 This can happen with incremental linking. Check if you have set | |
| 793 SUPPORT_EDIT_AND_CONTINUE to non-zero in config.inc, which must allow | |
| 794 incremental linking to be enabled (otherwise it's disabled). Either turn | |
| 795 this off, execute `nmake -f xemacs.mak clean', or manually remove | |
| 796 `temacs.exe' and `xemacs.exe'. | |
| 797 | |
| 392 | 798 ** Cygwin |
| 524 | 799 |
| 1318 | 800 See also Intel Architecture General, above. |
| 801 | |
| 802 *** Signal 11 when building or running a dumped XEmacs. | |
| 803 | |
| 804 This appears to happen when using the traditional dumping mechanism and | |
| 805 the system malloc. Andy Piper writes: | |
| 806 | |
| 1332 | 807 Traditional dumping on Cygwin relies on using gmalloc (there are specific |
| 1318 | 808 hacks in our version of gmalloc to support this), I suspect using sysmalloc |
| 809 is the problem. | |
| 810 | |
| 811 Try configuring with pdump or without system malloc. | |
| 812 | |
| 524 | 813 *** Syntax errors running configure scripts, make failing with exit code 127 |
| 814 in inexplicable situations, etc. | |
| 392 | 815 |
| 1332 | 816 [[ This may be because you are using the default Cygwin shell, under old |
| 817 versions of Cygwin. The default Cygwin shell (/bin/sh.exe) is ash, which | |
| 818 appears to work in most circumstances but has some weird failure modes. | |
| 819 You may need to replace the symlink with bash.exe. ]] This doesn't appear | |
| 820 to affect Cygwin any longer, and /bin/sh.exe is no longer a symlink in | |
| 821 any case. | |
| 392 | 822 |
| 524 | 823 *** Lots of compile errors, esp. on lines containing macro definitions |
| 824 terminated by backslashes. | |
| 392 | 825 |
| 524 | 826 Your partition holding the source files is mounted binary. It needs |
| 827 to be mounted text. (This will not screw up any binary files because | |
| 828 the Cygwin utilities specify explicitly whether they want binary or | |
| 829 text mode when working with source vs. binary files, which overrides | |
| 830 the mount type.) To fix this, you just need to run the appropriate | |
| 831 mount command once -- afterwards, the settings are remembered in the | |
| 832 registry. | |
| 392 | 833 |
| 524 | 834 *** Errors from make like /c:not found. |
| 392 | 835 |
| 524 | 836 Make sure you set the environment variable MAKE_MODE to UNIX in your |
| 837 .bashrc, Control Panel (Windows 2000/NT), or AUTOEXEC.BAT (Windows | |
| 838 98/95). | |
| 392 | 839 |
| 840 *** The info files will not build. | |
| 841 | |
| 1332 | 842 makeinfo that ships with old versions of Cygwin doesn't work. |
| 843 Upgrade to the latest Cygwin version. | |
| 392 | 844 |
| 524 | 845 *** XEmacs hangs while attempting to rebuild the .elc files. |
| 392 | 846 |
| 524 | 847 Check to make sure you're not configuring with rel-alloc. The relocating |
| 848 allocator does not currently work under Cygwin due to bugs in Cygwin's | |
| 849 mmap(). | |
| 392 | 850 |
| 524 | 851 *** Trying to build with X, but X11 not detected. |
| 852 | |
| 853 This is usually because xmkmf is not in your path or because you are | |
| 1332 | 854 using the default Cygwin shell. (See above.) |
| 333 | 855 |
| 856 | |
| 373 | 857 * Problems with running XEmacs |
| 858 ============================== | |
| 859 ** General | |
| 1332 | 860 |
| 861 *** Changes made to .el files do not take effect. | |
| 862 | |
| 863 You may have forgotten to recompile them into .elc files. Then the | |
| 864 old .elc files will be loaded, and your changes will not be seen. To | |
| 865 fix this, do `M-x byte-recompile-directory' and specify the directory | |
| 866 that contains the Lisp files. | |
| 867 | |
| 868 Note that you will get a warning when loading a .elc file that is | |
| 869 older than the corresponding .el file. | |
| 870 | |
| 871 *** VM appears to hang in large folders. | |
| 872 | |
| 873 This is normal (trust us) when upgrading to VM-6.22 from earlier | |
| 874 versions. Let VM finish what it is doing and all will be well. | |
| 1042 | 875 |
| 892 | 876 *** Starting with 21.4.x, killing text is absurdly slow. |
| 877 | |
| 878 See FAQ Q3.10.6. Should be available on the web near | |
| 879 http://www.xemacs.org/faq/xemacs-faq.html#SEC160. | |
| 880 | |
| 835 | 881 *** Whenever I try to retrieve a remote file, I have problems. |
| 882 | |
| 883 A typical error: FTP Error: USER request failed; 500 AUTH not understood. | |
| 884 Thanks to giacomo boffi <giacomo.boffi@polimi.it> on comp.emacs.xemacs: | |
| 885 | |
| 886 tell your ftp client to not attempt AUTH authentication (or do not | |
| 887 use FTP servers that don't understand AUTH) | |
| 888 | |
| 889 and notes that you need to add an element (often "-u") to | |
| 890 `efs-ftp-program-args'. Use M-x customize-variable, and verify the | |
| 891 needed flag with `man ftp' or other local documentation. | |
| 892 | |
| 464 | 893 *** gnuserv is running, some clients can connect, but others cannot. |
| 894 | |
| 895 The code in gnuslib.c respects the value of TMPDIR. If the server and | |
| 896 the client have different values in their environment, you lose. | |
| 897 One program known to set TMPDIR and manifest this problem is exmh. | |
| 898 You can defeat the use of TMPDIR by unsetting USE_TMPDIR at the top of | |
| 899 gnuserv.h at build time. | |
| 900 | |
| 1332 | 901 ** General Unix |
| 124 | 902 |
| 373 | 903 *** You type Control-H (Backspace) expecting to delete characters. |
| 124 | 904 |
| 905 Emacs has traditionally used Control-H for help; unfortunately this | |
| 424 | 906 interferes with its use as Backspace on TTY's. As of XEmacs 21, |
| 907 XEmacs looks at the "erase" setting of TTY structures and maps C-h to | |
| 908 backspace when erase is set to C-h. This is sort of a special hack, | |
| 909 but it makes it possible for you to use the standard: | |
| 910 | |
| 911 stty erase ^H | |
| 355 | 912 |
| 424 | 913 to get your backspace key to erase characters. The erase setting is |
| 914 recorded in the Lisp variable `tty-erase-char', which you can use to | |
| 915 tune the settings in your .emacs. | |
| 124 | 916 |
| 424 | 917 A major drawback of this is that when C-h becomes backspace, it no |
| 918 longer invokes help. In that case, you need to use f1 for help, or | |
| 919 bind another key. An example of the latter is the following code, | |
| 920 which moves help to Meta-? (ESC ?): | |
| 124 | 921 |
| 424 | 922 (global-set-key "\M-?" 'help-command) |
| 124 | 923 |
| 1332 | 924 *** At startup I get a warning on stderr about missing charsets: |
| 925 | |
| 926 Warning: Missing charsets in String to FontSet conversion | |
| 927 | |
| 928 You need to specify appropriate charsets for your locale (usually the | |
| 929 value of the LANG environment variable) in .Xresources. See | |
| 930 etc/Emacs.ad for the relevant resources (mostly menubar fonts and | |
| 931 fontsets). Do not edit this file, it's purely informative. | |
| 932 | |
| 933 If you have no satisfactory fonts for iso-8859-1, XEmacs will crash. | |
| 934 | |
| 935 It looks like XFree86 4.x (the usual server on Linux and *BSD) has | |
| 936 some braindamage where .UTF-8 locales will always generate this | |
| 937 message, because the XFree86 (font)server doesn't know that UTF-8 will | |
| 938 use the ISO10646-1 font registry (or a Cmap or something). | |
| 939 | |
| 940 If you are not using a .UTF-8 locale and see this warning for a | |
| 941 character set not listed in the default in Emacs.ad, please let | |
| 942 xemacs-beta@xemacs.org know about it, so we can add fonts to the | |
| 943 appropriate fontsets and stifle this warning. (Unfortunately it's | |
| 944 buried in Xlib, so we can't easily get rid of it otherwise.) | |
| 945 | |
| 373 | 946 *** Mail agents (VM, Gnus, rmail) cannot get new mail |
| 197 | 947 |
| 948 rmail and VM get new mail from /usr/spool/mail/$USER using a program | |
| 949 called `movemail'. This program interlocks with /bin/mail using the | |
| 950 protocol defined by /bin/mail. | |
| 951 | |
| 952 There are two different protocols in general use. One of them uses | |
| 953 the `flock' system call. The other involves creating a lock file; | |
| 954 `movemail' must be able to write in /usr/spool/mail in order to do | |
| 955 this. You control which one is used by defining, or not defining, the | |
| 956 macro MAIL_USE_FLOCK in config.h or the m- or s- file it includes. IF | |
| 957 YOU DON'T USE THE FORM OF INTERLOCKING THAT IS NORMAL ON YOUR SYSTEM, | |
| 958 YOU CAN LOSE MAIL! | |
| 959 | |
| 960 If your system uses the lock file protocol, and fascist restrictions | |
| 961 prevent ordinary users from writing the lock files in /usr/spool/mail, | |
| 962 you may need to make `movemail' setgid to a suitable group such as | |
| 963 `mail'. To do this, use the following commands (as root) after doing | |
| 964 the make install. | |
| 965 | |
| 966 chgrp mail movemail | |
| 967 chmod 2755 movemail | |
| 968 | |
| 969 Installation normally copies movemail from the build directory to an | |
| 970 installation directory which is usually under /usr/local/lib. The | |
| 971 installed copy of movemail is usually in the directory | |
| 972 /usr/local/lib/emacs/VERSION/TARGET. You must change the group and | |
| 973 mode of the installed copy; changing the group and mode of the build | |
| 974 directory copy is ineffective. | |
| 975 | |
| 373 | 976 *** Things which should be bold or italic (such as the initial |
| 197 | 977 copyright notice) are not. |
| 0 | 978 |
| 197 | 979 The fonts of the "bold" and "italic" faces are generated from the font |
| 980 of the "default" face; in this way, your bold and italic fonts will | |
| 981 have the appropriate size and family. However, emacs can only be | |
| 982 clever in this way if you have specified the default font using the | |
| 983 XLFD (X Logical Font Description) format, which looks like | |
| 0 | 984 |
| 985 *-courier-medium-r-*-*-*-120-*-*-*-*-*-* | |
| 986 | |
| 197 | 987 if you use any of the other, less strict font name formats, some of |
| 988 which look like: | |
| 989 | |
| 0 | 990 lucidasanstypewriter-12 |
| 991 and fixed | |
| 992 and 9x13 | |
| 993 | |
| 994 then emacs won't be able to guess the names of the "bold" and "italic" | |
| 995 versions. All X fonts can be referred to via XLFD-style names, so you | |
| 996 should use those forms. See the man pages for X(1), xlsfonts(1), and | |
| 997 xfontsel(1). | |
| 998 | |
| 373 | 999 *** The dumped Emacs crashes when run, trying to write pure data. |
| 0 | 1000 |
| 1001 Two causes have been seen for such problems. | |
| 1002 | |
| 1003 1) On a system where getpagesize is not a system call, it is defined | |
| 1004 as a macro. If the definition (in both unexec.c and malloc.c) is wrong, | |
| 1005 it can cause problems like this. You might be able to find the correct | |
| 1006 value in the man page for a.out (5). | |
| 1007 | |
| 1008 2) Some systems allocate variables declared static among the | |
| 1009 initialized variables. Emacs makes all initialized variables in most | |
| 1010 of its files pure after dumping, but the variables declared static and | |
| 1011 not initialized are not supposed to be pure. On these systems you | |
| 1012 may need to add "#define static" to the m- or the s- file. | |
| 1013 | |
| 373 | 1014 *** Reading and writing files is very very slow. |
| 0 | 1015 |
| 1016 Try evaluating the form (setq lock-directory nil) and see if that helps. | |
| 1017 There is a problem with file-locking on some systems (possibly related | |
| 454 | 1018 to NFS) that I don't understand. Please send mail to the address |
| 1332 | 1019 xemacs-beta@xemacs.org if you figure this one out. |
| 0 | 1020 |
| 373 | 1021 *** When emacs starts up, I get lots of warnings about unknown keysyms. |
| 124 | 1022 |
| 1023 If you are running the prebuilt binaries, the Motif library expects to find | |
| 1024 certain thing in the XKeysymDB file. This file is normally in /usr/lib/X11/ | |
| 1025 or in /usr/openwin/lib/. If you keep yours in a different place, set the | |
| 454 | 1026 environment variable $XKEYSYMDB to point to it before starting emacs. If |
| 1027 you still have the problem after doing that, perhaps your version of X is | |
| 2536 | 1028 too old. There is a copy of the MIT X11R6 XKeysymDB file in the emacs `etc' |
| 124 | 1029 directory. Try using that one. |
| 1030 | |
| 3406 | 1031 *** Lots of warnings generated when displaying via ssh X forwarding. |
| 1032 | |
| 1033 If you are seeing a significant number of X11 warnings (in particular | |
| 1034 BadWindow errors) when using XEmacs via ssh X forwarding try using a | |
| 1035 trusted x11 connection instead (for openssh, use -Y instead of -X). | |
| 1036 | |
| 373 | 1037 *** My X resources used to work, and now some of them are being ignored. |
| 0 | 1038 |
| 124 | 1039 Check the resources in .../etc/Emacs.ad (which is the same as the file |
| 1389 | 1040 sample.Xresources). Perhaps some of the default resources built in to |
| 124 | 1041 emacs are now overriding your existing resources. Copy and edit the |
| 1042 resources in Emacs.ad as necessary. | |
| 1043 | |
| 373 | 1044 *** I have focus problems when I use `M-o' to switch to another screen |
| 197 | 1045 without using the mouse. |
| 124 | 1046 |
| 197 | 1047 The focus issues with a program like XEmacs, which has multiple |
| 1048 homogeneous top-level windows, are very complicated, and as a result, | |
| 1049 most window managers don't implement them correctly. | |
| 0 | 1050 |
| 124 | 1051 The R4/R5 version of twm (and all of its descendants) had buggy focus |
| 197 | 1052 handling. Sufficiently recent versions of tvtwm have been fixed. In |
| 1053 addition, if you're using twm, make sure you have not specified | |
| 1054 "NoTitleFocus" in your .tvtwmrc file. The very nature of this option | |
| 1055 makes twm do some illegal focus tricks, even with the patch. | |
| 0 | 1056 |
| 197 | 1057 It is known that olwm and olvwm are buggy, and in different ways. If |
| 1058 you're using click-to-type mode, try using point-to-type, or vice | |
| 1059 versa. | |
| 0 | 1060 |
| 197 | 1061 In older versions of NCDwm, one could not even type at XEmacs windows. |
| 1062 This has been fixed in newer versions (2.4.3, and possibly earlier). | |
| 0 | 1063 |
| 197 | 1064 (Many people suggest that XEmacs should warp the mouse when focusing |
| 1065 on another screen in point-to-type mode. This is not ICCCM-compliant | |
| 1066 behavior. Implementing such policy is the responsibility of the | |
| 1067 window manager itself, it is not legal for a client to do this.) | |
| 0 | 1068 |
| 373 | 1069 *** Emacs spontaneously displays "I-search: " at the bottom of the screen. |
| 0 | 1070 |
| 1071 This means that Control-S/Control-Q (XON/XOFF) "flow control" is being | |
| 1072 used. C-s/C-q flow control is bad for Emacs editors because it takes | |
| 1073 away C-s and C-q as user commands. Since editors do not output long | |
| 1074 streams of text without user commands, there is no need for a | |
| 1075 user-issuable "stop output" command in an editor; therefore, a | |
| 1076 properly designed flow control mechanism would transmit all possible | |
| 1077 input characters without interference. Designing such a mechanism is | |
| 1078 easy, for a person with at least half a brain. | |
| 1079 | |
| 1080 There are three possible reasons why flow control could be taking place: | |
| 1081 | |
| 1082 1) Terminal has not been told to disable flow control | |
| 1083 2) Insufficient padding for the terminal in use | |
| 1084 3) Some sort of terminal concentrator or line switch is responsible | |
| 1085 | |
| 1086 First of all, many terminals have a set-up mode which controls whether | |
| 1087 they generate XON/XOFF flow control characters. This must be set to | |
| 1088 "no XON/XOFF" in order for Emacs to work. Sometimes there is an | |
| 1089 escape sequence that the computer can send to turn flow control off | |
| 1090 and on. If so, perhaps the termcap `ti' string should turn flow | |
| 1091 control off, and the `te' string should turn it on. | |
| 1092 | |
| 1093 Once the terminal has been told "no flow control", you may find it | |
| 1094 needs more padding. The amount of padding Emacs sends is controlled | |
| 1095 by the termcap entry for the terminal in use, and by the output baud | |
| 1096 rate as known by the kernel. The shell command `stty' will print | |
| 1097 your output baud rate; `stty' with suitable arguments will set it if | |
| 1098 it is wrong. Setting to a higher speed causes increased padding. If | |
| 1099 the results are wrong for the correct speed, there is probably a | |
| 1100 problem in the termcap entry. You must speak to a local Unix wizard | |
| 1101 to fix this. Perhaps you are just using the wrong terminal type. | |
| 1102 | |
| 1103 For terminals that lack a "no flow control" mode, sometimes just | |
| 1104 giving lots of padding will prevent actual generation of flow control | |
| 1105 codes. You might as well try it. | |
| 1106 | |
| 1107 If you are really unlucky, your terminal is connected to the computer | |
| 1108 through a concentrator which sends XON/XOFF flow control to the | |
| 1109 computer, or it insists on sending flow control itself no matter how | |
| 1110 much padding you give it. Unless you can figure out how to turn flow | |
| 1111 control off on this concentrator (again, refer to your local wizard), | |
| 1112 you are screwed! You should have the terminal or concentrator | |
| 1113 replaced with a properly designed one. In the mean time, some drastic | |
| 1114 measures can make Emacs semi-work. | |
| 1115 | |
| 1116 You can make Emacs ignore C-s and C-q and let the operating system | |
| 1117 handle them. To do this on a per-session basis, just type M-x | |
| 1118 enable-flow-control RET. You will see a message that C-\ and C-^ are | |
| 1119 now translated to C-s and C-q. (Use the same command M-x | |
| 1120 enable-flow-control to turn *off* this special mode. It toggles flow | |
| 1121 control handling.) | |
| 1122 | |
| 1123 If C-\ and C-^ are inconvenient for you (for example, if one of them | |
| 1124 is the escape character of your terminal concentrator), you can choose | |
| 1125 other characters by setting the variables flow-control-c-s-replacement | |
| 1126 and flow-control-c-q-replacement. But choose carefully, since all | |
| 1127 other control characters are already used by emacs. | |
| 1128 | |
| 1129 IMPORTANT: if you type C-s by accident while flow control is enabled, | |
| 1130 Emacs output will freeze, and you will have to remember to type C-q in | |
| 1131 order to continue. | |
| 1132 | |
| 1133 If you work in an environment where a majority of terminals of a | |
| 1134 certain type are flow control hobbled, you can use the function | |
| 1135 `enable-flow-control-on' to turn on this flow control avoidance scheme | |
| 1136 automatically. Here is an example: | |
| 1137 | |
| 1138 (enable-flow-control-on "vt200" "vt300" "vt101" "vt131") | |
| 1139 | |
| 1140 If this isn't quite correct (e.g. you have a mixture of flow-control hobbled | |
| 1141 and good vt200 terminals), you can still run enable-flow-control | |
| 1142 manually. | |
| 1143 | |
| 1144 I have no intention of ever redesigning the Emacs command set for the | |
| 1145 assumption that terminals use C-s/C-q flow control. XON/XOFF flow | |
| 1146 control technique is a bad design, and terminals that need it are bad | |
| 1147 merchandise and should not be purchased. Now that X is becoming | |
| 1148 widespread, XON/XOFF seems to be on the way out. If you can get some | |
| 1149 use out of GNU Emacs on inferior terminals, more power to you, but I | |
| 1150 will not make Emacs worse for properly designed systems for the sake | |
| 1151 of inferior systems. | |
| 1152 | |
| 373 | 1153 *** Control-S and Control-Q commands are ignored completely. |
| 0 | 1154 |
| 1155 For some reason, your system is using brain-damaged C-s/C-q flow | |
| 1156 control despite Emacs's attempts to turn it off. Perhaps your | |
| 1157 terminal is connected to the computer through a concentrator | |
| 1158 that wants to use flow control. | |
| 1159 | |
| 1160 You should first try to tell the concentrator not to use flow control. | |
| 1161 If you succeed in this, try making the terminal work without | |
| 1162 flow control, as described in the preceding section. | |
| 1163 | |
| 1164 If that line of approach is not successful, map some other characters | |
| 1165 into C-s and C-q using keyboard-translate-table. The example above | |
| 1166 shows how to do this with C-^ and C-\. | |
| 1167 | |
| 373 | 1168 *** Control-S and Control-Q commands are ignored completely on a net |
| 197 | 1169 connection. |
| 0 | 1170 |
| 1171 Some versions of rlogin (and possibly telnet) do not pass flow | |
| 1172 control characters to the remote system to which they connect. | |
| 1173 On such systems, emacs on the remote system cannot disable flow | |
| 1174 control on the local system. | |
| 1175 | |
| 1176 One way to cure this is to disable flow control on the local host | |
| 1177 (the one running rlogin, not the one running rlogind) using the | |
| 1178 stty command, before starting the rlogin process. On many systems, | |
| 120 | 1179 `stty start u stop u' will do this. |
| 0 | 1180 |
| 1181 Some versions of tcsh will prevent even this from working. One way | |
| 1182 around this is to start another shell before starting rlogin, and | |
| 1183 issue the stty command to disable flow control from that shell. | |
| 1184 | |
| 1185 If none of these methods work, the best solution is to type | |
| 120 | 1186 `M-x enable-flow-control' at the beginning of your emacs session, or |
| 0 | 1187 if you expect the problem to continue, add a line such as the |
| 1188 following to your .emacs (on the host running rlogind): | |
| 1189 | |
| 1190 (enable-flow-control-on "vt200" "vt300" "vt101" "vt131") | |
| 1191 | |
| 1192 See the entry about spontaneous display of I-search (above) for more | |
| 1193 info. | |
| 1194 | |
| 373 | 1195 *** TTY redisplay is slow. |
| 197 | 1196 |
| 1197 XEmacs has fairly new TTY redisplay support (beginning from 19.12), | |
| 1198 which doesn't include some basic TTY optimizations -- like using | |
| 1199 scrolling regions to move around blocks of text. This is why | |
| 454 | 1200 redisplay on the traditional terminals, or over slow lines can be very |
| 197 | 1201 slow. |
| 1202 | |
| 1203 If you are interested in fixing this, please let us know at | |
| 1332 | 1204 <xemacs-beta@xemacs.org>. |
| 197 | 1205 |
| 373 | 1206 *** Screen is updated wrong, but only on one kind of terminal. |
| 0 | 1207 |
| 120 | 1208 This could mean that the termcap entry you are using for that terminal |
| 1209 is wrong, or it could mean that Emacs has a bug handing the | |
| 1210 combination of features specified for that terminal. | |
| 0 | 1211 |
| 1212 The first step in tracking this down is to record what characters | |
| 1213 Emacs is sending to the terminal. Execute the Lisp expression | |
| 120 | 1214 (open-termscript "./emacs-script") to make Emacs write all terminal |
| 1215 output into the file ~/emacs-script as well; then do what makes the | |
| 1216 screen update wrong, and look at the file and decode the characters | |
| 1217 using the manual for the terminal. There are several possibilities: | |
| 0 | 1218 |
| 1219 1) The characters sent are correct, according to the terminal manual. | |
| 1220 | |
| 1221 In this case, there is no obvious bug in Emacs, and most likely you | |
| 1222 need more padding, or possibly the terminal manual is wrong. | |
| 1223 | |
| 120 | 1224 2) The characters sent are incorrect, due to an obscure aspect of the |
| 1225 terminal behavior not described in an obvious way by termcap. | |
| 0 | 1226 |
| 120 | 1227 This case is hard. It will be necessary to think of a way for Emacs |
| 1228 to distinguish between terminals with this kind of behavior and other | |
| 1229 terminals that behave subtly differently but are classified the same | |
| 1230 by termcap; or else find an algorithm for Emacs to use that avoids the | |
| 1231 difference. Such changes must be tested on many kinds of terminals. | |
| 0 | 1232 |
| 1233 3) The termcap entry is wrong. | |
| 1234 | |
| 120 | 1235 See the file etc/TERMS for information on changes that are known to be |
| 1236 needed in commonly used termcap entries for certain terminals. | |
| 0 | 1237 |
| 120 | 1238 4) The characters sent are incorrect, and clearly cannot be right for |
| 1239 any terminal with the termcap entry you were using. | |
| 0 | 1240 |
| 120 | 1241 This is unambiguously an Emacs bug, and can probably be fixed in |
| 197 | 1242 termcap.c, terminfo.c, tparam.c, cm.c, redisplay-tty.c, |
| 1243 redisplay-output.c, or redisplay.c. | |
| 0 | 1244 |
| 373 | 1245 *** My buffers are full of \000 characters or otherwise corrupt. |
| 1246 | |
| 1247 Some compilers have trouble with gmalloc.c and ralloc.c; try recompiling | |
| 1248 without optimization. If that doesn't work, try recompiling with | |
| 1249 SYSTEM_MALLOC defined, and/or with REL_ALLOC undefined. | |
| 1250 | |
| 1389 | 1251 *** A position you specified in .Xresources is ignored, using twm. |
| 373 | 1252 |
| 1253 twm normally ignores "program-specified" positions. | |
| 1254 You can tell it to obey them with this command in your `.twmrc' file: | |
| 1255 | |
| 1256 UsePPosition "on" #allow clents to request a position | |
| 1257 | |
| 1258 *** With M-x enable-flow-control, you need to type C-\ twice to do | |
| 1259 incremental search--a single C-\ gets no response. | |
| 1260 | |
| 1261 This has been traced to communicating with your machine via kermit, | |
| 1262 with C-\ as the kermit escape character. One solution is to use | |
| 1263 another escape character in kermit. One user did | |
| 1264 | |
| 1265 set escape-character 17 | |
| 1266 | |
| 1267 in his .kermrc file, to make C-q the kermit escape character. | |
| 1268 | |
| 1269 *** The Motif version of Emacs paints the screen a solid color. | |
| 1270 | |
| 1271 This has been observed to result from the following X resource: | |
| 1272 | |
| 1273 Emacs*default.attributeFont: -*-courier-medium-r-*-*-*-140-*-*-*-*-iso8859-* | |
| 1274 | |
| 1275 That the resource has this effect indicates a bug in something, but we | |
| 1276 do not yet know what. If it is an Emacs bug, we hope someone can | |
| 1277 explain what the bug is so we can fix it. In the mean time, removing | |
| 1278 the resource prevents the problem. | |
| 1279 | |
| 1280 *** After running emacs once, subsequent invocations crash. | |
| 1281 | |
| 1282 Some versions of SVR4 have a serious bug in the implementation of the | |
| 1283 mmap () system call in the kernel; this causes emacs to run correctly | |
| 1284 the first time, and then crash when run a second time. | |
| 1285 | |
| 1286 Contact your vendor and ask for the mmap bug fix; in the mean time, | |
| 1287 you may be able to work around the problem by adding a line to your | |
| 1288 operating system description file (whose name is reported by the | |
| 1289 configure script) that reads: | |
| 1290 #define SYSTEM_MALLOC | |
| 1291 This makes Emacs use memory less efficiently, but seems to work around | |
| 1292 the kernel bug. | |
| 1293 | |
| 1294 *** Inability to send an Alt-modified key, when Emacs is communicating | |
| 1295 directly with an X server. | |
| 1296 | |
| 1297 If you have tried to bind an Alt-modified key as a command, and it | |
| 1298 does not work to type the command, the first thing you should check is | |
| 1299 whether the key is getting through to Emacs. To do this, type C-h c | |
| 1300 followed by the Alt-modified key. C-h c should say what kind of event | |
| 1301 it read. If it says it read an Alt-modified key, then make sure you | |
| 1302 have made the key binding correctly. | |
| 1303 | |
| 1304 If C-h c reports an event that doesn't have the Alt modifier, it may | |
| 1305 be because your X server has no key for the Alt modifier. The X | |
| 1306 server that comes from MIT does not set up the Alt modifier by | |
| 1307 default. | |
| 1308 | |
| 1309 If your keyboard has keys named Alt, you can enable them as follows: | |
| 1310 | |
| 1311 xmodmap -e 'add mod2 = Alt_L' | |
| 1312 xmodmap -e 'add mod2 = Alt_R' | |
| 1313 | |
| 1314 If the keyboard has just one key named Alt, then only one of those | |
| 1315 commands is needed. The modifier `mod2' is a reasonable choice if you | |
| 1316 are using an unmodified MIT version of X. Otherwise, choose any | |
| 1317 modifier bit not otherwise used. | |
| 1318 | |
| 1319 If your keyboard does not have keys named Alt, you can use some other | |
| 1320 keys. Use the keysym command in xmodmap to turn a function key (or | |
| 1321 some other 'spare' key) into Alt_L or into Alt_R, and then use the | |
| 1322 commands show above to make them modifier keys. | |
| 1323 | |
| 1324 Note that if you have Alt keys but no Meta keys, Emacs translates Alt | |
| 1325 into Meta. This is because of the great importance of Meta in Emacs. | |
| 1326 | |
| 1327 *** In Shell mode, you get a ^M at the end of every line. | |
| 1328 | |
| 1329 This happens to people who use tcsh, because it is trying to be too | |
| 1330 smart. It sees that the Shell uses terminal type `unknown' and turns | |
| 1331 on the flag to output ^M at the end of each line. You can fix the | |
| 1332 problem by adding this to your .cshrc file: | |
| 1333 | |
| 1334 if ($?EMACS) then | |
| 1335 if ($EMACS == "t") then | |
| 454 | 1336 unset edit |
| 373 | 1337 stty -icrnl -onlcr -echo susp ^Z |
| 1338 endif | |
| 1339 endif | |
| 1340 | |
| 1341 *** An error message such as `X protocol error: BadMatch (invalid | |
| 1342 parameter attributes) on protocol request 93'. | |
| 1343 | |
| 1344 This comes from having an invalid X resource, such as | |
| 1345 emacs*Cursor: black | |
| 1346 (which is invalid because it specifies a color name for something | |
| 1347 that isn't a color.) | |
| 1348 | |
| 1349 The fix is to correct your X resources. | |
| 1350 | |
| 1351 *** Once you pull down a menu from the menubar, it won't go away. | |
| 1352 | |
| 1353 It has been claimed that this is caused by a bug in certain very old | |
| 1354 (1990?) versions of the twm window manager. It doesn't happen with | |
| 1355 recent vintages, or with other window managers. | |
| 1356 | |
| 1357 *** Emacs ignores the "help" key when running OLWM. | |
| 1358 | |
| 1359 OLWM grabs the help key, and retransmits it to the appropriate client | |
| 1360 using XSendEvent. Allowing emacs to react to synthetic events is a | |
| 1361 security hole, so this is turned off by default. You can enable it by | |
| 1362 setting the variable x-allow-sendevents to t. You can also cause fix | |
| 1363 this by telling OLWM to not grab the help key, with the null binding | |
| 1364 "OpenWindows.KeyboardCommand.Help:". | |
| 1365 | |
| 1366 *** Programs running under terminal emulator do not recognize `emacs' | |
| 1367 terminal type. | |
| 1368 | |
| 1369 The cause of this is a shell startup file that sets the TERMCAP | |
| 1370 environment variable. The terminal emulator uses that variable to | |
| 1371 provide the information on the special terminal type that Emacs | |
| 1372 emulates. | |
| 1373 | |
| 1374 Rewrite your shell startup file so that it does not change TERMCAP | |
| 1375 in such a case. You could use the following conditional which sets | |
| 1376 it only if it is undefined. | |
| 1377 | |
| 1378 if ( ! ${?TERMCAP} ) setenv TERMCAP ~/my-termcap-file | |
| 1379 | |
| 1380 Or you could set TERMCAP only when you set TERM--which should not | |
| 1381 happen in a non-login shell. | |
| 1382 | |
| 442 | 1383 *** The popup menu appears at the bottom/right of my screen. |
| 373 | 1384 |
| 1389 | 1385 You probably have something like the following in your ~/.Xresources |
| 373 | 1386 |
| 1387 Emacs.geometry: 81x56--9--1 | |
| 1388 | |
| 1389 Use the following instead | |
| 1390 | |
| 1391 Emacs*EmacsFrame.geometry: 81x56--9--1 | |
| 1392 | |
| 1222 | 1393 *** When I try to use the PostgreSQL functions, I get a message about |
| 1394 undefined symbols. | |
| 1395 | |
| 1396 The only known case in which this happens is if you are using gcc, you | |
| 2648 | 1397 configured with --enable-error-checking=all and --enable-modules, and |
| 1398 you compiled with no optimization. If you encounter this problem in any | |
| 1222 | 1399 other situation, please inform xemacs-beta@xemacs.org. |
| 1400 | |
| 1401 This problem stems from a gcc bug. With no optimization, functions | |
| 1402 declared `extern inline' sometimes are not completely compiled away. An | |
| 1403 undefined symbol with the function's name is put into the resulting | |
| 1404 object file. In this case, when the postgresql module is loaded, the | |
| 1405 linker is unable to resolve that symbol, so the module load fails. The | |
| 1406 workaround is to recompile the module with optimization turned on. Any | |
| 1407 optimization level, including -Os, appears to work. | |
| 1408 | |
| 1332 | 1409 *** C-z just refreshes the screen instead of suspending Emacs. |
| 1410 | |
| 1411 You are probably using a shell that doesn't support job control, even | |
| 1412 though the system itself is capable of it. Try using a different | |
| 1413 shell. | |
| 373 | 1414 |
| 1036 | 1415 ** MacOS/X, Darwin |
|
4753
dd933a82720c
Describe duplicate symbols warning.
Stephen J. Turnbull <stephen@xemacs.org>
parents:
4634
diff
changeset
|
1416 *** The linker warns about duplicate symbols. |
|
dd933a82720c
Describe duplicate symbols warning.
Stephen J. Turnbull <stephen@xemacs.org>
parents:
4634
diff
changeset
|
1417 |
|
dd933a82720c
Describe duplicate symbols warning.
Stephen J. Turnbull <stephen@xemacs.org>
parents:
4634
diff
changeset
|
1418 This occurs in the function alarm(), which we deliberately override, |
|
dd933a82720c
Describe duplicate symbols warning.
Stephen J. Turnbull <stephen@xemacs.org>
parents:
4634
diff
changeset
|
1419 and in vendorShellRec when using Xaw3d for the widgets. |
|
dd933a82720c
Describe duplicate symbols warning.
Stephen J. Turnbull <stephen@xemacs.org>
parents:
4634
diff
changeset
|
1420 |
|
dd933a82720c
Describe duplicate symbols warning.
Stephen J. Turnbull <stephen@xemacs.org>
parents:
4634
diff
changeset
|
1421 For alarm(), the linker chooses our version, as desired. |
|
dd933a82720c
Describe duplicate symbols warning.
Stephen J. Turnbull <stephen@xemacs.org>
parents:
4634
diff
changeset
|
1422 Unfortunately, for vendorShellRec, the Xt version is used instead of |
|
dd933a82720c
Describe duplicate symbols warning.
Stephen J. Turnbull <stephen@xemacs.org>
parents:
4634
diff
changeset
|
1423 Xaw3d's. This does not seem to cause problems. |
|
dd933a82720c
Describe duplicate symbols warning.
Stephen J. Turnbull <stephen@xemacs.org>
parents:
4634
diff
changeset
|
1424 |
| 1036 | 1425 *** XEmacs crashes on MacOS within font-lock, or when dealing |
| 1426 with large compilation buffers, or in other regex applications. | |
| 1427 | |
| 3074 | 1428 The default stack size under MacOS/X prior to 10.3 (Panther) is rather |
| 1429 small (512k as opposed to Solaris 8M), hosing the regexp code, which | |
| 1430 uses alloca() extensively, overflowing the stack when complex regexps | |
| 1431 are used. Workarounds: | |
| 1036 | 1432 |
| 1433 1) Increase your stack size, using `ulimit -s 8192' or a (t)csh | |
| 1434 equivalent; | |
| 1435 | |
| 1436 2) Recompile regex.c with REGEX_MALLOC defined. | |
| 1437 | |
| 373 | 1438 ** AIX |
| 1439 *** Your Delete key sends a Backspace to the terminal, using an AIXterm. | |
| 0 | 1440 |
| 1389 | 1441 The solution is to include in your .Xresources the lines: |
| 0 | 1442 |
| 1443 *aixterm.Translations: #override <Key>BackSpace: string(0x7f) | |
| 1444 aixterm*ttyModes: erase ^? | |
| 1445 | |
| 1446 This makes your Backspace key send DEL (ASCII 127). | |
| 1447 | |
| 373 | 1448 *** On AIX 4, some programs fail when run in a Shell buffer |
| 1449 with an error message like No terminfo entry for "unknown". | |
| 124 | 1450 |
| 373 | 1451 On AIX, many terminal type definitions are not installed by default. |
| 1452 `unknown' is one of them. Install the "Special Generic Terminal | |
| 1453 Definitions" to make them defined. | |
| 124 | 1454 |
| 373 | 1455 *** On AIX, you get this message when running Emacs: |
| 0 | 1456 |
| 373 | 1457 Could not load program emacs |
| 1458 Symbol smtcheckinit in csh is undefined | |
| 1459 Error was: Exec format error | |
| 124 | 1460 |
| 373 | 1461 or this one: |
| 0 | 1462 |
| 373 | 1463 Could not load program .emacs |
| 1464 Symbol _system_con in csh is undefined | |
| 1465 Symbol _fp_trapsta in csh is undefined | |
| 1466 Error was: Exec format error | |
| 124 | 1467 |
| 373 | 1468 These can happen when you try to run on AIX 3.2.5 a program that was |
| 1469 compiled with 3.2.4. The fix is to recompile. | |
| 124 | 1470 |
| 373 | 1471 *** Trouble using ptys on AIX. |
| 1472 | |
| 1473 People often install the pty devices on AIX incorrectly. | |
| 1474 Use `smit pty' to reinstall them properly. | |
| 1475 | |
| 0 | 1476 |
| 373 | 1477 ** SunOS/Solaris |
| 1478 *** The Emacs window disappears when you type M-q. | |
| 197 | 1479 |
| 373 | 1480 Some versions of the Open Look window manager interpret M-q as a quit |
| 1481 command for whatever window you are typing at. If you want to use | |
| 1482 Emacs with that window manager, you should try to configure the window | |
| 1483 manager to use some other command. You can disable the | |
| 1484 shortcut keys entirely by adding this line to ~/.OWdefaults: | |
| 0 | 1485 |
| 373 | 1486 OpenWindows.WindowMenuAccelerators: False |
| 1487 | |
| 1488 *** When Emacs tries to ring the bell, you get an error like | |
| 124 | 1489 |
| 1490 audio: sst_open: SETQSIZE" Invalid argument | |
| 1491 audio: sst_close: SETREG MMR2, Invalid argument | |
| 1492 | |
| 197 | 1493 you have probably compiled using an ANSI C compiler, but with non-ANSI |
| 1494 include files. In particular, on Suns, the file | |
| 1495 /usr/include/sun/audioio.h uses the _IOW macro to define the constant | |
| 1496 AUDIOSETQSIZE. _IOW in turn uses a K&R preprocessor feature that is | |
| 1497 now explicitly forbidden in ANSI preprocessors, namely substitution | |
| 1498 inside character constants. All ANSI C compilers must provide a | |
| 1499 workaround for this problem. Lucid's C compiler is shipped with a new | |
| 1500 set of system include files. If you are using GCC, there is a script | |
| 1501 called fixincludes that creates new versions of some system include | |
| 1502 files that use this obsolete feature. | |
| 124 | 1503 |
| 373 | 1504 *** On Solaris 2.6, XEmacs dumps core when exiting. |
| 0 | 1505 |
| 373 | 1506 This happens if you're XEmacs is running on the same machine as the X |
| 1507 server, and the optimized memory transport has been turned on by | |
| 1508 setting the environment variable XSUNTRANSPORT. The crash occurs | |
| 1509 during the call to XCloseDisplay. | |
| 124 | 1510 |
| 373 | 1511 If this describes your situation, you need to undefine the |
| 1512 XSUNTRANSPORT environment variable. | |
| 126 | 1513 |
| 373 | 1514 *** On Solaris, C-x doesn't get through to Emacs when you use the console. |
| 124 | 1515 |
| 373 | 1516 This is a Solaris feature (at least on Intel x86 cpus). Type C-r |
| 1517 C-r C-t, to toggle whether C-x gets through to Emacs. | |
| 124 | 1518 |
| 373 | 1519 *** On Solaris 2.4, Dired hangs and C-g does not work. Or Emacs hangs |
| 197 | 1520 forever waiting for termination of a subprocess that is a zombie. |
| 124 | 1521 |
| 1522 casper@fwi.uva.nl says the problem is in X11R6. Rebuild libX11.so | |
| 1523 after changing the file xc/config/cf/sunLib.tmpl. Change the lines | |
| 1524 | |
| 1525 #if ThreadedX | |
| 1526 #define SharedX11Reqs -lthread | |
| 1527 #endif | |
| 1528 | |
| 1529 to: | |
| 1530 | |
| 1531 #if OSMinorVersion < 4 | |
| 1532 #if ThreadedX | |
| 1533 #define SharedX11Reqs -lthread | |
| 1534 #endif | |
| 1535 #endif | |
| 1536 | |
| 1537 Be sure also to edit x/config/cf/sun.cf so that OSMinorVersion is 4 | |
| 1538 (as it should be for Solaris 2.4). The file has three definitions for | |
| 1539 OSMinorVersion: the first is for x86, the second for SPARC under | |
| 1540 Solaris, and the third for SunOS 4. Make sure to update the | |
| 1541 definition for your type of machine and system. | |
| 1542 | |
| 1543 Then do `make Everything' in the top directory of X11R6, to rebuild | |
| 1544 the makefiles and rebuild X. The X built this way work only on | |
| 1545 Solaris 2.4, not on 2.3. | |
| 1546 | |
| 1547 For multithreaded X to work it necessary to install patch | |
| 1548 101925-02 to fix problems in header files [2.4]. You need | |
| 1549 to reinstall gcc or re-run just-fixinc after installing that | |
| 1550 patch. | |
| 0 | 1551 |
| 124 | 1552 However, Frank Rust <frust@iti.cs.tu-bs.de> used a simpler solution: |
| 1553 he changed | |
| 1554 #define ThreadedX YES | |
| 1555 to | |
| 1556 #define ThreadedX NO | |
| 1557 in sun.cf and did `make World' to rebuild X11R6. Removing all | |
| 1558 `-DXTHREAD*' flags and `-lthread' entries from lib/X11/Makefile and | |
| 1559 typing 'make install' in that directory also seemed to work. | |
| 1560 | |
| 373 | 1561 *** On SunOS 4.1.3, Emacs unpredictably crashes in _yp_dobind_soft. |
| 124 | 1562 |
| 373 | 1563 This happens if you configure Emacs specifying just `sparc-sun-sunos4' |
| 1564 on a system that is version 4.1.3. You must specify the precise | |
| 1565 version number (or let configure figure out the configuration, which | |
| 1566 it can do perfectly well for SunOS). | |
| 124 | 1567 |
| 373 | 1568 *** Mail is lost when sent to local aliases. |
| 0 | 1569 |
| 124 | 1570 Many emacs mail user agents (VM and rmail, for instance) use the |
| 1571 sendmail.el library. This library can arrange for mail to be | |
| 1572 delivered by passing messages to the /usr/lib/sendmail (usually) | |
| 1573 program . In doing so, it passes the '-t' flag to sendmail, which | |
| 1574 means that the name of the recipient of the message is not on the | |
| 1575 command line and, therefore, that sendmail must parse the message to | |
| 1576 obtain the destination address. | |
| 1577 | |
| 1578 There is a bug in the SunOS4.1.1 and SunOS4.1.3 versions of sendmail. | |
| 1579 In short, when given the -t flag, the SunOS sendmail won't recognize | |
| 1580 non-local (i.e. NIS) aliases. It has been reported that the Solaris | |
| 1581 2.x versions of sendmail do not have this bug. For those using SunOS | |
| 1582 4.1, the best fix is to install sendmail V8 or IDA sendmail (which | |
| 1583 have other advantages over the regular sendmail as well). At the time | |
| 1584 of this writing, these official versions are available: | |
| 1585 | |
| 1586 Sendmail V8 on ftp.cs.berkeley.edu in /ucb/sendmail: | |
| 1587 sendmail.8.6.9.base.tar.Z (the base system source & documentation) | |
| 1588 sendmail.8.6.9.cf.tar.Z (configuration files) | |
| 1589 sendmail.8.6.9.misc.tar.Z (miscellaneous support programs) | |
| 1590 sendmail.8.6.9.xdoc.tar.Z (extended documentation, with postscript) | |
| 1591 | |
| 1592 IDA sendmail on vixen.cso.uiuc.edu in /pub: | |
| 1593 sendmail-5.67b+IDA-1.5.tar.gz | |
| 1594 | |
| 373 | 1595 *** Emacs fails to understand most Internet host names, even though |
| 124 | 1596 the names work properly with other programs on the same system. |
| 197 | 1597 Emacs won't work with X-windows if the value of DISPLAY is HOSTNAME:0. |
| 1598 Gnus can't make contact with the specified host for nntp. | |
| 0 | 1599 |
| 124 | 1600 This typically happens on Suns and other systems that use shared |
| 1601 libraries. The cause is that the site has installed a version of the | |
| 1602 shared library which uses a name server--but has not installed a | |
| 1603 similar version of the unshared library which Emacs uses. | |
| 0 | 1604 |
| 124 | 1605 The result is that most programs, using the shared library, work with |
| 1606 the nameserver, but Emacs does not. | |
| 1607 | |
| 1608 The fix is to install an unshared library that corresponds to what you | |
| 1609 installed in the shared library, and then relink Emacs. | |
| 0 | 1610 |
| 124 | 1611 On SunOS 4.1, simply define HAVE_RES_INIT. |
| 1612 | |
| 1613 If you have already installed the name resolver in the file libresolv.a, | |
| 1614 then you need to compile Emacs to use that library. The easiest way to | |
| 1615 do this is to add to config.h a definition of LIBS_SYSTEM, LIBS_MACHINE | |
| 1616 or LIB_STANDARD which uses -lresolv. Watch out! If you redefine a macro | |
| 1617 that is already in use in your configuration to supply some other libraries, | |
| 1618 be careful not to lose the others. | |
| 1619 | |
| 1620 Thus, you could start by adding this to config.h: | |
| 1621 | |
| 1622 #define LIBS_SYSTEM -lresolv | |
| 1623 | |
| 1624 Then if this gives you an error for redefining a macro, and you see that | |
| 1625 the s- file defines LIBS_SYSTEM as -lfoo -lbar, you could change config.h | |
| 1626 again to say this: | |
| 1627 | |
| 1628 #define LIBS_SYSTEM -lresolv -lfoo -lbar | |
| 1629 | |
| 373 | 1630 *** With process-connection-type set to t, each line of subprocess |
| 1631 output is terminated with a ^M, making ange-ftp and GNUS not work. | |
| 1632 | |
| 1633 On SunOS systems, this problem has been seen to be a result of an | |
| 1634 incomplete installation of gcc 2.2 which allowed some non-ANSI | |
| 1635 compatible include files into the compilation. In particular this | |
| 1636 affected virtually all ioctl() calls. | |
| 1637 | |
| 1638 | |
| 1639 ** Linux | |
| 845 | 1640 *** XEmacs crashes on startup, in make-frame. |
| 1641 | |
| 1642 Typically the Lisp backtrace includes | |
| 1643 | |
| 1644 make-frame(nil #<x-device on ":0.0" 0x2558>) | |
| 1645 | |
| 2648 | 1646 somewhere near the top. The problem is due to an improvement in GNU ld |
| 1647 that sorts the ELF reloc sections in the executable, giving dramatic | |
| 1648 speedups in startup for large executables. It also confuses the | |
| 1649 traditional unexec code in XEmacs, leading to the core dump. The | |
| 1650 solution is to use the --enable-pdump or --with-ldflags='-z nocombreloc' | |
| 1651 options to configure. Recent 21.4 and 12.5 autodetect this in | |
| 1652 configure. | |
| 845 | 1653 |
| 1654 Red Hat and SuSE (at least) distributed a prerelease version of ld | |
| 1655 (versions around 2.11.90.x.y) where autodetection is impossible. The | |
| 1656 recommended procedure is to upgrade to binutils >= 2.12 and rerun | |
| 2648 | 1657 configure. Otherwise you must apply the flags by hand. --enable-pdump |
| 1658 is recommended. | |
| 448 | 1659 |
| 1660 *** I want XEmacs to use the Alt key, not the XXX key, for Meta commands | |
| 1661 | |
| 1662 For historical reasons, XEmacs looks for a Meta key, then an Alt key. | |
| 1663 It binds Meta commands to the X11 modifier bit attached to the first | |
| 1664 of these it finds. On PCs, the Windows key is often assigned the Meta | |
| 1665 bit, but many desktop environments go to great lengths to get all apps | |
| 1666 to use the Alt key, and reserve the Windows key to (sensibly enough) | |
| 1667 the window manager. | |
| 1668 | |
| 1669 One correct way to implement this was suggested on comp.emacs.xemacs | |
| 1670 (by Kilian Foth and in more detail by Michael Piotrowski): unmap the | |
| 1671 Meta modifier using xmodmap or xkb, and then map the Meta/Windows key | |
| 450 | 1672 to the Super or Hyper keysym and an appropriate mod bit. XEmacs will |
| 1673 not find the Meta keysym, and default to using the Alt key for Meta | |
| 1674 keybindings. Typically few applications use the (X11) Meta modifier; | |
| 1675 it is tedious but not too much so to teach the ones you need to use | |
| 1676 Super instead of Meta. There may be further useful hints in the | |
| 1677 discussion of keymapping on non-Linux platforms. | |
| 1678 | |
| 1679 *** The color-gcc wrapper | |
| 1680 | |
| 1681 This wrapper colorizes the error messages from gcc. By default XEmacs | |
| 1682 does not interpret the escape sequences used to generate colors, | |
| 1683 resulting in a cluttered, hard-to-read buffer. You can remove the | |
| 1684 wrapper, or defeat the wrapper colorization in Emacs process buffers | |
| 1685 by editing the "nocolor" attribute in /etc/colorgccrc: | |
| 1686 | |
| 1687 $ diff -u /etc/colorgccrc.old /etc/colorgccrc | |
| 1688 --- /etc/colorgccrc.old Tue Dec 26 02:17:46 2000 | |
| 1689 +++ /etc/colorgccrc Tue Dec 26 02:15:48 2000 | |
| 1690 @@ -34,1 +34,1 @@ | |
| 1691 -nocolor: dumb | |
| 1692 +nocolor: dumb emacs | |
| 1693 | |
| 1694 If you want colorization in your Emacs buffers, you may get good | |
| 1695 results from the ansi-color.el library: | |
| 1696 | |
| 1697 http://www.geocities.com/kensanata/color-emacs.html#ansicolors | |
| 1698 | |
| 1699 This is written for the mainline GNU Emacs but the author has made | |
| 1700 efforts to adapt it to XEmacs. YMMV. | |
| 448 | 1701 |
| 373 | 1702 *** Slow startup on Linux. |
| 1703 | |
| 1704 People using systems based on the Linux kernel sometimes report that | |
| 448 | 1705 startup takes 10 to 15 seconds longer than `usual'. There are two |
| 1706 problems, one older, one newer. | |
| 1707 | |
| 1708 **** Old problem: IPv4 host lookup | |
| 373 | 1709 |
| 448 | 1710 On older systems, this is because Emacs looks up the host name when it |
| 1711 starts. Normally, this takes negligible time; the extra delay is due | |
| 1712 to improper system configuration. (Recent Linux distros usually have | |
| 1713 this configuration correct "out of the box".) This problem can occur | |
| 1714 for both networked and non-networked machines. | |
| 373 | 1715 |
| 1716 Here is how to fix the configuration. It requires being root. | |
| 1717 | |
| 448 | 1718 ***** Networked Case |
| 373 | 1719 |
| 1720 First, make sure the files `/etc/hosts' and `/etc/host.conf' both | |
| 1721 exist. The first line in the `/etc/hosts' file should look like this | |
| 1722 (replace HOSTNAME with your host name): | |
| 1723 | |
| 1724 127.0.0.1 localhost HOSTNAME | |
| 1725 | |
| 1726 Also make sure that the `/etc/host.conf' files contains the following | |
| 1727 lines: | |
| 1728 | |
| 454 | 1729 order hosts, bind |
| 373 | 1730 multi on |
| 1731 | |
| 1732 Any changes, permanent and temporary, to the host name should be | |
| 1733 indicated in the `/etc/hosts' file, since it acts a limited local | |
| 1734 database of addresses and names (e.g., some SLIP connections | |
| 1735 dynamically allocate ip addresses). | |
| 1736 | |
| 448 | 1737 ***** Non-Networked Case |
| 373 | 1738 |
| 1739 The solution described in the networked case applies here as well. | |
| 1740 However, if you never intend to network your machine, you can use a | |
| 1741 simpler solution: create an empty `/etc/host.conf' file. The command | |
| 1742 `touch /etc/host.conf' suffices to create the file. The `/etc/hosts' | |
| 1743 file is not necessary with this approach. | |
| 1744 | |
| 448 | 1745 **** New problem: IPv6 CNAME lookup |
| 1746 | |
| 1747 A newer problem is due to XEmacs changing to use the modern | |
| 1748 getaddrinfo() interface from the older gethostbyname() interface. The | |
| 1749 solution above is insufficient, because getaddrinfo() by default tries | |
| 1750 to get IPv6 information for localhost. This always involves a dns | |
| 1751 lookup to get the CNAME, and the strategies above don't work. It then | |
| 724 | 1752 falls back to IPv4 behavior. This is good[tm] according the people at |
| 1753 WIDE who know about IPv6. | |
| 448 | 1754 |
| 1755 ***** Robust network case | |
| 1756 | |
| 1757 Configure your network so that there are no nameservers configured | |
| 1758 until the network is actually running. getaddrinfo() will not try to | |
| 1759 access a nameserver that isn't configured. | |
| 1760 | |
| 1761 ***** Flaky network case | |
| 1762 | |
| 1763 If you have a flaky modem or DSL connection that can be relied on only | |
| 1764 to go down whenever you want to bring XEmacs up, you need to force | |
| 1765 IPv4 behavior. Explicitly setting DISPLAY=127.0.0.1:0.0 (or whatever | |
| 1766 is appropriate) works in most cases. | |
| 1767 | |
| 1768 If you cannot or do not want to do that, you can hard code IPv4 | |
| 1769 behavior in src/process-unix.c. This is bad[tm], on your own head be | |
| 724 | 1770 it. Use the configure option `--with-ipv6-cname=no'. |
| 373 | 1771 |
| 845 | 1772 *** Mandrake |
| 1773 | |
| 1774 The Mandrake Linux distribution is attempting to comprehensively | |
| 1775 update the user interface, and make it consistent across | |
| 1776 applications. This is very difficult, and will occasionally cause | |
| 1777 conflicts with applications like Emacs with their own long-established | |
| 1778 interfaces. Known issues specific to Mandrake or especially common: | |
| 1779 | |
| 1780 Some versions of XEmacs (21.1.9 is known) distributed with Mandrake | |
| 1781 were patched to make the Meta and Alt keysyms synonymous. These | |
| 1782 normally work as expected in the Mandrake environment. However, | |
| 1783 custom-built XEmacsen (including all 21.2 betas) will "inexplicably" | |
| 1784 not respect the "Alt-invokes-Meta-commands" convention. See "I want | |
| 1785 XEmacs to use the Alt key" below. | |
| 1786 | |
| 1787 The color-gcc wrapper (see below) is in common use on the Mandrake | |
| 1788 platform. | |
| 1789 | |
| 1790 *** You get crashes in a non-C locale with Linux GNU Libc 2.0. | |
| 1791 | |
| 1792 Internationalization was not the top priority for GNU Libc 2.0. | |
| 1793 As of this writing (1998-12-28) you may get crashes while running | |
| 1794 XEmacs in a non-C locale. For example, `LC_ALL=en_US xemacs' crashes | |
| 1795 while `LC_ALL=C xemacs' runs fine. This happens for example with GNU | |
| 1796 libc 2.0.7. Installing libintl.a and libintl.h built from gettext | |
| 1797 0.10.35 and re-building XEmacs solves the crashes. Presumably soon | |
| 1798 everyone will upgrade to GNU Libc 2.1 and this problem will go away. | |
| 1799 | |
| 1800 *** `C-z', or `M-x suspend-emacs' hangs instead of suspending. | |
| 1801 | |
| 1802 If you build with `gpm' support on Linux, you cannot suspend XEmacs | |
| 1803 because gpm installs a buggy SIGTSTP handler. Either compile with | |
| 1804 `--with-gpm=no', or don't suspend XEmacs on the Linux console until | |
| 1805 this bug is fixed. | |
| 1806 | |
| 1807 *** With certain fonts, when the cursor appears on a character, the | |
| 1808 character doesn't appear--you get a solid box instead. | |
| 1809 | |
| 1810 One user on a Linux system reported that this problem went away with | |
| 1811 installation of a new X server. The failing server was XFree86 3.1.1. | |
| 1812 XFree86 3.1.2 works. | |
| 1813 | |
| 373 | 1814 ** IRIX |
| 1815 *** On Irix, I don't see the toolbar icons and I'm getting lots of | |
| 1816 entries in the warnings buffer. | |
| 1817 | |
| 1818 SGI ships a really old Xpm library in /usr/lib which does not work at | |
| 1819 all well with XEmacs. The solution is to install your own copy of the | |
| 2648 | 1820 latest version of Xpm somewhere and then use the --with-site-includes |
| 1821 and --with-site-libraries flags to tell configure where to find it. | |
| 373 | 1822 |
| 1823 *** Trouble using ptys on IRIX, or running out of ptys. | |
| 1824 | |
| 1825 The program mkpts (which may be in `/usr/adm' or `/usr/sbin') needs to | |
| 1826 be set-UID to root, or non-root programs like Emacs will not be able | |
| 1827 to allocate ptys reliably. | |
| 1828 | |
| 1829 *** Beware of the default image & graphics library on Irix | |
| 1830 | |
| 1831 Richard Cognot <cognot@ensg.u-nancy.fr> writes: | |
| 1832 | |
| 1833 You *have* to compile your own jpeg lib. The one delivered with SGI | |
| 1834 systems is a C++ lib, which apparently XEmacs cannot cope with. | |
| 1835 | |
| 1836 | |
| 1837 ** Digital UNIX/OSF/VMS/Ultrix | |
| 1838 *** XEmacs crashes on Digital Unix within font-lock, or when dealing | |
| 1036 | 1839 with large compilation buffers, or in other regex applications. |
| 373 | 1840 |
| 1841 The default stack size under Digital Unix is rather small (2M as | |
| 1842 opposed to Solaris 8M), hosing the regexp code, which uses alloca() | |
| 1843 extensively, overflowing the stack when complex regexps are used. | |
| 1844 Workarounds: | |
| 312 | 1845 |
| 373 | 1846 1) Increase your stack size, using `ulimit -s 8192' or a (t)csh |
| 1847 equivalent; | |
| 1848 | |
| 1849 2) Recompile regex.c with REGEX_MALLOC defined. | |
| 1850 | |
| 1851 *** The `Alt' key doesn't behave as `Meta' when running DECwindows. | |
| 1852 | |
| 1853 The default DEC keyboard mapping has the Alt keys set up to generate the | |
| 1854 keysym `Multi_key', which has a meaning to xemacs which is distinct from that | |
| 1855 of the `Meta_L' and `Meta-R' keysyms. A second problem is that certain keys | |
| 1856 have the Mod2 modifier attached to them for no adequately explored reason. | |
| 1857 The correct fix is to pass this file to xmodmap upon starting X: | |
| 1858 | |
| 1859 clear mod2 | |
| 1860 keysym Multi_key = Alt_L | |
| 1861 add mod1 = Alt_L | |
| 1862 add mod1 = Alt_R | |
| 1863 | |
| 1864 *** The Compose key on a DEC keyboard does not work as Meta key. | |
| 1865 | |
| 1866 This shell command should fix it: | |
| 1867 | |
| 1868 xmodmap -e 'keycode 0xb1 = Meta_L' | |
| 1869 | |
| 1870 *** `expand-file-name' fails to work on any but the machine you dumped | |
| 1871 Emacs on. | |
| 1872 | |
| 1873 On Ultrix, if you use any of the functions which look up information | |
| 1874 in the passwd database before dumping Emacs (say, by using | |
| 1875 expand-file-name in site-init.el), then those functions will not work | |
| 1876 in the dumped Emacs on any host but the one Emacs was dumped on. | |
| 1877 | |
| 1878 The solution? Don't use expand-file-name in site-init.el, or in | |
| 1879 anything it loads. Yuck - some solution. | |
| 1880 | |
| 1881 I'm not sure why this happens; if you can find out exactly what is | |
| 1882 going on, and perhaps find a fix or a workaround, please let us know. | |
| 1883 Perhaps the YP functions cache some information, the cache is included | |
| 1884 in the dumped Emacs, and is then inaccurate on any other host. | |
| 1885 | |
| 1886 | |
| 1887 ** HP-UX | |
| 1888 *** I get complaints about the mapping of my HP keyboard at startup, | |
| 1889 but I haven't changed anything. | |
| 1890 | |
| 1891 The default HP keymap is set up to have Mod1 assigned to two different keys: | |
| 1892 Meta_L and Mode_switch (even though there is not actually a Mode_switch key on | |
| 1893 the keyboard -- it uses an "imaginary" keycode.) There actually is a reason | |
| 1894 for this, but it's not a good one. The correct fix is to execute this command | |
| 1895 upon starting X: | |
| 1896 | |
| 1897 xmodmap -e 'remove mod1 = Mode_switch' | |
| 312 | 1898 |
| 373 | 1899 *** On HP-UX, you get "poll: Interrupted system call" message in the |
| 1900 window where XEmacs was launched. | |
| 1901 | |
| 1902 Richard Cognot <cognot@ensg.u-nancy.fr> writes: | |
| 1903 | |
| 1904 I get a very strange problem when linking libc.a dynamically: every | |
| 1905 event (mouse, keyboard, expose...) results in a "poll: Interrupted | |
| 1906 system call" message in the window where XEmacs was | |
| 1907 launched. Forcing a static link of libc.a alone by adding | |
| 1908 /usr/lib/libc.a at the end of the link line solves this. Note that | |
| 1909 my 9.07 build of 19.14b17 and my (old) build of 19.13 both exhibit | |
| 442 | 1910 the same behavior. I've tried various hpux patches to no avail. If |
| 373 | 1911 this problem cannot be solved before the release date, binary kits |
| 1912 for HP *must* be linked statically against libc, otherwise this | |
| 1913 problem will show up. (This is directed at whoever will volunteer | |
| 1914 for this kit, as I won't be available to do it, unless 19.14 gets | |
| 1915 delayed until mid-june ;-). I think this problem will be an FAQ soon | |
| 1916 after the release otherwise. | |
| 1917 | |
| 1918 Note: The above entry is probably not valid for XEmacs 21.0 and | |
| 1919 later. | |
| 1920 | |
| 1921 *** The right Alt key works wrong on German HP keyboards (and perhaps | |
| 1922 other non-English HP keyboards too). | |
| 1923 | |
| 1924 This is because HP-UX defines the modifiers wrong in X. Here is a | |
| 1925 shell script to fix the problem; be sure that it is run after VUE | |
| 1926 configures the X server. | |
| 1927 | |
| 1928 xmodmap 2> /dev/null - << EOF | |
| 1929 keysym Alt_L = Meta_L | |
| 1930 keysym Alt_R = Meta_R | |
| 1931 EOF | |
| 1932 | |
| 1933 xmodmap - << EOF | |
| 1934 clear mod1 | |
| 1935 keysym Mode_switch = NoSymbol | |
| 1936 add mod1 = Meta_L | |
| 1937 keysym Meta_R = Mode_switch | |
| 1938 add mod2 = Mode_switch | |
| 1939 EOF | |
| 1940 | |
| 442 | 1941 |
| 1942 *** XEmacs dumps core at startup when native audio is used. Native | |
| 1943 audio does not work with recent versions of HP-UX. | |
| 1944 | |
| 1945 Under HP-UX 10.20 and later (e.g., HP-UX 11.XX), with native audio | |
| 1946 enabled, the dumped XEmacs binary ("xemacs") core dumps at startup if | |
| 1947 recent versions of the libAlib.sl audio shared library is used. Note | |
| 1948 that "temacs" will run, but "xemacs" will dump core. This, of course, | |
| 1949 causes the XEmacs build to fail. If GNU malloc is enabled, a stack | |
| 1950 trace will show XEmacs to have crashed in the "first" call to malloc(). | |
| 1951 | |
| 1952 This bug currently exists in all versions of XEmacs, when the undump | |
| 1953 mechanism is used. It is not known if using the experimental portable | |
| 1954 dumper will allow native audio to work. | |
| 1955 | |
| 1956 **** Cause: | |
| 1957 | |
| 1958 Recent versions of the HP-UX 10.20 (and later) audio shared library (in | |
| 1959 /opt/audio/lib), pulls in the libdce shared library, which pulls in a | |
| 1960 thread (libcma) library. This prevents the HP-UX undump() routine (in | |
| 1961 unexhp9k800.c) from properly working. What's happening is that some | |
| 1962 initialization routines are being called in the libcma library, *BEFORE* | |
| 1963 main() is called, and these initialization routines are calling | |
| 1964 malloc(). Unfortunately, in order for the undumper to work, XEmacs must | |
| 1965 adjust (move upwards) the sbrk() value *BEFORE* the first call to | |
| 1966 malloc(); if malloc() is called before XEmacs has properly adjusted sbrk | |
| 1967 (which is what is happening), dumped memory that is being used by | |
| 1968 XEmacs, is improperly re-allocated for use by malloc() and the dumped | |
| 1969 memory is corrupted. This causes XEmacs to die an horrible death. | |
| 1970 | |
| 1971 It is believed that versions of the audio library past December 1998 | |
| 1972 will trigger this problem. Under HP-UX 10.20, you probably have to | |
| 1973 install audio library patches to encounter this. It's probable that | |
| 1974 recent "fresh, out-of-the-box" HP-UX 11.XX workstations also have this | |
| 1975 problem. For HP-UX 10.20, it's believed that audio patch PHSS_17121 (or | |
| 1976 a superceeding one, like PHSS_17554, PHSS_17971, PHSS_18777, PHSS_21481, | |
| 1977 or PHSS_21662, etc.) will trigger this. | |
| 1978 | |
| 1979 To check if your audio library will cause problems for XEmacs, run | |
| 1980 "chatr /opt/audio/lib/libAlib.sl". If "libdce" appears in the displayed | |
| 1981 shared library list, XEmacs will probably encounter problems if audio is | |
| 1982 enabled. | |
| 1983 | |
| 1984 **** Workaround: | |
| 1985 | |
| 1986 Don't enable native audio. Re-run configure without native audio | |
| 1987 support. | |
| 1988 | |
| 1989 If your site supports it, try using NAS (Network Audio Support). | |
| 1990 | |
| 1991 Try using the experimental portable dumper. It may work, or it may | |
| 1992 not. | |
| 1993 | |
| 1994 | |
| 373 | 1995 *** `Pid xxx killed due to text modification or page I/O error' |
| 1996 | |
| 1997 On HP-UX, you can get that error when the Emacs executable is on an NFS | |
| 1998 file system. HP-UX responds this way if it tries to swap in a page and | |
| 1999 does not get a response from the server within a timeout whose default | |
| 2000 value is just ten seconds. | |
| 2001 | |
| 2002 If this happens to you, extend the timeout period. | |
| 2003 | |
| 2004 *** Shell mode on HP-UX gives the message, "`tty`: Ambiguous". | |
| 124 | 2005 |
| 2006 christos@theory.tn.cornell.edu says: | |
| 2007 | |
| 2008 The problem is that in your .cshrc you have something that tries to | |
| 197 | 2009 execute `tty`. If you are not running the shell on a real tty then tty |
| 2010 will print "not a tty". Csh expects one word in some places, but tty | |
| 2011 is giving it back 3. | |
| 124 | 2012 |
| 197 | 2013 The solution is to add a pair of quotes around `tty` to make it a |
| 2014 single word: | |
| 0 | 2015 |
| 454 | 2016 if (`tty` == "/dev/console") |
| 124 | 2017 |
| 2018 should be changed to: | |
| 2019 | |
| 454 | 2020 if ("`tty`" == "/dev/console") |
| 124 | 2021 |
| 2022 Even better, move things that set up terminal sections out of .cshrc | |
| 2023 and into .login. | |
| 0 | 2024 |
| 2025 | |
| 373 | 2026 ** SCO |
| 2027 *** Regular expressions matching bugs on SCO systems. | |
| 0 | 2028 |
| 373 | 2029 On SCO, there are problems in regexp matching when Emacs is compiled |
| 2030 with the system compiler. The compiler version is "Microsoft C | |
| 2031 version 6", SCO 4.2.0h Dev Sys Maintenance Supplement 01/06/93; Quick | |
| 2032 C Compiler Version 1.00.46 (Beta). The solution is to compile with | |
| 2033 GCC. | |
| 124 | 2034 |
| 88 | 2035 |
| 373 | 2036 ** Windows |
| 1332 | 2037 *** Conflicts with FSF NTEmacs |
| 2038 | |
| 2039 Depending on how it is installed, FSF NTEmacs may setup various EMACS* | |
| 2040 variables in your environment. The presence of these variables may | |
| 2041 cause XEmacs to fail at startup, cause you to see corrupted | |
| 2042 doc-strings, or cause other random problems. | |
| 2043 | |
| 2044 You should remove these variables from your environment. These | |
| 2045 variables are not required to run FSF NTEmacs if you start it by | |
| 2046 running emacs.bat. | |
| 2047 | |
| 2048 *** XEmacs can't find my init file | |
| 2049 | |
| 2050 XEmacs looks for your init in your "home" directory -- either in | |
| 2051 `~/.xemacs/init.el' or `~/.emacs'. XEmacs decides that your "home" | |
| 2052 directory is, in order of preference: | |
| 2053 | |
| 2054 - The value of the HOME environment variable, if the variable exists. | |
| 2055 - The value of the registry entry SOFTWARE\XEmacs\XEmacs\HOME, | |
| 2056 if it exists. | |
| 2057 - The value of the HOMEDRIVE and HOMEPATH environment variables, if | |
| 2058 these variables both exist. | |
| 2059 - C:\. | |
| 2060 | |
| 2061 To determine what XEmacs thinks your home directory is, try opening | |
| 2062 a file in the `~' directory, and you should see its expansion in the | |
| 2063 modeline. If this doesn't work, type ESC : (user-home-directory). | |
| 2064 | |
| 2065 *** XEmacs can't find any packages | |
| 2066 | |
| 2067 XEmacs looks for your packages in subdirectories of a directory which | |
| 2068 is set at compile-time (see `config.inc'), and whose default is | |
| 2069 `C:\Program Files\XEmacs'. XEmacs also looks in `~/.xemacs', where | |
| 2070 `~' refers to your home directory (see previous entry). The variable | |
| 2071 `configure-package-path' holds the actual path that was compiled into | |
| 2072 your copy of XEmacs. | |
| 2073 | |
| 2074 The compile-time default location can be overridden by the EMACSPACKAGEPATH | |
| 2075 environment variable or by the SOFTWARE\XEmacs\XEmacs\EMACSPACKAGEPATH | |
| 2076 registry entry. You should check that these variables, if they exist, | |
| 2077 point to the actual location of your package tree. | |
| 2078 | |
| 2079 *** XEmacs doesn't die when shutting down Windows 95 or 98 | |
| 2080 | |
| 2081 When shutting down Windows 95 or 98 you may see a dialog that says | |
| 2082 "xemacs / You must quit this program before you quit Windows". | |
| 2083 It is safe to | |
| 2084 "Click OK to quit the program and Windows", | |
| 2085 but you won't be offered a chance to save any modified XEmacs buffers. | |
| 2086 | |
| 2087 *** Key bindings | |
| 2088 | |
| 2089 The C-z, C-x, C-c, and C-v keystrokes have traditional uses in both | |
| 2090 emacs and Windows programs. XEmacs binds these keys to their | |
| 2091 traditional emacs uses, and provides Windows 3.x style bindings for | |
| 2092 the Cut, Copy and Paste functions. | |
| 2093 | |
| 2094 Function XEmacs binding | |
| 2095 -------- -------------- | |
| 2096 Undo C-_ | |
| 2097 Cut Sh-Del | |
| 2098 Copy C-Insert | |
| 2099 Paste Sh-Insert | |
| 2100 | |
| 2101 You can rebind keys to make XEmacs more Windows-compatible; for | |
| 2102 example, to bind C-z to undo: | |
| 2103 | |
| 2104 (global-set-key [(control z)] 'undo) | |
| 2105 | |
| 2106 Rebindind C-x and C-c is trickier because by default these are prefix | |
| 2107 keys in XEmacs. See the "Key Bindings" node in the XEmacs manual. | |
| 2108 | |
| 2109 *** Behavior of selected regions | |
| 2110 | |
| 2111 Use the pending-del package to enable the standard Windows behavior of | |
| 2112 self-inserting deletes region. | |
| 2113 | |
| 2114 *** Limitations on the use of the AltGr key. | |
| 2115 | |
| 2116 In some locale and OS combinations you can't generate M-AltGr-key or | |
| 2117 C-M-AltGr-key sequences at all. | |
| 2118 | |
| 2119 To generate C-AltGr-key or C-M-AltGr-key sequences you must use the | |
| 2120 right-hand Control key and you must press it *after* AltGr. | |
| 2121 | |
| 2122 These limitations arise from fundamental problems in the way that the | |
| 2123 win32 API reports AltGr key events. There isn't anything that XEmacs | |
| 2124 can do to work round these problems that it isn't already doing. | |
| 2125 | |
| 2126 You may want to create alternative bindings if any of the standard | |
| 2127 XEmacs bindings require you to use some combination of Control or Meta | |
| 2128 and AltGr. | |
| 2129 | |
| 2130 *** Limited support for subprocesses under Windows 9x | |
| 2131 | |
| 2132 Attempting to use call-process to run a 16bit program gives a | |
| 2133 "Spawning child process: Exec format error". For example shell-command | |
| 2134 fails under Windows 95 and 98 if you use command.com or any other | |
| 2135 16bit program as your shell. | |
| 2136 | |
| 2137 XEmacs may incorrectly quote your call-process command if it contains | |
| 2138 double quotes, backslashes or spaces. | |
| 2139 | |
| 2140 start-process and functions that rely on it are supported under Windows 95, | |
| 2141 98 and NT. However, starting a 16bit program that requires keyboard input | |
| 2142 may cause XEmacs to hang or crash under Windows 95 and 98, and will leave | |
| 2143 the orphaned 16bit program consuming all available CPU time. | |
| 2144 | |
| 2145 Sending signals to subprocesses started by call-process or by | |
| 2146 start-process fails with a "Cannot send signal to process" error under | |
| 2147 Windows 95 and 98. As a side effect of this, quitting XEmacs while it | |
| 2148 is still running subprocesses causes it to crash under Windows 95 and | |
| 2149 98. | |
| 524 | 2150 |
| 2151 | |
| 2152 ** Cygwin | |
| 1318 | 2153 *** Signal 11 when building or running a dumped XEmacs. |
| 2154 | |
| 2155 See the section on Cygwin above, under building. | |
| 2156 | |
| 1058 | 2157 *** XEmacs fails to start because cygXpm-noX4.dll was not found. |
| 2158 | |
| 2159 Andy Piper <andy@xemacs.org> sez: | |
| 2160 | |
| 2161 cygXpm-noX4 is part of the cygwin distribution under libraries or | |
| 2162 graphics, but is not installed by default. You need to run the | |
| 2163 cygwin setup again and select this package. | |
| 2164 | |
| 524 | 2165 *** Subprocesses do not work. |
| 2166 | |
| 2167 You do not have "tty" in your CYGWIN environment variable. This must | |
| 2168 be set in your autoexec.bat (win95) or the system properties (winnt) | |
| 2169 as it must be read before the cygwin DLL initializes. | |
| 2170 | |
| 2171 *** ^G does not work on hung subprocesses. | |
| 124 | 2172 |
| 524 | 2173 This is a known problem. It can be remedied by defining BROKEN_SIGIO |
| 2174 in src/s/cygwin.h, however this currently leads to instability in XEmacs. | |
| 2175 (#### is this still true?) | |
| 2176 | |
| 2177 *** Errors from make like `/c:not found' when running `M-x compile'. | |
| 308 | 2178 |
| 524 | 2179 Make sure you set the environment variable MAKE_MODE to UNIX in your |
| 2180 init file (.xemacs/init.el), Control Panel (Windows 2000/NT), or | |
| 2181 AUTOEXEC.BAT (Windows 98/95). | |
| 2182 | |
| 2183 *** There are no images in the toolbar buttons. | |
| 2184 | |
| 2185 You need version 4.71 of commctrl.dll which does not ship with windows | |
| 2186 95. You can get this by installing IE 4.0 or downloading it from the | |
| 2187 microsoft website. | |
| 308 | 2188 |
| 197 | 2189 |
| 124 | 2190 * Compatibility problems (with Emacs 18, GNU Emacs, or previous XEmacs/lemacs) |
| 197 | 2191 ============================================================================== |
| 88 | 2192 |
| 373 | 2193 *** "Symbol's value as variable is void: unread-command-char". |
| 197 | 2194 "Wrong type argument: arrayp, #<keymap 143 entries>" |
| 2195 "Wrong type argument: stringp, [#<keypress-event return>]" | |
| 88 | 2196 |
| 124 | 2197 There are a few incompatible changes in XEmacs, and these are the |
| 2198 symptoms. Some of the emacs-lisp code you are running needs to be | |
| 2199 updated to be compatible with XEmacs. | |
| 2200 | |
| 2201 The code should not treat keymaps as arrays (use `define-key', etc.), | |
| 2202 should not use obsolete variables like `unread-command-char' (use | |
| 197 | 2203 `unread-command-events'). Many (most) of the new ways of doing things |
| 124 | 2204 are compatible in GNU Emacs and XEmacs. |
| 88 | 2205 |
| 197 | 2206 Modern Emacs packages (Gnus, VM, W3, efs, etc) are written to support |
| 2207 GNU Emacs and XEmacs. We have provided modified versions of several | |
| 2208 popular emacs packages (dired, etc) which are compatible with this | |
| 2209 version of emacs. Check to make sure you have not set your load-path | |
| 2210 so that your private copies of these packages are being found before | |
| 2211 the versions in the lisp directory. | |
| 124 | 2212 |
| 2213 Make sure that your load-path and your $EMACSLOADPATH environment | |
| 2214 variable are not pointing at an Emacs18 lisp directory. This will | |
| 2215 cripple emacs. | |
| 88 | 2216 |
| 124 | 2217 ** Some packages that worked before now cause the error |
| 223 | 2218 Wrong type argument: arrayp, #<face ... > |
| 124 | 2219 |
| 197 | 2220 Code which uses the `face' accessor functions must be recompiled with |
| 2221 xemacs 19.9 or later. The functions whose callers must be recompiled | |
| 2222 are: face-font, face-foreground, face-background, | |
| 2223 face-background-pixmap, and face-underline-p. The .elc files | |
| 2224 generated by version 19.9 will work in 19.6 and 19.8, but older .elc | |
| 2225 files which contain calls to these functions will not work in 19.9. | |
| 124 | 2226 |
| 2227 ** Signaling: (error "Byte code stack underflow (byte compiler bug), pc 38") | |
| 88 | 2228 |
| 120 | 2229 This error is given when XEmacs 20 is compiled without MULE support |
| 88 | 2230 but is attempting to load a .elc which requires MULE support. The fix |
| 2231 is to rebytecompile the offending file. | |
| 2232 | |
| 124 | 2233 ** Signaling: (wrong-type-argument ...) when loading mail-abbrevs |
| 88 | 2234 |
| 197 | 2235 The is seen when installing the Insidious Big Brother Data Base (bbdb) |
| 2236 which includes an outdated copy of mail-abbrevs.el. Remove the copy | |
| 2237 that comes with bbdb and use the one that comes with XEmacs. | |
| 2238 | |
| 144 | 2239 |
| 2240 * MULE issues | |
| 197 | 2241 ============= |
| 144 | 2242 |
| 223 | 2243 ** A reminder: XEmacs/Mule work does not currently receive *any* |
| 2244 funding, and all work is done by volunteers. If you think you can | |
| 2245 help, please contact the XEmacs maintainers. | |
| 2246 | |
| 278 | 2247 ** XEmacs/Mule doesn't support TTY's satisfactorily. |
| 223 | 2248 |
| 2249 This is a major problem, which we plan to address in a future release | |
| 2250 of XEmacs. Basically, XEmacs should have primitives to be told | |
| 2251 whether the terminal can handle international output, and which | |
| 2252 locale. Also, it should be able to do approximations of characters to | |
| 2253 the nearest supported by the locale. | |
| 2254 | |
| 197 | 2255 ** Internationalized (Asian) Isearch doesn't work. |
| 144 | 2256 |
| 2257 Currently, Isearch doesn't directly support any of the input methods | |
| 2258 that are not XIM based (like egg, canna and quail) (and there are | |
| 223 | 2259 potential problems with XIM version too...). If you're using egg |
| 2260 there is a workaround. Hitting <RET> right after C-s to invoke | |
| 2261 Isearch will put Isearch in string mode, where a complete string can | |
| 2262 be typed into the minibuffer and then processed by Isearch afterwards. | |
| 2263 Since egg is now supported in the minibuffer using string mode you can | |
| 2264 now use egg to input your Japanese, Korean or Chinese string, then hit | |
| 2265 return to send that to Isearch and then use standard Isearch commands | |
| 2266 from there. | |
| 144 | 2267 |
| 223 | 2268 ** Using egg and mousing around while in 'fence' mode screws up my |
| 2269 buffer. | |
| 144 | 2270 |
| 2271 Don't do this. The fence modes of egg and canna are currently very | |
| 2272 modal, and messing with where they expect point to be and what they | |
| 2273 think is the current buffer is just asking for trouble. If you're | |
| 2274 lucky they will realize that something is awry, and simply delete the | |
| 2275 fence, but worst case can trash other buffers too. We've tried to | |
| 2276 protect against this where we can, but there still are many ways to | |
| 2277 shoot yourself in the foot. So just finish what you are typing into | |
| 2278 the fence before reaching for the mouse. | |
| 223 | 2279 |
| 2280 ** Not all languages in Quail are supported like Devanagari and Indian | |
| 2281 languages, Lao and Tibetan. | |
| 2282 | |
| 2283 Quail requires more work and testing. Although it has been ported to | |
| 2284 XEmacs, it works really well for Japanese and for the European | |
| 2285 languages. | |
| 2286 | |
| 2287 ** Right-to-left mode is not yet implemented, so languages like | |
| 2288 Arabic, Hebrew and Thai don't work. | |
| 2289 | |
| 2290 Getting this right requires more work. It may be implemented in a | |
| 2291 future XEmacs version, but don't hold your breath. If you know | |
| 2292 someone who is ready to implement this, please let us know. | |
| 2293 | |
| 2294 ** We need more developers and native language testers. It's extremely | |
| 2295 difficult (and not particularly productive) to address languages that | |
| 2296 nobody is using and testing. | |
| 2297 | |
| 2298 ** The kWnn and cWnn support for Chinese and Korean needs developers | |
| 2299 and testers. It probably doesn't work. | |
| 2300 | |
| 2301 ** There are no `native XEmacs' TUTORIALs for any Asian languages, | |
| 454 | 2302 including Japanese. FSF Emacs and XEmacs tutorials are quite similar, |
| 223 | 2303 so it should be sufficient to skim through the differences and apply |
| 2304 them to the Japanese version. | |
| 2305 | |
| 2306 ** We only have localized menus translated for Japanese, and the | |
| 2307 Japanese menus are developing bitrot (the Mule menu appears in | |
| 2308 English). | |
| 2309 | |
| 2310 ** XIM is untested for any language other than Japanese. |