bug#20011: etc/PROBLEMS: updates, wording, typos

bug#20011: etc/PROBLEMS: updates, wording, typos

[Ivan Shmakov]

[-- Attachment #1: Type: text/plain, Size: 516 bytes --]

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.)

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/diff, Size: 29283 bytes --]

--- 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 <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
+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<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
 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 <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>.
 
 ** 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.

bug#20011: etc/PROBLEMS: updates, wording, typos

[Eli Zaretskii]

> From: Ivan Shmakov <ivan@siamics.net>
> Date: Thu, 05 Mar 2015 21:49:22 +0000
> 
> 	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.

There's nothing wrong with using "that" in these contexts, it's pretty
standard English usage, and we use it all over the place in the Emacs
documentation.

So please submit a patch without those parts.

Also, "X Window" is incorrect; use "X Window system" or just "X"
instead.

This part:

>  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)

replaces a recipe with an entirely different one.  Why not keep both?

Thanks.

bug#20011: etc/PROBLEMS: updates, wording, typos

[Ivan Shmakov]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>> From: Ivan Shmakov  Date: Thu, 05 Mar 2015 21:49:22 +0000

 >> 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.

 > There's nothing wrong with using "that" in these contexts,

	AIUI, there’s nothing wrong with using “which” there, either.

 > it's pretty standard English usage, and we use it all over the place
 > in the Emacs documentation.

	Personally, I find “that” sentences somewhat harder to read
	/in general./  I still hope someone with English skills better
	than mine could re-check these cases and apply the changes
	suggested where sensible.

 > So please submit a patch without those parts.

	ACK.

 > Also, "X Window" is incorrect; use "X Window system" or just "X"
 > instead.

	Indeed, I stand corrected.  (Though it’s X Window /S/ystem.)

 > This part:

 >>  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)

 > replaces a recipe with an entirely different one.  Why not keep both?

	The former recipe seems to predate the introduction of
	visible-cursor.  I see no reason to keep it now that there’s an
	easy way to solve the issue without having to modify terminfo or
	restart Emacs, etc.  I presume that the more experienced users
	will be able to gather all what necessary for a terminfo-based
	solution from the “use software cursor” recipe just above the
	one at hand.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

bug#20011: etc/PROBLEMS: updates, wording, typos

[Eli Zaretskii]

> From: Ivan Shmakov <ivan@siamics.net>
> Date: Fri, 06 Mar 2015 09:10:54 +0000
> 
> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
> >>>>> From: Ivan Shmakov  Date: Thu, 05 Mar 2015 21:49:22 +0000
> 
>  >> 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.
> 
>  > There's nothing wrong with using "that" in these contexts,
> 
> 	AIUI, there’s nothing wrong with using “which” there, either.

Indeed, there isn't.  But making such changes in a single document on
top of that, leaving all the other uses intact, hardly makes sense.
It could make sense if we agreed not to use "that" in these cases, and
then changed that all over and wrote somewhere in the docs that this
is our style.  But not in a single file.

>  >>  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)
> 
>  > replaces a recipe with an entirely different one.  Why not keep both?
> 
> 	The former recipe seems to predate the introduction of
> 	visible-cursor.  I see no reason to keep it now that there’s an
> 	easy way to solve the issue without having to modify terminfo or
> 	restart Emacs, etc.  I presume that the more experienced users
> 	will be able to gather all what necessary for a terminfo-based
> 	solution from the “use software cursor” recipe just above the
> 	one at hand.

I don't know enough about this to judge, so I will defer to others.
(I generally prefer to keep existing knowledge intact, even if it's
old, as long as it's correct; but that's me.)

Thanks.

bug#20011: etc/PROBLEMS: updates, wording, typos

[Glenn Morris]

Ivan Shmakov wrote:

> 	AIUI, there's nothing wrong with using "which" there, either.

I disagree. Eg
http://blog.apastyle.org/apastyle/2012/01/that-versus-which.html

bug#20011: etc/PROBLEMS: updates, wording, typos

[Ivan Shmakov]

