bug#23746: 25.0.95; Doc fixes (grammar, typos, clarification)

bug#23746: 25.0.95; Doc fixes (grammar, typos, clarification)

[Stephen Berman]

In GNU Emacs 25.0.95.1 (x86_64-suse-linux-gnu, GTK+ Version 3.14.15)
 of 2016-06-11 built on rosalinde
Repository revision: 6921f4a5961fb53f8fb24d1a5a3f94266f990f6e

diff --git a/doc/emacs/files.texi b/doc/emacs/files.texi
index 3bbb3cd..fc46ef7 100644
--- a/doc/emacs/files.texi
+++ b/doc/emacs/files.texi
@@ -701,7 +701,7 @@ Customize Save
 can undo it.)  If the value is @code{visit-save}, Emacs adds such
 newlines both on visiting and on saving.  If the value is @code{nil},
 Emacs leaves the end of the file unchanged; any other non-@code{nil}
-value means to asks you whether to add a newline.  The default is
+value means Emacs asks you whether to add a newline.  The default is
 @code{nil}.
 
 @vindex mode-require-final-newline
diff --git a/doc/emacs/frames.texi b/doc/emacs/frames.texi
index a7e709f..7e60062 100644
--- a/doc/emacs/frames.texi
+++ b/doc/emacs/frames.texi
@@ -1011,7 +1011,7 @@ Window Dividers
 
   On graphical displays, you can use @dfn{window dividers} in order to
 separate windows visually.  Window dividers are bars that can be dragged
