unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: "rms@gnu.org" <rms@gnu.org>
Cc: "luangruo@yahoo.com" <luangruo@yahoo.com>,
	"emacs-devel@gnu.org" <emacs-devel@gnu.org>,
	"bjc@spork.org" <bjc@spork.org>,
	"arstoffel@gmail.com" <arstoffel@gmail.com>,
	"juri@linkov.net" <juri@linkov.net>
Subject: RE: [External] : Re: master 4c0c9d23ab 1/2: Rewrite the minibuffer lazy highlight feature
Date: Tue, 12 Apr 2022 19:53:38 +0000	[thread overview]
Message-ID: <SJ0PR10MB5488113D23BF3A2948FE4D54F3ED9@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <E1ne75e-0007fF-3m@fencepost.gnu.org>

> > "You can do XYZ."
> > "ABC lets you do XYZ."
> 
> There is semantic sloppiness in using "lets" to mean "enables".
> Likewise, using "permits" or "allows" is sloppy.  They all refer to
> giving permission for or authorizing an action.

Sorry, I don't agree with your characterization.
But of course the devil is in the details of any
particular use/occurrence.

"Let" and "enable...to" are similar.  Neither is
inherently "sloppy" semantically.  But anything
can be used in a way that makes its meaning less
than crystal clear.

Neither "let" nor "enable" _necessarily_ involves
permission or authorization.

(Of course, as with connotation generally, a word
always carries with it _all_ of its connotations.
But context typically filters them.)

"Let" and "enable" _can_ each involve permission.
And it's true that "let" is used with that sense
more than "enable" is - much more.

If a given context makes it difficult to know
whether the meaning might involve permission,
then using "enable...to" might make clear that
permission is not involved.

"Let" is generally preferable for the contexts
we're talking about, however, because it's
simpler.  "Enables...to" is less succinct, and
it's more formal - often unnecessarily so, for
user documentation.

That's the main difference in this context.
"Let" is more conversational and more easily
understood by more people, including non-native
readers.

But of course, if a particular use of "let" can
easily be misread, then...don't use it that way.

("Let" also encourages use of the active voice -
it's nearly impossible to use it in the passive
voice.  Not so, "enable".)

> For actively making something possible, "enable"
> is the clear word.

"Enable" is clear for that, I agree.  But so is
"let" in most cases.  Here's a rule of thumb, to
mull over in any particular context:

 IF using "enable...to" isn't clearer than using
    "let" - i.e., you gain nothing in particular
    by using "enable...to" -
 THEN use "let".

IOW, use "let" by default, rereading to make sure
the meaning is clear and not ambiguous.

Also: It's often the case that it's better to say
"You can use X to do Y" than to say either "X
lets you do Y" or "X enables you to do Y".  That's
why I put that first - see the quoted text at the
top of this message.

(And yes, "can", not "may", for the same reason
you raised: less ambiguity wrt whether permission
is involved.) 

("Enable" of course also makes sense, and "let"
does not, when talking about some feature being
enabled: "You need to enable X before you can Y."
That's a different sense from "enable AN_ACTOR to
ACT".)

Examples:

XYZ lets you quickly react to changing requirements

XYZ lets you create and store collections without
needing to know...

XYZ lets you discover information about the
structure and content of...

Function ABC lets you modify XYZ data in a
declarative way.

Condition ABC lets you use a path expression to
select XYZ based on...

XYZ lets you append new elements to an existing
ABC, by specifying...

Using an array wrapper lets you...

Filters let you test for the existence of...
___

https://english.stackexchange.com/q/212345/51214

https://english.stackexchange.com/questions/181533/word-for-allows-in-special-context

https://hinative.com/en-US/questions/1068322


      reply	other threads:[~2022-04-12 19:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <164961948912.5547.6176778706291368339@vcs2.savannah.gnu.org>
     [not found] ` <20220410193810.B2511C00890@vcs2.savannah.gnu.org>
2022-04-11  1:20   ` master 4c0c9d23ab 1/2: Rewrite the minibuffer lazy highlight feature Po Lu
2022-04-11  1:39     ` Brian Cully
2022-04-11  6:05       ` Augusto Stoffel
2022-04-11 16:49         ` Juri Linkov
2022-04-11 17:14           ` [External] : " Drew Adams
2022-04-12  3:21             ` Richard Stallman
2022-04-12 19:53               ` Drew Adams [this message]

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=SJ0PR10MB5488113D23BF3A2948FE4D54F3ED9@SJ0PR10MB5488.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=arstoffel@gmail.com \
    --cc=bjc@spork.org \
    --cc=emacs-devel@gnu.org \
    --cc=juri@linkov.net \
    --cc=luangruo@yahoo.com \
    --cc=rms@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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).