[-- Attachment #1: Type: text/plain, Size: 1573 bytes --]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>> From: Ivan Shmakov  Date: Fri, 06 Mar 2015 09:10:54 +0000
>>>>> Eli Zaretskii <eliz@gnu.org> writes:

[…]

 >>> There's nothing wrong with using "that" in these contexts,

 >> AIUI, there’s nothing wrong with using “which” there, either.

 > Indeed, there isn't.  But making such changes in a single document on
 > top of that, leaving all the other uses intact, hardly makes sense.
 > It could make sense if we agreed not to use "that" in these cases,
 > and then changed that all over and wrote somewhere in the docs that
 > this is our style.  But not in a single file.

	I’ve mostly dropped these changes, or (in three cases) reworded
	to avoid either.

 >>> replaces a recipe with an entirely different one.  Why not keep
 >>> both?

 >> The former recipe seems to predate the introduction of
 >> visible-cursor.  I see no reason to keep it now that there’s an easy
 >> way to solve the issue without having to modify terminfo or restart
 >> Emacs, etc.  I presume that the more experienced users will be able
 >> to gather all what necessary for a terminfo-based solution from the
 >> “use software cursor” recipe just above the one at hand.

 > I don't know enough about this to judge, so I will defer to others.
 > (I generally prefer to keep existing knowledge intact, even if it's
 > old, as long as it's correct; but that's me.)

	Done.

	Please consider the revised patch MIMEd.

-- 
FSF associate member #7257  np. A World Behind the World — Jami Sieber

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/diff, Size: 10792 bytes --]

--- a/etc/PROBLEMS
+++ b/etc/PROBLEMS
@@ -26,6 +26,9 @@ ** Emacs fails to start, complaining about missing fonts.
 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
@@ -35,6 +38,12 @@ ** Emacs fails to start, complaining about missing fonts.
 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
@@ -270,8 +279,7 @@ *** Using epop3.el package causes Emacs to signal an error.
 
 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 it, but perhaps a newer version of epop3 corrects that.
 
 *** Buffers from `with-output-to-temp-buffer' get set up in Help mode.
 
@@ -507,7 +515,7 @@ *** Dired is very slow.
 
 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.
@@ -600,7 +608,7 @@ *** This can occur when two different versions of FontConfig are used.
 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
+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,
@@ -700,7 +708,7 @@ ** Emacs pauses for several seconds when changing the default font.
 ** 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'.
@@ -823,7 +831,7 @@ *** You "lose characters" after typing Compose Character key.
 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 System, control-shift-leftbutton makes Emacs hang.
 
 Use the shell command `xset bc' to make the old X Menu package work.
 
@@ -987,8 +995,8 @@ *** KDE: Emacs hangs on KDE when a large portion of text is killed.
 
   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'.  Upgrading `klipper' to the one
+coming with KDE 3.3 or later also solves the problem.
 
 *** CDE: Frames may cover dialogs they created when using CDE.
 
@@ -1113,8 +1121,8 @@ *** Improving performance with slow X connections.
     (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
@@ -1133,7 +1141,7 @@ *** Improving performance with slow X connections.
     -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:
@@ -1201,17 +1209,17 @@ *** Pull-down menus appear in the wrong place, in the toolkit version of Emacs.
 -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 System 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 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 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.
 
@@ -1393,7 +1401,7 @@ ** Control-S and Control-Q commands are ignored completely.
 ** 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
@@ -1612,7 +1620,7 @@ *** GNU/Linux: Truncated svn annotate output with SSH.
 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
@@ -1714,7 +1722,11 @@ *** GNU/Linux: Emacs on a tty switches the cursor to large blinking block.
 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)
+
+Still other way is to change the "cvvis" capability to send the
+"\E[?25h\E[?0c" command.
 
 ** FreeBSD
 
@@ -1906,7 +1918,7 @@ *** On Solaris, CTRL-t is ignored by Emacs when you use
 
         Ctrl<t> <quotedbl> <Y>                  : "\276"        threequarters
 
-that should read:
+while it should read:
 
         Ctrl<T> <quotedbl> <Y>                  : "\276"        threequarters
 
@@ -2049,7 +2061,7 @@ ** Emacs crashes when opening a file with a UNC path and rails-mode is loaded.
 ** 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
@@ -2062,7 +2074,7 @@ ** Frames are not refreshed while dialogs or menus are displayed
 
 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
@@ -2144,7 +2156,7 @@ ** Files larger than 4GB report wrong size in a 32-bit Windows build
 
 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