-with the mouse, thus allowing to easily resize adjacent windows.
+with the mouse, thus allowing you to easily resize adjacent windows.
 
 @findex window-divider-mode
   To toggle the display of window dividers, use the command @kbd{M-x
diff --git a/doc/emacs/misc.texi b/doc/emacs/misc.texi
index 497a4ab..853b978 100644
--- a/doc/emacs/misc.texi
+++ b/doc/emacs/misc.texi
@@ -1885,7 +1885,7 @@ Printing
 @findex lpr-region
 @vindex lpr-switches
 @vindex lpr-commands
-  On most operating system, the above hardcopy commands submit files
+  On most operating systems, the above hardcopy commands submit files
 for printing by calling the @command{lpr} program.  To change the
 printer program, customize the variable @code{lpr-command}.  To
 specify extra switches to give the printer program, customize the list
diff --git a/doc/lispref/compile.texi b/doc/lispref/compile.texi
index c943a6a..f6cd022 100644
--- a/doc/lispref/compile.texi
+++ b/doc/lispref/compile.texi
@@ -438,7 +438,7 @@ Compiler Errors
 messages.
 
   When an error is due to invalid syntax in the program, the byte
-compiler might get confused about the errors' exact location.  One way
+compiler might get confused about the error's exact location.  One way
 to investigate is to switch to the buffer @w{@file{ *Compiler
 Input*}}.  (This buffer name starts with a space, so it does not show
 up in the Buffer Menu.)  This buffer contains the program being
diff --git a/doc/lispref/control.texi b/doc/lispref/control.texi
index 0cdb035..6179500 100644
--- a/doc/lispref/control.texi
+++ b/doc/lispref/control.texi
@@ -289,11 +289,11 @@ Conditionals
 @end example
 
 @menu
-* Pattern matching case statement::
+* Pattern Matching Case Statement::
 @end menu
 
-@node Pattern matching case statement
-@subsection Pattern matching case statement
+@node Pattern Matching Case Statement
+@subsection Pattern Matching Case Statement
 @cindex pcase
 @cindex pattern matching
 
diff --git a/doc/lispref/elisp.texi b/doc/lispref/elisp.texi
index a3bff0b..f9f155e 100644
--- a/doc/lispref/elisp.texi
+++ b/doc/lispref/elisp.texi
@@ -469,7 +469,7 @@ Top
 
 Conditionals
 
-* Pattern matching case statement::  How to use @code{pcase}.
+* Pattern Matching Case Statement::  How to use @code{pcase}.
 
 Nonlocal Exits
 
diff --git a/doc/lispref/keymaps.texi b/doc/lispref/keymaps.texi
index 61ac80c..f5d3811 100644
--- a/doc/lispref/keymaps.texi
+++ b/doc/lispref/keymaps.texi
@@ -1368,7 +1368,7 @@ Changing Key Bindings
   The function @code{substitute-key-definition} scans a keymap for
 keys that have a certain binding and rebinds them with a different
 binding.  Another feature which is cleaner and can often produce the
-same results to remap one command into another (@pxref{Remapping
+same results is to remap one command into another (@pxref{Remapping
 Commands}).
 
 @defun substitute-key-definition olddef newdef keymap &optional oldmap
diff --git a/doc/lispref/loading.texi b/doc/lispref/loading.texi
index d2d38d7..81a1922 100644
--- a/doc/lispref/loading.texi
+++ b/doc/lispref/loading.texi
@@ -848,8 +848,8 @@ Named Features
 associated with @var{feature} are or will be available for other Lisp
 programs.
 
-The direct effect of calling @code{provide} is if not already in
-@var{features} then to add @var{feature} to the front of that list and
+The direct effect of calling @code{provide} is to add @var{feature} to
+the front of @code{features} if it is not already in that list and
 call any @code{eval-after-load} code waiting for it (@pxref{Hooks for
 Loading}).  The argument @var{feature} must be a symbol.
 @code{provide} returns @var{feature}.
diff --git a/doc/lispref/markers.texi b/doc/lispref/markers.texi
index 1c90466..1b4d74f 100644
--- a/doc/lispref/markers.texi
+++ b/doc/lispref/markers.texi
@@ -340,10 +340,10 @@ Marker Insertion Types
 This function reports the current insertion type of @var{marker}.
 @end defun
 
-Most functions that create markers, without an argument allowing to
-specify the insertion type, create them with insertion type
-@code{nil}.  Also, the mark has, by default, insertion type
-@code{nil}.
+All functions that create markers without accepting an argument that
+specifies the insertion type, create them with insertion type
+@code{nil} (@pxref{Creating Markers}).  Also, the mark has, by
+default, insertion type @code{nil}.
 
 @node Moving Markers
 @section Moving Marker Positions
diff --git a/doc/lispref/modes.texi b/doc/lispref/modes.texi
index ae79128..4c96e63 100644
--- a/doc/lispref/modes.texi
+++ b/doc/lispref/modes.texi
@@ -899,7 +899,7 @@ Mode Hooks
 or fail to run @code{after-change-major-mode-hook}.  If you encounter
 such a major mode, please correct it to follow these conventions.
 
-  When you defined a major mode using @code{define-derived-mode}, it
+  When you define a major mode using @code{define-derived-mode}, it
 automatically makes sure these conventions are followed.  If you
 define a major mode ``by hand'', not using @code{define-derived-mode},
 use the following functions to handle these conventions automatically.
@@ -1048,7 +1048,7 @@ Tabulated List Mode
 @defun tabulated-list-init-header
 This function computes and sets @code{header-line-format} for the
 Tabulated List buffer (@pxref{Header Lines}), and assigns a keymap to
-the header line to allow sort entries by clicking on column headers.
+the header line to allow sorting entries by clicking on column headers.
 
 Modes derived from Tabulated List mode should call this after setting
 the above variables (in particular, only after setting
diff --git a/doc/lispref/processes.texi b/doc/lispref/processes.texi
index 03ae1f0..4977d2c 100644
--- a/doc/lispref/processes.texi
+++ b/doc/lispref/processes.texi
@@ -506,7 +506,7 @@ Synchronous Processes
 @defun call-process-shell-command command &optional infile destination display
 This function executes the shell command @var{command} synchronously.
 The arguments are handled as in @code{call-process}.  An old calling
-convention allowed to pass any number of additional arguments after
+convention allowed passing any number of additional arguments after
 @var{display}, which were concatenated to @var{command}; this is still
 supported, but strongly discouraged.
 @end defun
@@ -515,7 +515,7 @@ Synchronous Processes
 This function is like @code{call-process-shell-command}, but uses
 @code{process-file} internally.  Depending on @code{default-directory},
 @var{command} can be executed also on remote hosts.  An old calling
-convention allowed to pass any number of additional arguments after
+convention allowed passing any number of additional arguments after
 @var{display}, which were concatenated to @var{command}; this is still
 supported, but strongly discouraged.
 @end defun
@@ -1382,12 +1382,13 @@ Process Buffers
 @end defun
 
 If the process's buffer is displayed in a window, your Lisp program
-may wish telling the process the dimensions of that window, so that
-the process could adapt its output to those dimensions, much as it
-adapts to the screen dimensions.  The following functions allow to
-communicate this kind of information to processes; however, not all
-systems support the underlying functionality, so it is best to provide
-fallbacks, e.g., via command-line arguments or environment variables.
+may wish to tell the process the dimensions of that window, so that
+the process can adapt its output to those dimensions, much as it
+adapts to the screen dimensions.  The following functions allow your
+program to communicate this kind of information to processes; however,
+not all systems support the underlying functionality, so it is best to
+provide fallbacks, e.g., via command-line arguments or environment
+variables.
 
 @defun set-process-window-size process height width
 Tell @var{process} that its logical window size has dimensions
diff --git a/doc/lispref/text.texi b/doc/lispref/text.texi
index 96f109b..7791c26 100644
--- a/doc/lispref/text.texi
+++ b/doc/lispref/text.texi
@@ -1376,10 +1376,10 @@ Undo
 the effects of one command.  A few exceptional commands are
 @dfn{amalgamating}: these commands generally cause small changes to
 buffers, so with these a boundary is inserted only every 20th command,
-allowing to undo them as a group.  By default, commands
+allowing the changes to be undone as a group.  By default, the commands
 @code{self-insert-command}, which produces self-inserting input
-characters (@pxref{Commands for Insertion}), and @code{delete-char}
-which deletes characters (@pxref{Deletion}) are amalgamating.
+characters (@pxref{Commands for Insertion}), and @code{delete-char},
+which deletes characters (@pxref{Deletion}), are amalgamating.
 Where a command affects the contents of several buffers, as may happen,
 for example, when a function on the @code{post-command-hook} affects a
 buffer other than the @code{current-buffer}, then @code{undo-boundary}
diff --git a/src/floatfns.c b/src/floatfns.c
index c1bd258..f514fcb 100644
--- a/src/floatfns.c
+++ b/src/floatfns.c
@@ -185,8 +185,8 @@ If X is zero, both parts (SGNFCAND and EXP) are zero.  */)
 }
 
 DEFUN ("ldexp", Fldexp, Sldexp, 2, 2, 0,
-       doc: /* Return X * 2**EXP, as a floating point number.
-EXP must be an integer.   */)
+       doc: /* Return SGNFCAND * 2**EXPONENT, as a floating point number.
+EXPONENT must be an integer.   */)
   (Lisp_Object sgnfcand, Lisp_Object exponent)
 {
   CHECK_NUMBER (exponent);
diff --git a/src/xfaces.c b/src/xfaces.c
index 88f5f34..5077cb2 100644
--- a/src/xfaces.c
+++ b/src/xfaces.c
@@ -6503,8 +6503,8 @@ REPLACEMENT is a face specification, i.e. one of the following:
   (3) a list in which each element has the form of (1) or (2).
 
 List values for REPLACEMENT are merged to form the final face
-specification, with earlier entries taking precedence, in the same as
-as in the `face' text property.
+specification, with earlier entries taking precedence, in the same way
+as with the `face' text property.
 
 Face-name remapping cycles are suppressed; recursive references use
 the underlying face instead of the remapped face.  So a remapping of

bug#23746: 25.0.95; Doc fixes (grammar, typos, clarification)

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Date: Sat, 11 Jun 2016 17:54:04 +0200
> 
> In GNU Emacs 25.0.95.1 (x86_64-suse-linux-gnu, GTK+ Version 3.14.15)
>  of 2016-06-11 built on rosalinde
> Repository revision: 6921f4a5961fb53f8fb24d1a5a3f94266f990f6e

Thanks.  Please go ahead and push to the release branch, with the
following 2 exceptions:

> --- a/doc/lispref/control.texi
> +++ b/doc/lispref/control.texi
> @@ -289,11 +289,11 @@ Conditionals
>  @end example
>  
>  @menu
> -* Pattern matching case statement::
> +* Pattern Matching Case Statement::
>  @end menu

This and related changes just change the letter-case, which isn't
worth the hassle (and could break cross-references from other
manuals).

> @@ -1382,12 +1382,13 @@ Process Buffers
>  @end defun
>  
>  If the process's buffer is displayed in a window, your Lisp program
> -may wish telling the process the dimensions of that window, so that
> -the process could adapt its output to those dimensions, much as it
> -adapts to the screen dimensions.  The following functions allow to
> -communicate this kind of information to processes; however, not all
> -systems support the underlying functionality, so it is best to provide
> -fallbacks, e.g., via command-line arguments or environment variables.
> +may wish to tell the process the dimensions of that window, so that
> +the process can adapt its output to those dimensions, much as it
> +adapts to the screen dimensions.  The following functions allow your
> +program to communicate this kind of information to processes; however,
> +not all systems support the underlying functionality, so it is best to
> +provide fallbacks, e.g., via command-line arguments or environment
> +variables.

This goes against the rest of the changes, which correctly made the
opposite replacement.  I see no reason to make the opposite change
here.

bug#23746: 25.0.95; Doc fixes (grammar, typos, clarification)

[Stephen Berman]

On Sat, 11 Jun 2016 19:08:57 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Date: Sat, 11 Jun 2016 17:54:04 +0200
>> 
>> In GNU Emacs 25.0.95.1 (x86_64-suse-linux-gnu, GTK+ Version 3.14.15)
>>  of 2016-06-11 built on rosalinde
>> Repository revision: 6921f4a5961fb53f8fb24d1a5a3f94266f990f6e
>
> Thanks.  Please go ahead and push to the release branch, with the
> following 2 exceptions:
[...]
>> @@ -1382,12 +1382,13 @@ Process Buffers
>>  @end defun
>>  
>>  If the process's buffer is displayed in a window, your Lisp program
>> -may wish telling the process the dimensions of that window, so that
        ^^^^^^^^^^^^
>> -the process could adapt its output to those dimensions, much as it
                ^^^^^
>> -adapts to the screen dimensions.  The following functions allow to
                                                              ^^^^^^^^
>> -communicate this kind of information to processes; however, not all
    ^^^^^^^^^^^
>> -systems support the underlying functionality, so it is best to provide
>> -fallbacks, e.g., via command-line arguments or environment variables.
>> +may wish to tell the process the dimensions of that window, so that
        ^^^^^^^^^^^^
>> +the process can adapt its output to those dimensions, much as it
                ^^^
>> +adapts to the screen dimensions.  The following functions allow your
                                                              ^^^^^^^^^^
>> +program to communicate this kind of information to processes; however,
    ^^^^^^^^^^^^^^^^^^^^^^
>> +not all systems support the underlying functionality, so it is best to
>> +provide fallbacks, e.g., via command-line arguments or environment
>> +variables.
>
> This goes against the rest of the changes, which correctly made the
> opposite replacement.  I see no reason to make the opposite change
> here.

I don't understand what you mean; the changes in that hunk are strictly
grammatical corrections (underlined).

Steve Berman

bug#23746: 25.0.95; Doc fixes (grammar, typos, clarification)

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 23746@debbugs.gnu.org
> Date: Sat, 11 Jun 2016 18:32:57 +0200
> 
> >>  If the process's buffer is displayed in a window, your Lisp program
> >> -may wish telling the process the dimensions of that window, so that
>         ^^^^^^^^^^^^
> >> -the process could adapt its output to those dimensions, much as it
>                 ^^^^^
> >> -adapts to the screen dimensions.  The following functions allow to
>                                                               ^^^^^^^^
> >> -communicate this kind of information to processes; however, not all
>     ^^^^^^^^^^^
> >> -systems support the underlying functionality, so it is best to provide
> >> -fallbacks, e.g., via command-line arguments or environment variables.
> >> +may wish to tell the process the dimensions of that window, so that
>         ^^^^^^^^^^^^
> >> +the process can adapt its output to those dimensions, much as it
>                 ^^^
> >> +adapts to the screen dimensions.  The following functions allow your
>                                                               ^^^^^^^^^^
> >> +program to communicate this kind of information to processes; however,
>     ^^^^^^^^^^^^^^^^^^^^^^
> >> +not all systems support the underlying functionality, so it is best to
> >> +provide fallbacks, e.g., via command-line arguments or environment
> >> +variables.
> >
> > This goes against the rest of the changes, which correctly made the
> > opposite replacement.  I see no reason to make the opposite change
> > here.
> 
> I don't understand what you mean; the changes in that hunk are strictly
> grammatical corrections (underlined).

Yes.  They are just backwards: "may wish telling" => "may wish to tell".

bug#23746: 25.0.95; Doc fixes (grammar, typos, clarification)

[Noam Postavsky]

On Sat, Jun 11, 2016 at 3:22 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> >
>> > This goes against the rest of the changes, which correctly made the
>> > opposite replacement.  I see no reason to make the opposite change
>> > here.
>>
>> I don't understand what you mean; the changes in that hunk are strictly
>> grammatical corrections (underlined).
>
> Yes.  They are just backwards: "may wish telling" => "may wish to tell".
>

As a native English speaker, "your Lisp program may wish telling the
process" sounds obviously incorrect (though I'm not sure how to
explain why in terms of grammatical rules). Whereas, "your Lisp
program may wish to tell the process" is correct.

bug#23746: 25.0.95; Doc fixes (grammar, typos, clarification)

[Stephen Berman]

On Sat, 11 Jun 2016 16:21:19 -0400 Noam Postavsky <npostavs@users.sourceforge.net> wrote:

> On Sat, Jun 11, 2016 at 3:22 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>> >
>>> > This goes against the rest of the changes, which correctly made the
>>> > opposite replacement.  I see no reason to make the opposite change
>>> > here.
>>>
>>> I don't understand what you mean; the changes in that hunk are strictly
>>> grammatical corrections (underlined).
>>
>> Yes.  They are just backwards: "may wish telling" => "may wish to tell".
>>
>
> As a native English speaker, "your Lisp program may wish telling the
> process" sounds obviously incorrect (though I'm not sure how to
> explain why in terms of grammatical rules). Whereas, "your Lisp
> program may wish to tell the process" is correct.

