all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: allan gottlieb <gottlieb@nyu.edu>
To: help-gnu-emacs@gnu.org
Subject: Re: delete-other-frames
Date: Sat, 27 Aug 2016 09:32:47 -0400	[thread overview]
Message-ID: <87pooupcao.fsf@nyu.edu> (raw)
In-Reply-To: <49a2a9c7-8573-4f07-897f-3eb444679d8a@default> (Drew Adams's message of "Fri, 26 Aug 2016 23:31:19 -0700 (PDT)")

On Sat, Aug 27 2016, Drew Adams wrote:

>>   > 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}.
>> 
>> 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
>> 
>>   Send it to my assistant, Jeanne.
>> 
>> 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.



  parent reply	other threads:[~2016-08-27 13:32 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-23  8:19 delete-other-frames martin rudalics
2016-08-23 14:09 ` delete-other-frames Eli Zaretskii
2016-08-23 17:56   ` delete-other-frames Richard Copley
2016-08-23 18:31     ` delete-other-frames Eli Zaretskii
2016-08-23 19:55       ` delete-other-frames Richard Copley
2016-08-24  9:07     ` delete-other-frames martin rudalics
2016-08-24  9:06   ` delete-other-frames martin rudalics
2016-08-25  9:16     ` delete-other-frames martin rudalics
2016-08-25 14:46       ` delete-other-frames Eli Zaretskii
2016-08-27  1:32         ` delete-other-frames Richard Stallman
2016-08-27  7:40           ` delete-other-frames Eli Zaretskii
     [not found]         ` <<E1bdSUT-00059T-8W@fencepost.gnu.org>
2016-08-27  6:31           ` delete-other-frames Drew Adams
2016-08-27  7:45             ` delete-other-frames Eli Zaretskii
2016-08-27 13:32             ` allan gottlieb [this message]
2016-08-27 13:40               ` delete-other-frames allan gottlieb
2016-08-27 21:45             ` delete-other-frames Richard Stallman
     [not found]           ` <<49a2a9c7-8573-4f07-897f-3eb444679d8a@default>
     [not found]             ` <<E1bdlPn-0005Ch-I4@fencepost.gnu.org>
2016-08-28  0:41               ` delete-other-frames Drew Adams
     [not found] <<<57BC072F.9070704@gmx.at>
     [not found] <<57BC072F.9070704@gmx.at>

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87pooupcao.fsf@nyu.edu \
    --to=gottlieb@nyu.edu \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.