From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ivan Shmakov Newsgroups: gmane.emacs.bugs Subject: bug#20011: etc/PROBLEMS: updates, wording, typos Date: Thu, 05 Mar 2015 21:49:22 +0000 Message-ID: <871tl315el.fsf@violet.siamics.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: ger.gmane.org 1425592237 15273 80.91.229.3 (5 Mar 2015 21:50:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Mar 2015 21:50:37 +0000 (UTC) To: 20011@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Mar 05 22:50:24 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YTdex-0006Gc-BI for geb-bug-gnu-emacs@m.gmane.org; Thu, 05 Mar 2015 22:50:23 +0100 Original-Received: from localhost ([::1]:55118 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTdew-0003pr-Kk for geb-bug-gnu-emacs@m.gmane.org; Thu, 05 Mar 2015 16:50:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56234) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTdeh-0003Zv-RW for bug-gnu-emacs@gnu.org; Thu, 05 Mar 2015 16:50:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YTded-00015N-Va for bug-gnu-emacs@gnu.org; Thu, 05 Mar 2015 16:50:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:37927) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTdec-00014V-IP for bug-gnu-emacs@gnu.org; Thu, 05 Mar 2015 16:50:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YTdec-0000Vl-3m for bug-gnu-emacs@gnu.org; Thu, 05 Mar 2015 16:50:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Ivan Shmakov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Mar 2015 21:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 20011 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch X-Debbugs-Original-To: submit@debbugs.gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.14255921791926 (code B ref -1); Thu, 05 Mar 2015 21:50:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 5 Mar 2015 21:49:39 +0000 Original-Received: from localhost ([127.0.0.1]:36495 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YTdeD-0000Uy-EF for submit@debbugs.gnu.org; Thu, 05 Mar 2015 16:49:39 -0500 Original-Received: from fely.am-1.org ([78.47.74.50]:58121) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YTde8-0000Ul-SD for submit@debbugs.gnu.org; Thu, 05 Mar 2015 16:49:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=siamics.net; s=a2013295; h=Content-Type:MIME-Version:Message-ID:Date:Sender:Subject:To:From; bh=xwrYi8eC6XrXCaFmfkGaF4k1RlbsvQ8xwsHDb99X0m8=; b=ob+opqs4HUTZ7iMstt3I5+mUJ8iVSgDIlkVGZdIL4nUzNWvbcOC0JYdllORBd/g/rxObILsqblbX+GlsTLf0BGMzrmwoEYyXWCb8NLsq2el/21me4edOKyB+wkCUF5QAEuvEv3fOXip5V4nW7BF9vTMxw+keOoGMCxQQm4FhuVM=; Original-Received: from [2a02:2560:6d4:26ca::1:1d] (helo=violet.siamics.net) by fely.am-1.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YTde5-00048i-Nj for submit@debbugs.gnu.org; Thu, 05 Mar 2015 21:49:30 +0000 Original-Received: from localhost ([::1] helo=violet.siamics.net) by violet.siamics.net with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YTddy-0006iv-QT for submit@debbugs.gnu.org; Fri, 06 Mar 2015 04:49:22 +0700 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:100115 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Package: emacs Severity: wishlist Tags: patch Please consider the patch MIMEd. * etc/PROBLEMS: Use 'which' where appropriate (was: 'that'); mention visible-cursor; a few more mentions of ~/.Xresources and xrdb(1); refer to 'GNU Coreutils' and 'X Window' (were: 'GNU Fileutils' and 'X Windows', respectively); other similar fixes and updates. (The patch is against 619fc5c197eb, 2015-02-26 18:09:48 UTC.) --=20 FSF associate member #7257 http://boycottsystemd.org/ =E2=80=A6 3013 B6A0= 230E 334A --=-=-= Content-Type: text/diff Content-Disposition: inline --- a/etc/PROBLEMS +++ b/etc/PROBLEMS @@ -5,10 +5,10 @@ See the end of the file for license conditions. -This file describes various problems that have been encountered +This file describes various problems which have been encountered in compiling, installing and running GNU Emacs. Try doing C-c C-t and browsing through the outline headers. (See C-h m for help on -Outline mode.) Information about systems that are no longer supported, +Outline mode.) Information about systems which are no longer supported, and old Emacs releases, has been removed. Consult older versions of this file if you are interested in that information. @@ -27,6 +27,9 @@ This happens because some X resource specifies a bad font family for Emacs to use. The possible places where this specification might be are: + - in the X server resources database, often initialized from + ~/.Xresources (use $ xrdb -query to find out the current state) + - in your ~/.Xdefaults file - client-side X resource file, such as ~/Emacs or @@ -36,6 +39,12 @@ fontset that Emacs should use. To fix the problem, you need to find the problematic line(s) and correct them. +After correcting ~/.Xresources, the new data has to be merged into the +X server resources database. Depending on the circumstances, the +following command may do the trick. See xrdb(1) for more information. + + $ xrdb -merge ~/.Xresources + ** Emacs aborts while starting up, only when run without X. This problem often results from compiling Emacs with GCC when GCC was @@ -96,7 +105,7 @@ x-complement-fontset-spec: "Wrong type argument: stringp, nil" This can be another symptom of stale *.elc files in your load-path. -The following command will print any duplicate Lisp files that are +The following command will print any duplicate Lisp files which are present in load-path: emacs -batch -f list-load-path-shadows @@ -168,7 +177,7 @@ ** Emacs aborts inside the function `tparam1'. This can happen if Emacs was built without terminfo support, but the -terminal's capabilities use format that is only supported by terminfo. +terminal's capabilities use format which is only supported by terminfo. If your system has ncurses installed, this might happen if your version of ncurses is broken; upgrading to a newer version of ncurses and reconfiguring and rebuilding Emacs should solve this. @@ -197,12 +206,12 @@ ** When Emacs is compiled with Gtk+, closing a display kills Emacs. -There is a long-standing bug in GTK that prevents it from recovering +There is a long-standing bug in GTK which prevents it from recovering from disconnects: http://bugzilla.gnome.org/show_bug.cgi?id=85715. Thus, for instance, when Emacs is run as a server on a text terminal, and an X frame is created, and the X server for that frame crashes or -exits unexpectedly, Emacs must exit to prevent a GTK error that would +exits unexpectedly, Emacs must exit to prevent a GTK error which would result in an endless loop. If you need Emacs to be able to recover from closing displays, compile @@ -236,7 +245,7 @@ OpenMPI and Emacs with libotf support. The best you can do is use a wrapper shell script (or function) "emacs" that removes the offending element from LD_LIBRARY_PATH before starting emacs proper. -Or you could recompile Emacs with an -Wl,-rpath option that +Or you could recompile Emacs with a -Wl,-rpath option that gives the location of the correct libotf. * General runtime problems @@ -248,7 +257,7 @@ You may have forgotten to recompile them into .elc files. Then the old .elc files will be loaded, and your changes will not be seen. To fix this, do M-x byte-recompile-directory -and specify the directory that contains the Lisp files. +and specify the directory which contains the Lisp files. Emacs prints a warning when loading a .elc file which is older than the corresponding .el file. @@ -271,8 +280,8 @@ This happens because epop3 redefines the function gethash, which is a built-in primitive beginning with Emacs 21.1. We don't have a patch -for epop3 that fixes this, but perhaps a newer version of epop3 -corrects that. +for epop3 to fix this, but perhaps a newer version of epop3 corrects +that. *** Buffers from `with-output-to-temp-buffer' get set up in Help mode. @@ -411,7 +420,7 @@ *** Editing files with very long lines is slow. -For example, simply moving through a file that contains hundreds of +For example, simply moving through a file which contains hundreds of thousands of characters per line is slow, and consumes a lot of CPU. This is a known limitation of Emacs with no solution at this time. @@ -431,9 +440,10 @@ *** Programs running under terminal emulator do not recognize `emacs' terminal type. -The cause of this is a shell startup file that sets the TERMCAP +The cause of this is a shell startup file which sets the TERMCAP environment variable. The terminal emulator uses that variable to -provide the information on the special terminal type that Emacs emulates. +provide the information on the special terminal type which Emacs +emulates. Rewrite your shell startup file so that it does not change TERMCAP in such a case. You could use the following conditional which sets @@ -476,7 +486,7 @@ This could happen if invocation of the `df' program takes a long time. Possible reasons for this include: - - ClearCase mounted filesystems (VOBs) that sometimes make `df' + - ClearCase mounted filesystems (VOBs) which sometimes make `df' response time extremely slow (dozens of seconds); - slow automounters on some old versions of Unix; @@ -485,7 +495,7 @@ To work around the problem, you could either (a) set the variable `directory-free-space-program' to nil, and thus prevent Emacs from -invoking `df'; (b) use `df' from the GNU Fileutils package; or +invoking `df'; (b) use `df' from the GNU Coreutils package; or (c) use CVS, which is Free Software, instead of ClearCase. *** ps-print commands fail to find prologue files ps-prin*.ps. @@ -559,7 +569,7 @@ version of Ispell installed on your machine is old. Upgrade. Yet another possibility is that you are trying to spell-check a word -in a language that doesn't fit the dictionary you choose for use by +in a language which doesn't fit the dictionary you choose for use by Ispell. (Ispell can only spell-check one language at a time, because it uses a single dictionary.) Make sure that the text you are spelling and the dictionary used by Ispell conform to each other. @@ -577,8 +587,8 @@ For example, XFree86 4.3.0 has one version and Gnome usually comes with a newer version. Emacs compiled with Gtk+ will then use the newer version. In most cases the problem can be temporarily fixed by -stopping the application that has the error (it can be Emacs or any -other application), removing ~/.fonts.cache-1, and then start the +stopping the application which has the error (it can be Emacs or any +other application), removing ~/.fonts.cache-1, and then starting the application again. If removing ~/.fonts.cache-1 and restarting doesn't help, the application with problem must be recompiled with the same version of FontConfig as the rest of the system uses. For KDE, @@ -597,10 +607,10 @@ many different fonts, collected into a fontset. You can remedy the problem by installing additional fonts. -The intlfonts distribution includes a full spectrum of fonts that can +The intlfonts distribution includes a full spectrum of fonts which can display all the characters Emacs supports. The etl-unicode collection of fonts (available from ) includes -fonts that can display many Unicode characters; they can also be used +fonts which can display many Unicode characters; they can also be used by ps-print and ps-mule to print Unicode characters. ** Under X, some characters appear improperly aligned in their lines. @@ -678,7 +688,7 @@ ** Underlines appear at the wrong position. This is caused by fonts having a wrong UNDERLINE_POSITION property. -Examples are the font 7x13 on XFree prior to version 4.1, or the jmk +Examples are the 7x13 font on XFree86 prior to version 4.1, or the jmk neep font from the Debian xfonts-jmk package prior to version 3.0.17. To circumvent this problem, set x-use-underline-position-properties to nil in your `.emacs'. @@ -759,7 +769,7 @@ Try other font set sizes (S-mouse-1). If the problem persists with other sizes as well, your text is corrupted, probably through software -that is not 8-bit clean. If the problem goes away with another font +which is not 8-bit clean. If the problem goes away with another font size, it's probably because some fonts pretend to be ISO-8859-1 fonts when they are really ASCII fonts. In particular the schumacher-clean fonts have this bug in some versions of X. @@ -801,7 +811,7 @@ Compose, you can make the remapping happen automatically by adding the xmodmap command to the xdm setup script for that display. -*** Using X Windows, control-shift-leftbutton makes Emacs hang. +*** Using X Window, control-shift-leftbutton makes Emacs hang. Use the shell command `xset bc' to make the old X Menu package work. @@ -876,9 +886,10 @@ it read. If it says it read an Alt-modified key, then make sure you have made the key binding correctly. -If C-h c reports an event that doesn't have the Alt modifier, it may +If C-h c reports an event which doesn't have the Alt modifier, it may be because your X server has no key for the Alt modifier. The X -server that comes from MIT does not set up the Alt modifier by default. +server which comes from MIT does not set up the Alt modifier by +default. If your keyboard has keys named Alt, you can enable them as follows: @@ -965,8 +976,8 @@ Timed out waiting for property-notify event -A workaround is to not use `klipper'. An upgrade to the `klipper' that -comes with KDE 3.3 or later also solves the problem. +A workaround is to not use `klipper'. An upgrade to the `klipper' +which comes with KDE 3.3 or later also solves the problem. *** CDE: Frames may cover dialogs they created when using CDE. @@ -1091,8 +1102,8 @@ (menu-bar-mode -1) (tool-bar-mode -1) - For still quicker startup, put these X resources in your .Xdefaults - file: + For still quicker startup, put these X resources in your + .Xresources or .Xdefaults file: Emacs.verticalScrollBars: off Emacs.menuBar: off @@ -1111,7 +1122,7 @@ -noatomsfile -nowinattr -cheaterrors -cheatevents Note that the -nograbcmap option is known to cause problems. For more about lbxproxy, see: - http://www.xfree86.org/4.3.0/lbxproxy.1.html + http://www.x.org/archive/X11R6.8.0/doc/lbxproxy.1.html 5) If copying and killing is slow, try to disable the interaction with the native system's clipboard by adding these lines to your .emacs file: @@ -1179,17 +1190,17 @@ -query' to see what resources the X server records, and also look at the user's ~/.Xdefaults and ~/.Xdefaults-* files. -*** Emacs running under X Windows does not handle mouse clicks. +*** Emacs running under X Window does not handle mouse clicks. *** `emacs -geometry 80x20' finds a file named `80x20'. One cause of such problems is having (setq term-file-prefix nil) in your .emacs file. Another cause is a bad value of EMACSLOADPATH in the environment. -*** X Windows doesn't work if DISPLAY uses a hostname. +*** X Window doesn't work if DISPLAY uses a hostname. People have reported kernel bugs in certain systems that cause Emacs -not to work with X Windows if DISPLAY is set using a host name. But +not to work with X Window if DISPLAY is set using a host name. But the problem does not occur if DISPLAY is set to `unix:0.0'. I think the bug has to do with SIGIO or FIONREAD. @@ -1244,7 +1255,7 @@ appmenu concept. It tries to track Emacs menus and show them in the top panel, instead of in each Emacs window. This is not properly implemented, so it fails for Emacs. The order of menus is wrong, and things like copy/paste -that depend on what state Emacs is in are usually wrong (i.e. paste disabled +which depend on what state Emacs is in are usually wrong (i.e. paste disabled even if you should be able to paste, and similar). You can get back menus on each frame by starting emacs like this: @@ -1256,13 +1267,13 @@ Typing M-x rings the terminal bell, and inserts a string like ";120~". For recent xterm versions (>= 216), Emacs uses xterm's modifyOtherKeys -feature to generate strings for key combinations that are not +feature to generate strings for key combinations which are not otherwise usable. One circumstance in which this can cause problems is if you have specified the X resource xterm*VT100.Translations -to contain translations that use the meta key. Then xterm will not +to contain translations which use the meta key. Then xterm will not use meta in modified function-keys, which confuses Emacs. To fix this, you can remove the X resource or put this in your init file: @@ -1289,7 +1300,7 @@ they generate XON/XOFF flow control characters. This must be set to "no XON/XOFF" in order for Emacs to work. (For example, on a VT220 you may select "No XOFF" in the setup menu.) Sometimes there is an -escape sequence that the computer can send to turn flow control off +escape sequence which the computer can send to turn flow control off and on. If so, perhaps the termcap `ti' string should turn flow control off, and the `te' string should turn it on. @@ -1303,7 +1314,7 @@ problem in the termcap entry. You must speak to a local Unix wizard to fix this. Perhaps you are just using the wrong terminal type. -For terminals that lack a "no flow control" mode, sometimes just +For terminals which lack a "no flow control" mode, sometimes just giving lots of padding will prevent actual generation of flow control codes. You might as well try it. @@ -1346,7 +1357,7 @@ I have no intention of ever redesigning the Emacs command set for the assumption that terminals use C-s/C-q flow control. XON/XOFF flow -control technique is a bad design, and terminals that need it are bad +control technique is a bad design, and terminals which need it are bad merchandise and should not be purchased. Now that X is becoming widespread, XON/XOFF seems to be on the way out. If you can get some use out of GNU Emacs on inferior terminals, more power to you, but I @@ -1358,7 +1369,7 @@ For some reason, your system is using brain-damaged C-s/C-q flow control despite Emacs's attempts to turn it off. Perhaps your terminal is connected to the computer through a concentrator -that wants to use flow control. +which wants to use flow control. You should first try to tell the concentrator not to use flow control. If you succeed in this, try making the terminal work without @@ -1371,7 +1382,7 @@ ** Screen is updated wrong, but only on one kind of terminal. This could mean that the termcap entry you are using for that -terminal is wrong, or it could mean that Emacs has a bug handing +terminal is wrong, or it could mean that Emacs has a bug handling the combination of features specified for that terminal. The first step in tracking this down is to record what characters @@ -1392,15 +1403,15 @@ This case is hard. It will be necessary to think of a way for Emacs to distinguish between terminals with this kind of behavior -and other terminals that behave subtly differently but are +and other terminals which behave subtly differently but are classified the same by termcap; or else find an algorithm for -Emacs to use that avoids the difference. Such changes must be +Emacs to use which avoids the difference. Such changes must be tested on many kinds of terminals. 3) The termcap entry is wrong. See the file etc/TERMS for information on changes -that are known to be needed in commonly used termcap entries +which are known to be needed in commonly used termcap entries for certain terminals. 4) The characters sent are incorrect, and clearly cannot be @@ -1529,14 +1540,14 @@ Emacs uses the database entry for the terminal whose name is the value of the environment variable TERM. With `xterm', a common terminal -entry that supports color is `xterm-color', so setting TERM's value to +entry which supports color is `xterm-color', so setting TERM's value to `xterm-color' might activate the color support on an xterm-compatible emulator. Beginning with version 22.1, Emacs supports the --color command-line option which may be used to force Emacs to use one of a few popular modes for getting colors on a tty. For example, --color=ansi8 sets up -for using the ANSI-standard escape sequences that support 8 colors. +for using the ANSI-standard escape sequences which support 8 colors. Some modes do not use colors unless you turn on the Font-lock mode. Some people have long ago set their `~/.emacs' files to turn on @@ -1568,7 +1579,7 @@ *** GNU/Linux: Process output is corrupted. -There is a bug in Linux kernel 2.6.10 PTYs that can cause emacs to +There is a bug in Linux kernel 2.6.10 PTYs which can cause emacs to read corrupted process output. *** GNU/Linux: Remote access to CVS with SSH causes file corruption. @@ -1590,7 +1601,7 @@ The symptoms are: you are accessing a svn repository over SSH. You use vc-annotate on a large (several thousand line) file, and the result is truncated around the 1000 line mark. It works fine with -other access methods (eg http), or from outside Emacs. +other access methods (e.g. http), or from outside Emacs. This may be a similar libc/SSH issue to the one mentioned above for CVS. A similar workaround seems to be effective: create a script with the @@ -1692,7 +1703,8 @@ produce a modified terminfo entry. Alternatively, if you want a blinking underscore as your Emacs cursor, -change the "cvvis" capability to send the "\E[?25h\E[?0c" command. +set the `visible-cursor' variable to nil in your ~/.emacs: + (setq visible-cursor nil) ** FreeBSD @@ -1721,7 +1733,7 @@ christos@theory.tn.cornell.edu says: -The problem is that in your .cshrc you have something that tries to +The problem is that in your .cshrc you have something which tries to execute `tty`. If you are not running the shell on a real tty then tty will print "not a tty". Csh expects one word in some places, but tty is giving it back 3. @@ -1735,7 +1747,7 @@ if ("`tty`" == "/dev/console") -Even better, move things that set up terminal sections out of .cshrc +Even better, move things which set up terminal sections out of .cshrc and into .login. *** HP/UX: `Pid xxx killed due to text modification or page I/O error'. @@ -1880,11 +1892,11 @@ /usr/openwin/lib/locale/iso8859-15/Compose -Near the bottom there is a line that reads: +Near the bottom there is a line which reads: Ctrl : "\276" threequarters -that should read: +while it should read: Ctrl : "\276" threequarters @@ -1892,7 +1904,7 @@ *** On Solaris, Emacs fails to set menu-bar-update-hook on startup, with error "Error in menu-bar-update-hook: (error Point before start of properties)". -This seems to be a GCC optimization bug that occurs for GCC 4.1.2 (-g +This seems to be a GCC optimization bug which occurs for GCC 4.1.2 (-g and -g -O2) and GCC 4.2.3 (-g -O and -g -O2). You can fix this by compiling with GCC 4.2.3 or CC 5.7, with no optimizations. @@ -1959,7 +1971,7 @@ after Emacs has started. One solution for this problem is to find an alternative build of the -same optional library that does not depend on the libgcc DLL. +same optional library which does not depend on the libgcc DLL. Another possibility is to rebuild Emacs with the -shared-libgcc switch, which will force Emacs to load libgcc_s_dw2-1.dll on startup, @@ -1968,7 +1980,7 @@ ** File selection dialog opens in incorrect directories Invoking the file selection dialog on Windows 7 or later shows a -directory that is different from what was passed to `read-file-name' +directory which is different from what was passed to `read-file-name' or `x-file-dialog' via their arguments. This is due to a deliberate change in behavior of the file selection @@ -2021,13 +2033,13 @@ Loading rails-mode seems to interfere with UNC path handling. This has been reported as a bug against both Emacs and rails-mode, so look for an updated -rails-mode that avoids this crash, or avoid using UNC paths if using +rails-mode which avoids this crash, or avoid using UNC paths if using rails-mode. ** M-x term does not work on MS-Windows. TTY emulation on Windows is undocumented, and programs such as stty -which are used on posix platforms to control tty emulation do not +which are used on POSIX platforms to control tty emulation do not exist for native windows terminals. ** Using create-fontset-from-ascii-font or the --font startup parameter @@ -2040,7 +2052,7 @@ This means no redisplay while the File or Font dialog or a pop-up menu is displayed. This also means tooltips with help text for pop-up -menus is not displayed at all (except in a TTY session, where the help +menus are not displayed at all (except in a TTY session, where the help text is shown in the echo area). This is because message handling under Windows is synchronous, so we cannot handle repaint (or any other) messages while waiting for a system function, which popped up @@ -2095,7 +2107,7 @@ the Advanced tab of Regional Settings) to the language of the input method. -To bind keys that produce non-ASCII characters with modifiers, you +To bind keys which produce non-ASCII characters with modifiers, you must specify raw byte codes. For instance, if you want to bind META-a-grave to a command, you need to specify this in your `~/.emacs': @@ -2122,8 +2134,8 @@ Files larger than 4GB cause overflow in the size (represented as a 32-bit integer) reported by `file-attributes'. This affects Dired as -well, since the Windows port uses a Lisp emulation of `ls' that relies -on `file-attributes'. +well, since the Windows port uses a Lisp emulation of `ls' which +relies on `file-attributes'. ** Playing sound doesn't support the :data method @@ -2138,7 +2150,7 @@ more permanent work around is to change it to another key combination, or disable it in the "Regional and Language Options" applet of the Control Panel. (The exact sequence of mouse clicks in the "Regional -and Language Options" applet needed to find the key combination that +and Language Options" applet needed to find the key combination which changes the keyboard layout depends on your Windows version; for XP, in the Languages tab, click "Details" and then "Key Settings".) @@ -2260,8 +2272,8 @@ *** `configure' warns ``accepted by the compiler, rejected by the preprocessor''. -This indicates a mismatch between the C compiler and preprocessor that -configure is using. For example, on Solaris 10 trying to use +This indicates a mismatch between the C compiler and preprocessor +which configure is using. For example, on Solaris 10 trying to use CC=/opt/SUNWspro/bin/cc (the Sun Studio compiler) together with CPP=/usr/ccs/lib/cpp can result in errors of this form (you may also see the error ``"/usr/include/sys/isa_defs.h", line 500: undefined control''). @@ -2310,7 +2322,7 @@ marvin:/usr/local/src /usr/local/src ...options.omitted... -The solution is to remove this line from `etc/fstab'. +The solution is to remove this line from `/etc/fstab'. *** Building a 32-bit executable on a 64-bit GNU/Linux architecture. @@ -2341,7 +2353,7 @@ oo-spd/i386/ctags.o:ctags.c:(.text+0x156e): undefined reference to `_imp__re_set_syntax' collect2: ld returned 1 exit status -This happens because GCC finds an incompatible header regex.h +This happens because GCC finds an incompatible regex.h header somewhere on the include path, before the version of regex.h supplied with Emacs. One such incompatible version of regex.h is part of the GnuWin32 Regex package. @@ -2399,7 +2411,7 @@ Microsoft no longer ships the single threaded version of the C library with their compiler, and the multithreaded static library is missing -some functions that Microsoft have deemed non-threadsafe. The +some functions which Microsoft have deemed non-threadsafe. The dynamically linked C library has all the functions, but there is a conflict between the versions of malloc in the DLL and in Emacs, which is not resolvable due to the way Windows does dynamic linking. @@ -2488,7 +2500,7 @@ "No rule to make target `/path/to/some/lisp.elc'". The causes of this problem are not understood. Using GNU make 3.81 compiled from source, rather than the Ubuntu version, worked. -See . +See , . ** Dumping @@ -2552,7 +2564,7 @@ site-init.el or site-load.el file, consider deleting that file. 4) getting the wrong .el or .elc files (not from the directory you expected). - 5) deleting some .elc files that are supposed to exist. + 5) deleting some .elc files which are supposed to exist. This would cause the source files (.el files) to be loaded instead. They take up more room, so you lose. 6) a bug in the Emacs distribution which underestimates the space required. @@ -2561,7 +2573,8 @@ of PURESIZE in puresize.h. But in some of the cases listed above, this problem is a consequence -of something else that is wrong. Be sure to check and fix the real problem. +of something else which is wrong. Be sure to check and fix the real +problem. *** OpenBSD 4.0 macppc: Segfault during dumping. @@ -2596,7 +2609,7 @@ On a system where getpagesize is not a system call, it is defined as a macro. If the definition (in both unex*.c and malloc.c) is wrong, it can cause problems like this. You might be able to find the correct -value in the man page for a.out (5). +value in the man page for a.out(5). * Problems on legacy systems @@ -2620,7 +2633,7 @@ **** On Solaris, Emacs crashes if you use (display-time). This can happen if you configure Emacs without specifying the precise -version of Solaris that you are using. +version of Solaris which you are using. **** Solaris 2.x: GCC complains "64 bit integer types not supported". @@ -2660,7 +2673,7 @@ support complains to Sun about the bug, they may release a patch. If you do this, mention Sun bug #4188711. -One workaround is to use a locale that allows non-ASCII characters. +One workaround is to use a locale which allows non-ASCII characters. For example, before invoking emacs, set the LC_ALL environment variable to "en_US" (American English). The directory /usr/lib/locale lists the supported locales; any locale other than "C" or "POSIX" @@ -2758,7 +2771,7 @@ *** When compiling with DJGPP on MS-Windows NT or later, "config msdos" fails. If the error message is "VDM has been already loaded", this is because -Windows has a program called `redir.exe' that is incompatible with a +Windows has a program called `redir.exe' which is incompatible with a program by the same name supplied with DJGPP, which is used by config.bat. To resolve this, move the DJGPP's `bin' subdirectory to the front of your PATH environment variable. @@ -2806,7 +2819,7 @@ This can happen if you define an environment variable `TERM'. Emacs on MSDOS uses an internal terminal emulator which is disabled if the value of `TERM' is anything but the string "internal". Emacs then -works as if its terminal were a dumb glass teletype that doesn't +works as if its terminal were a dumb glass teletype which doesn't support faces. To work around this, arrange for `TERM' to be undefined when Emacs runs. The best way to do that is to add an [emacs] section to the DJGPP.ENV file which defines an empty value for @@ -2853,16 +2866,16 @@ This can happen if the Emacs distribution was unzipped without LFN support, thus causing long filenames to be truncated to the first 6 -characters and a numeric tail that Windows 95 normally attaches to it. -You should unzip the files again with a utility that supports long -filenames (such as djtar from DJGPP or InfoZip's UnZip program +characters and a numeric tail which Windows 95 normally attaches to +it. You should unzip the files again with a utility which supports +long filenames (such as djtar from DJGPP or InfoZip's UnZip program compiled with DJGPP v2). The file msdos/INSTALL explains this issue in more detail. Another possible reason for such failures is that Emacs compiled for MSDOS is used on Windows NT, where long file names are not supported by this version of Emacs, but the distribution was unpacked by an -unzip program that preserved the long file names instead of truncating +unzip program which preserved the long file names instead of truncating them to DOS 8+3 limits. To be useful on NT, the MSDOS port of Emacs must be unzipped by a DOS utility, so that long file names are properly truncated. --=-=-=--