That's one argument for this change; another is the statistical one
based on the existing Emacs documentation:

steve@rosalinde:/data/steve/git/emacs> grep -r " wish to " doc/ | wc -l
196
steve@rosalinde:/data/steve/git/emacs> grep -r " wish [a-z]*ing " doc/
doc/lispref/processes.texi:may wish telling the process the dimensions

Eli, does this persuade you to accept this change too?

Steve Berman

bug#23746: 25.0.95; Doc fixes (grammar, typos, clarification)

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  23746@debbugs.gnu.org
> Date: Sun, 12 Jun 2016 19:58:27 +0200
> 
> On Sat, 11 Jun 2016 16:21:19 -0400 Noam Postavsky <npostavs@users.sourceforge.net> wrote:
> 
> > As a native English speaker, "your Lisp program may wish telling the
> > process" sounds obviously incorrect (though I'm not sure how to
> > explain why in terms of grammatical rules). Whereas, "your Lisp
> > program may wish to tell the process" is correct.
> 
> That's one argument for this change; another is the statistical one
> based on the existing Emacs documentation:
> 
> steve@rosalinde:/data/steve/git/emacs> grep -r " wish to " doc/ | wc -l
> 196
> steve@rosalinde:/data/steve/git/emacs> grep -r " wish [a-z]*ing " doc/
> doc/lispref/processes.texi:may wish telling the process the dimensions
> 
> Eli, does this persuade you to accept this change too?

