[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#20011: etc/PROBLEMS: updates, wording, typos
bug#20011: etc/PROBLEMS: updates, wording, typos
Thu, 05 Mar 2015 21:49:22 +0000
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
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.)
FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A
@@ -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
+for epop3 to fix this, but perhaps a newer version of epop3 corrects
*** 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'
-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
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 <URL:ftp://ftp.x.org/contrib/fonts/>) 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
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 @@
- For still quicker startup, put these X resources in your .Xdefaults
+ For still quicker startup, put these X resources in your
+ .Xresources or .Xdefaults file:
@@ -1111,7 +1122,7 @@
-noatomsfile -nowinattr -cheaterrors -cheatevents
Note that the -nograbcmap option is known to cause problems.
For more about lbxproxy, see:
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
-*** 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
-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
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)
@@ -1721,7 +1733,7 @@
-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 @@
-Near the bottom there is a line that reads:
+Near the bottom there is a line which reads:
Ctrl<t> <quotedbl> <Y> : "\276" threequarters
-that should read:
+while it should read:
Ctrl<T> <quotedbl> <Y> : "\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
** 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
-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
+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
-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
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 <URL:http://debbugs.gnu.org/327, <URL:http://debbugs.gnu.org/821>.
+See <URL:http://debbugs.gnu.org/327>, <URL:http://debbugs.gnu.org/821>.
@@ -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
*** 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
- bug#20011: etc/PROBLEMS: updates, wording, typos,
Ivan Shmakov <=