@@ -2332,7 +2344,7 @@ *** Building Emacs over NFS fails with ``Text file busy''.
 
     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.
 
@@ -2363,7 +2375,7 @@ *** Building the native MS-Windows port fails due to unresolved externals
  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.
@@ -2510,7 +2522,7 @@ *** "No rule to make target" with Ubuntu 8.04 make 3.81-3build1
 "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>.
 
 ** Dumping
 
@@ -2618,7 +2630,7 @@ *** The dumped Emacs crashes when run, trying to write pure data.
 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
 

bug#20011: etc/PROBLEMS: updates, wording, typos

[Ivan Shmakov]

>>>>> Glenn Morris <rgm@gnu.org> writes:
>>>>> Ivan Shmakov wrote:

 >> AIUI, there's nothing wrong with using “which” there, either.

 > I disagree.  Eg
 > http://blog.apastyle.org/apastyle/2012/01/that-versus-which.html

	There, it documents the in-house style.  As for the English at
	large, Wikipedia quotes [1] Merriam-Webster’s (1995) thus:

    […] the facts of usage are quite simple.  Virginia McDavid’s 1977
    study shows that about 75 percent of the instances of /which/ in
    edited prose introduce restrictive clauses; about 25 percent
    nonrestrictive ones.  We conclude that at the end of the 20th
    century, the usage of /which/ and /that/ — at least in prose — has
    settled down.  You can use either /which/ or /that/ to introduce a
    restrictive clause — the grounds for your choice should be stylistic
    — and /which/ to introduce a nonrestrictive clause.

[1] https://en.wikipedia.org/wiki/English_relative_clauses

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

bug#20011: etc/PROBLEMS: updates, wording, typos

[Eli Zaretskii]

> From: Ivan Shmakov <ivan@siamics.net>
> Date: Sat, 04 Apr 2015 20:20:19 +0000
> 
>  >>> There's nothing wrong with using "that" in these contexts,
> 
>  >> AIUI, there’s nothing wrong with using “which” there, either.
> 
>  > Indeed, there isn't.  But making such changes in a single document on
>  > top of that, leaving all the other uses intact, hardly makes sense.
>  > It could make sense if we agreed not to use "that" in these cases,
>  > and then changed that all over and wrote somewhere in the docs that
>  > this is our style.  But not in a single file.
> 
> 	I’ve mostly dropped these changes, or (in three cases) reworded
> 	to avoid either.
> 
>  >>> replaces a recipe with an entirely different one.  Why not keep
>  >>> both?
> 
>  >> The former recipe seems to predate the introduction of
>  >> visible-cursor.  I see no reason to keep it now that there’s an easy
>  >> way to solve the issue without having to modify terminfo or restart
>  >> Emacs, etc.  I presume that the more experienced users will be able
>  >> to gather all what necessary for a terminfo-based solution from the
>  >> “use software cursor” recipe just above the one at hand.
> 
>  > I don't know enough about this to judge, so I will defer to others.
>  > (I generally prefer to keep existing knowledge intact, even if it's
>  > old, as long as it's correct; but that's me.)
> 
> 	Done.
> 
> 	Please consider the revised patch MIMEd.

Looks good to me, thanks.

bug#20011: etc/PROBLEMS: updates, wording, typos

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

It's not wrong to introduce a restrictive clause with "which",
but using "that" could provide the advantage of showing clearly
that the clause is restrictive.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

bug#20011: etc/PROBLEMS: updates, wording, typos

[Ivan Shmakov]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>> From: Ivan Shmakov  Date: Sat, 04 Apr 2015 20:20:19 +0000

[…]

 >> Please consider the revised patch MIMEd.

 > Looks good to me, thanks.

	Pushed, closing.

commit a137ff5025bbfe8aa3cd49814726c4b37ee3311d
CommitDate: 2015-04-07 17:42:28 +0000

    Update etc/PROBLEMS.
    
    * etc/PROBLEMS: Mention visible-cursor; a few more mentions of
    ~/.Xresources and xrdb(1); refer to 'GNU Coreutils' and
    'X Window System' or 'X' (were: 'GNU Fileutils' and 'X Windows',
    respectively); other minor updates and tweaks.  (Bug#20011)

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A