From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: master 1d4862e: Fix English grammar in some doc strings and comments Date: Thu, 7 Nov 2019 19:35:35 -0800 Organization: UCLA Computer Science Department Message-ID: <9ccae76c-07a2-1739-d4b0-5c13164145d3@cs.ucla.edu> References: <14407.1572888070@quatro> <8736f3js95.fsf@fastmail.fm> <871runxqjq.fsf@gmx.net> <87eeyj8nqr.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="49025"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.0 Cc: emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 08 04:36:18 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iSv4M-000CcM-PS for ged-emacs-devel@m.gmane.org; Fri, 08 Nov 2019 04:36:18 +0100 Original-Received: from localhost ([::1]:49484 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iSv4K-0001Jz-Vp for ged-emacs-devel@m.gmane.org; Thu, 07 Nov 2019 22:36:17 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60366) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iSv3r-0001Iz-4G for emacs-devel@gnu.org; Thu, 07 Nov 2019 22:35:48 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iSv3p-0008NG-83 for emacs-devel@gnu.org; Thu, 07 Nov 2019 22:35:46 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:60510) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iSv3p-0008LI-1y for emacs-devel@gnu.org; Thu, 07 Nov 2019 22:35:45 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A9ECB1600F1; Thu, 7 Nov 2019 19:35:39 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 6Fetgzwe70w3; Thu, 7 Nov 2019 19:35:38 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id DC26D160101; Thu, 7 Nov 2019 19:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 24FPeHXAxm0K; Thu, 7 Nov 2019 19:35:38 -0800 (PST) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id BDC971600F1; Thu, 7 Nov 2019 19:35:38 -0800 (PST) In-Reply-To: <87eeyj8nqr.fsf@gnus.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:241964 Archived-At: On 11/7/19 11:55 AM, Lars Ingebrigtsen wrote: > I doubt anybody, non native speaker or not, would find the former > ambiguous. The change is simply nonsensical pet peeving. Pet peeving yes, nonsensical no. In many cases this sort of change does improve clarity, and it's a good habit to use the word "only" consistently to lessen the probability of misunderstanding, as there's little harm in following what you're calling a "pet peeve" guideline and there can often be a benefit in doing so. For example, here's one of the changes Stephen installed: -If the value is `after-completion', confirmation is only - requested if the user called `minibuffer-complete' right before +If the value is `after-completion', confirmation is requested + only if the user called `minibuffer-complete' right before `minibuffer-complete-and-exit'. This particular change makes it less likely that a reader will misinterpret the doc string as saying that confirmation is *requested* instead of being *required*. In verbal communication, it's less important to follow the "pet peeve" guideline for "only", as vocal emphasis often makes it clear which meaning is intended. Written communication lacks this advantage, though. Worse, the writer of a sentence often internally vocalizes it and naturally thinks "well, there's only one plausible way to interpret this so it's good enough", but then someone else who reads the sentence will internally vocalize it differently and misinterpret the scope of the "only". So when writing technical documentation it's a good habit to follow the "pet peeve" guideline even when the sentence seems unambiguous to you otherwise. (If you're writing love letters, the rules are of course quite different and you can disregard this email. :-)