Sorry, no.  There's nothing wrong in the original wording in this
case.

bug#23746: 25.0.95; Doc fixes (grammar, typos, clarification)

[Ken Brown]

On 6/12/2016 2:55 PM, Eli Zaretskii wrote:
>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  23746@debbugs.gnu.org
>> Date: Sun, 12 Jun 2016 19:58:27 +0200
>>
>> On Sat, 11 Jun 2016 16:21:19 -0400 Noam Postavsky <npostavs@users.sourceforge.net> wrote:
>>
>>> As a native English speaker, "your Lisp program may wish telling the
>>> process" sounds obviously incorrect (though I'm not sure how to
>>> explain why in terms of grammatical rules). Whereas, "your Lisp
>>> program may wish to tell the process" is correct.
>>
>> That's one argument for this change; another is the statistical one
>> based on the existing Emacs documentation:
>>
>> steve@rosalinde:/data/steve/git/emacs> grep -r " wish to " doc/ | wc -l
>> 196
>> steve@rosalinde:/data/steve/git/emacs> grep -r " wish [a-z]*ing " doc/
>> doc/lispref/processes.texi:may wish telling the process the dimensions
>>
>> Eli, does this persuade you to accept this change too?
>
> Sorry, no.  There's nothing wrong in the original wording in this
> case.

