From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: delete-other-frames Date: Fri, 26 Aug 2016 23:31:19 -0700 (PDT) Message-ID: <49a2a9c7-8573-4f07-897f-3eb444679d8a@default> References: <<57BC072F.9070704@gmx.at>> <<83k2f7fugv.fsf@gnu.org> <57BD63A9.8040502@gmx.at>> <<57BEB772.60100@gmx.at> <83inuoewjy.fsf@gnu.org>> <> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1472279542 25836 195.159.176.226 (27 Aug 2016 06:32:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 27 Aug 2016 06:32:22 +0000 (UTC) Cc: emacs-devel@gnu.org To: rms@gnu.org, Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 27 08:32:19 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bdXA9-0006DU-26 for ged-emacs-devel@m.gmane.org; Sat, 27 Aug 2016 08:32:17 +0200 Original-Received: from localhost ([::1]:34871 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bdXA6-0007Fc-Ca for ged-emacs-devel@m.gmane.org; Sat, 27 Aug 2016 02:32:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34255) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bdX9T-0007FS-Gy for emacs-devel@gnu.org; Sat, 27 Aug 2016 02:31:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bdX9R-0001QI-4s for emacs-devel@gnu.org; Sat, 27 Aug 2016 02:31:34 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:49174) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bdX9J-0001Pm-69; Sat, 27 Aug 2016 02:31:25 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u7R6VLQL005672 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 27 Aug 2016 06:31:23 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u7R6VLlx026272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 27 Aug 2016 06:31:21 GMT Original-Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u7R6VKD9022100; Sat, 27 Aug 2016 06:31:21 GMT In-Reply-To: <> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6753.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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:206825 Archived-At: > > For the future, please adopt the following style: > > This function deletes the specified @var{frame}. > > rather than using this: > > This function deletes the frame @var{frame}. >=20 > The latter is the grammatically correct way. A parameter name in > italics, such as "@var{frame}", acts as a _name_ that refers to the > actual value of the argument. Just as we would write >=20 > Send it to my assistant, Jeanne. >=20 > we should write, > delete the frame, @var{f}. > or > delete the frame, @var{frame}. Yes, and no. 1. If there is only one frame in the discussion, and @var{f} is a name for it, then "delete the frame, @var{f}" is correct. This is _non-restrictive apposition_: the frame and @var{f} are two ways of designating the same thing: THE frame in the scope of discussion. The name @var{f} does not restrict the choice of frames here; it is understood that there is only one, and it is called @var{f}. You could drop either "the frame" or "@var{f}" without loss of meaning: neither qualifies the other. But if there might be more than one frame in the discussion, and @var{f} is the one we are concerned with at present, then this is correct: "delete the frame @var{f}". (Note: no comma.) And so is this: "delete frame @var{f}". Here, @var{f} is the name of the particular frame we care about at the moment, but we do not assume that it is the only one in the general discussion. This is _restrictive apposition_: "@var{f}" restricts "frame", identifying the one frame out of possibly many that we are concerned with now. It is the difference between "my sister, Sue" and "my sister Sue". In the first case I have only one sister. In the second I likely have more than one. In both cases the nominal appositive "Sue" applies to the descriptive appositive "sister". In the first case "Sue" is non-restrictive; in the second case it is restrictive. Clearly, it is easy to not notice a comma, or to mistakenly add or forget a comma, so it is important for clarity that the rest of the text reinforces the meaning. The form of restrictive apposition where "the" is dropped can make reading easier, especially when there are multiple things that we are juggling, as is often the case for technical writing. For example, if we've introduced things clearly enough then it can be simpler to speak of "querying columns JCOL and KCOL of table TAB", instead of bothering readers with "querying the columns JCOL and KCOL of the table TAB". When "the" is omitted the apposition is partial: Only the descriptive appositive (the type: columns or tables) could be omitted; the nominal appositive (the name: JCOL or TAB) is needed (and sufficient). This dropping of the type and using only the name brings us to the next point. 2. I think Eli was talking about something different, but related: the fact that in Emacs doc the name of a parameter is often chosen to be a type name, and a convention is to omit the type noun to which the restrictive appositive applies and let the parameter name stand alone. IOW, if the name of the individual echoes the name of the type then we can get by with just the individual name. Example: Just "copy FILE to DIRECTORY", instead of "copy file FILE to directory DIRECTORY" (or the even heavier "copy the file FILE to the directory DIRECTORY). And if there are multiple individuals of the same type then we can use different names for them that each echo the type name: "copy FILE1 and FILE2 to DIRECTORY". This is a kind of abbreviation, and it is fine too.