As a native speaker of English, I agree with Noam on this.  "may wish 
telling" sounds wrong.

Ken

bug#23746: 25.0.95; Doc fixes (grammar, typos, clarification)

[Noam Postavsky]

On Sun, Jun 12, 2016 at 3:40 PM, Ken Brown <kbrown@cornell.edu> wrote:
> On 6/12/2016 2:55 PM, Eli Zaretskii wrote:
>>>
>>> From: Stephen Berman <stephen.berman@gmx.net>
>>> Cc: Eli Zaretskii <eliz@gnu.org>,  23746@debbugs.gnu.org
>>> Date: Sun, 12 Jun 2016 19:58:27 +0200
>>>
>>> On Sat, 11 Jun 2016 16:21:19 -0400 Noam Postavsky
>>> <npostavs@users.sourceforge.net> wrote:
>>>
>>>> As a native English speaker, "your Lisp program may wish telling the
>>>> process" sounds obviously incorrect (though I'm not sure how to
>>>> explain why in terms of grammatical rules). Whereas, "your Lisp
>>>> program may wish to tell the process" is correct.
>>>
>>>
>>> That's one argument for this change; another is the statistical one
>>> based on the existing Emacs documentation:
>>>
>>> steve@rosalinde:/data/steve/git/emacs> grep -r " wish to " doc/ | wc -l
>>> 196
>>> steve@rosalinde:/data/steve/git/emacs> grep -r " wish [a-z]*ing " doc/
>>> doc/lispref/processes.texi:may wish telling the process the dimensions
>>>
>>> Eli, does this persuade you to accept this change too?
>>
>>
>> Sorry, no.  There's nothing wrong in the original wording in this
>> case.

I'm sorry, but you're simply wrong on this. The original wording is
grammatically incorrect, please defer to people with more knowledge of
English, as I'm sure anyone would defer to you on a question regarding
Emacs' display engine.


>
>
> As a native speaker of English, I agree with Noam on this.  "may wish
> telling" sounds wrong.
>
> Ken

bug#23746: 25.0.95; Doc fixes (grammar, typos, clarification)

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Sun, 12 Jun 2016 17:09:45 -0400
> Cc: Eli Zaretskii <eliz@gnu.org>, Stephen Berman <stephen.berman@gmx.net>, 23746@debbugs.gnu.org
> 
> I'm sorry, but you're simply wrong on this. The original wording is
> grammatically incorrect, please defer to people with more knowledge of
> English, as I'm sure anyone would defer to you on a question regarding
> Emacs' display engine.

Actually, no one defers to me on the display engine, I'm normally
required to prove my opinions with hard evidence.

Anyway, which part(s) are grammatically incorrect, and why?  The
changes in question modified at least 3 different parts, all of them
seem to be stylistic changes.  I wonder why stylistic matters should
cause this amount of bike-shedding.

bug#23746: 25.0.95; Doc fixes (grammar, typos, clarification)

[Stephen Berman]

On Mon, 13 Jun 2016 07:04:58 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

> Anyway, which part(s) are grammatically incorrect, and why?  The

Since I proposed the changes, I will try to explain why.

> changes in question modified at least 3 different parts, all of them
> seem to be stylistic changes.  I wonder why stylistic matters should
> cause this amount of bike-shedding.

Here is the relevent diff again, with the three parts in question
underlined:

   @@ -1382,12 +1382,13 @@ Process Buffers
    @end defun
    
    If the process's buffer is displayed in a window, your Lisp program
   -may wish telling the process the dimensions of that window, so that
        ^^^^^^^^^^^^
   -the process could adapt its output to those dimensions, much as it
                ^^^^^
   -adapts to the screen dimensions.  The following functions allow to
                                                              ^^^^^^^^
   -communicate this kind of information to processes; however, not all
    ^^^^^^^^^^^
   -systems support the underlying functionality, so it is best to provide
   -fallbacks, e.g., via command-line arguments or environment variables.
   +may wish to tell the process the dimensions of that window, so that
        ^^^^^^^^^^^^
   +the process can adapt its output to those dimensions, much as it
                ^^^
   +adapts to the screen dimensions.  The following functions allow your
                                                              ^^^^^^^^^^
   +program to communicate this kind of information to processes; however,
    ^^^^^^^^^^^^^^^^^^^^^^
   +not all systems support the underlying functionality, so it is best to
   +provide fallbacks, e.g., via command-line arguments or environment
   +variables.

The line between grammaticality and stylistic variation isn't always
clearcut, but I think there would be little or no disagreement among
native speakers of the most widely spoken dialects of English (there may
be dialects that differ, though I am not aware of any) regarding at
least two of the three underlined parts above: "wish" and "allow" can
both occur with non-finite clausal complements, but with differences:
"wish" can occur only with a "to"-infinitive, usually without a subject,
as in "I wish to go" but possibly also with one, as in "I wish you to
go" or "I wish for you to go" (to me, the first sounds rather formal or
archaic, the second sounds colloquial but possibly non-standard); in
contrast, an "-ing" complement (with or without a subject), as in "I
wish (you) going" is unacceptable.  "Allow" can occur with a
"to"-infinitive, but then only with a subject, as in "I allowed you to
go" but not "I allowed to go" (unless the complement is passivized, as
in "We were allowed to go"); in some cases a subjectless "-ing"
complement is possible, as in "the header line allows sorting entries by
clicking on column headers", where the understood subject of "sorting"
is nonspecific, e.g., people in general, not some particular individual:
"I allowed John going" is unacceptable (there may be some dialectal
variation about this, but I'm not sure).  These differences are
grammatical in the sense that native speakers by and large agree on
what's "right" and "wrong", regardless of context or stylistic register
(though, again, there are gray areas).
  
As for my suggestion to use "can" instead of "could", I suspect there
may be less agreement about that: both entail possibility, but in the
above context "can" sounds more natural (or appropriate) to me due to
the present tense of the whole sentence, in contrast to the following:
"If your program told the process the dimensions of the window, the
process could adapt its output to those dimensions".  But I think many
native speakers would find either form perfectly acceptable in the above
context.

Steve Berman

bug#23746: 25.0.95; Doc fixes (grammar, typos, clarification)

[Stephen Berman]

On Mon, 13 Jun 2016 11:20:43 +0200 Stephen Berman <stephen.berman@gmx.net> wrote:


> go" but not "I allowed to go" (unless the complement is passivized, as
                                        ^^^^^^^^^^^^^^
Sorry:                                  s/the complement/"allow"/

> in "We were allowed to go"); in some cases a subjectless "-ing"

Steve Berman

bug#23746: 25.0.95; Doc fixes (grammar, typos, clarification)

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: Noam Postavsky <npostavs@users.sourceforge.net>,  kbrown@cornell.edu,  23746@debbugs.gnu.org
> Date: Mon, 13 Jun 2016 11:20:43 +0200
> 
> The line between grammaticality and stylistic variation isn't always
> clearcut, but I think there would be little or no disagreement among
> native speakers of the most widely spoken dialects of English (there may
> be dialects that differ, though I am not aware of any) regarding at
> least two of the three underlined parts above: "wish" and "allow" can
> both occur with non-finite clausal complements, but with differences:
> "wish" can occur only with a "to"-infinitive, usually without a subject,
> as in "I wish to go" but possibly also with one, as in "I wish you to
> go" or "I wish for you to go" (to me, the first sounds rather formal or
> archaic, the second sounds colloquial but possibly non-standard); in
> contrast, an "-ing" complement (with or without a subject), as in "I
> wish (you) going" is unacceptable.  "Allow" can occur with a
> "to"-infinitive, but then only with a subject, as in "I allowed you to
> go" but not "I allowed to go" (unless the complement is passivized, as
> in "We were allowed to go"); in some cases a subjectless "-ing"
> complement is possible, as in "the header line allows sorting entries by
> clicking on column headers", where the understood subject of "sorting"
> is nonspecific, e.g., people in general, not some particular individual:
> "I allowed John going" is unacceptable (there may be some dialectal
> variation about this, but I'm not sure).  These differences are
> grammatical in the sense that native speakers by and large agree on
> what's "right" and "wrong", regardless of context or stylistic register
> (though, again, there are gray areas).
>   
> As for my suggestion to use "can" instead of "could", I suspect there
> may be less agreement about that: both entail possibility, but in the
> above context "can" sounds more natural (or appropriate) to me due to
> the present tense of the whole sentence, in contrast to the following:
> "If your program told the process the dimensions of the window, the
> process could adapt its output to those dimensions".  But I think many
> native speakers would find either form perfectly acceptable in the above
> context.

Is the text below good enough?

     If the process’s buffer is displayed in a window, your Lisp program
  may wish to tell the process the dimensions of that window, so that the
  process could adapt its output to those dimensions, much as it adapts to
  the screen dimensions.  The following functions allow communicating
  this kind of information to processes; [...]

bug#23746: 25.0.95; Doc fixes (grammar, typos, clarification)

[Stephen Berman]

On Mon, 13 Jun 2016 17:14:35 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

> Is the text below good enough?
>
>      If the process’s buffer is displayed in a window, your Lisp program
>   may wish to tell the process the dimensions of that window, so that the
>   process could adapt its output to those dimensions, much as it adapts to
>   the screen dimensions.  The following functions allow communicating
>   this kind of information to processes; [...]

That's ok by me.

Steve Berman

bug#23746: 25.0.95; Doc fixes (grammar, typos, clarification)

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: npostavs@users.sourceforge.net,  kbrown@cornell.edu,  23746@debbugs.gnu.org
> Date: Mon, 13 Jun 2016 16:27:31 +0200
> 
> On Mon, 13 Jun 2016 17:14:35 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Is the text below good enough?
> >
> >      If the process’s buffer is displayed in a window, your Lisp program
> >   may wish to tell the process the dimensions of that window, so that the
> >   process could adapt its output to those dimensions, much as it adapts to
> >   the screen dimensions.  The following functions allow communicating
> >   this kind of information to processes; [...]
> 
> That's ok by me.

Thanks, pushed.

bug#23746: 25.0.95; Doc fixes (grammar, typos, clarification)

[Stephen Berman]

On Mon, 13 Jun 2016 18:01:37 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: npostavs@users.sourceforge.net,  kbrown@cornell.edu,  23746@debbugs.gnu.org
>> Date: Mon, 13 Jun 2016 16:27:31 +0200
>> 
>> On Mon, 13 Jun 2016 17:14:35 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>> > Is the text below good enough?
>> >
>> >      If the process’s buffer is displayed in a window, your Lisp program
>> >   may wish to tell the process the dimensions of that window, so that the
>> >   process could adapt its output to those dimensions, much as it adapts to
>> >   the screen dimensions.  The following functions allow communicating
>> >   this kind of information to processes; [...]
>> 
>> That's ok by me.
>
> Thanks, pushed.

And now I've pushed the doc fixes you already approved and am closing
this bug.  (BTW, your commit references the wrong bug....)

Steve Berman

bug#23746: 25.0.95; Doc fixes (grammar, typos, clarification)

[Stephen Berman]

On Mon, 13 Jun 2016 18:12:32 +0200 Stephen Berman <stephen.berman@gmx.net> wrote:

> On Mon, 13 Jun 2016 18:01:37 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>
>>> From: Stephen Berman <stephen.berman@gmx.net>
>>> Cc: npostavs@users.sourceforge.net,  kbrown@cornell.edu,  23746@debbugs.gnu.org
>>> Date: Mon, 13 Jun 2016 16:27:31 +0200
>>> 
>>> On Mon, 13 Jun 2016 17:14:35 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>>> 
>>> > Is the text below good enough?
>>> >
>>> >      If the process’s buffer is displayed in a window, your Lisp program
>>> >   may wish to tell the process the dimensions of that window, so that the
>>> >   process could adapt its output to those dimensions, much as it adapts to
>>> >   the screen dimensions.  The following functions allow communicating
>>> >   this kind of information to processes; [...]
>>> 
>>> That's ok by me.
>>
>> Thanks, pushed.
>
> And now I've pushed the doc fixes you already approved and am closing
> this bug.  (BTW, your commit references the wrong bug....)

Oops, I left out the other changes you had approved from processes.texi;
now pushed.

Steve Berman

bug#23746: 25.0.95; Doc fixes (grammar, typos, clarification)

[Noam Postavsky]

On Mon, Jun 13, 2016 at 12:04 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Noam Postavsky <npostavs@users.sourceforge.net>
>> Date: Sun, 12 Jun 2016 17:09:45 -0400
>> Cc: Eli Zaretskii <eliz@gnu.org>, Stephen Berman <stephen.berman@gmx.net>, 23746@debbugs.gnu.org
>>
>> I'm sorry, but you're simply wrong on this. The original wording is
>> grammatically incorrect, please defer to people with more knowledge of
>> English, as I'm sure anyone would defer to you on a question regarding
>> Emacs' display engine.
>
> Actually, no one defers to me on the display engine, I'm normally
> required to prove my opinions with hard evidence.

Eli, I'm sorry for trying to strongarm you about this, I was a bit
frustrated that you were blocking what looked to me like a
"no-brainer" improvement. But of course you have to apply your own
judgement, and I was wrong to suggest otherwise.

bug#23746: 25.0.95; Doc fixes (grammar, typos, clarification)

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Mon, 13 Jun 2016 22:43:37 -0400
> Cc: 23746@debbugs.gnu.org, Stephen Berman <stephen.berman@gmx.net>, 
> 	Ken Brown <kbrown@cornell.edu>
> 
> On Mon, Jun 13, 2016 at 12:04 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> From: Noam Postavsky <npostavs@users.sourceforge.net>
> >> Date: Sun, 12 Jun 2016 17:09:45 -0400
> >> Cc: Eli Zaretskii <eliz@gnu.org>, Stephen Berman <stephen.berman@gmx.net>, 23746@debbugs.gnu.org
> >>
> >> I'm sorry, but you're simply wrong on this. The original wording is
> >> grammatically incorrect, please defer to people with more knowledge of
> >> English, as I'm sure anyone would defer to you on a question regarding
> >> Emacs' display engine.
> >
> > Actually, no one defers to me on the display engine, I'm normally
> > required to prove my opinions with hard evidence.
> 
> Eli, I'm sorry for trying to strongarm you about this, I was a bit
> frustrated that you were blocking what looked to me like a
> "no-brainer" improvement. But of course you have to apply your own
> judgement, and I was wrong to suggest otherwise.

No sweat.