unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Re: master 4c0c9d23ab 1/2: Rewrite the minibuffer lazy highlight feature
       [not found] ` <20220410193810.B2511C00890@vcs2.savannah.gnu.org>
@ 2022-04-11  1:20   ` Po Lu
  2022-04-11  1:39     ` Brian Cully
  0 siblings, 1 reply; 7+ messages in thread
From: Po Lu @ 2022-04-11  1:20 UTC (permalink / raw)
  To: emacs-devel; +Cc: Augusto Stoffel

Juri Linkov <juri@jurta.org> writes:

> +This function allows to set up the minibuffer so that lazy
> +highlighting of its content is applied in the original window.

I used to be guilty of this mistake as well, but yesterday I read an
style guide according to which "allows to" is not correct English.

It's probably prudent to replace that with "allows you to" or "allows
users to".



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: master 4c0c9d23ab 1/2: Rewrite the minibuffer lazy highlight feature
  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
  0 siblings, 1 reply; 7+ messages in thread
From: Brian Cully @ 2022-04-11  1:39 UTC (permalink / raw)
  To: Po Lu; +Cc: Augusto Stoffel, emacs-devel


Po Lu <luangruo@yahoo.com> writes:

> Juri Linkov <juri@jurta.org> writes:
>
>> +This function allows to set up the minibuffer so that lazy
>> +highlighting of its content is applied in the original window.
>
> I used to be guilty of this mistake as well, but yesterday I read an
> style guide according to which "allows to" is not correct English.

	It has always struck my (native speaker) ears as odd, but this
construction seems to be gaining prominence within the US.

> It's probably prudent to replace that with "allows you to" or "allows
> users to".

	One may also say “allows setting up the minibuffer”, which I
find the most natural. But any of these choices would be acceptable over
“allows to”, IMHO.

-bjc



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: master 4c0c9d23ab 1/2: Rewrite the minibuffer lazy highlight feature
  2022-04-11  1:39     ` Brian Cully
@ 2022-04-11  6:05       ` Augusto Stoffel
  2022-04-11 16:49         ` Juri Linkov
  0 siblings, 1 reply; 7+ messages in thread
From: Augusto Stoffel @ 2022-04-11  6:05 UTC (permalink / raw)
  To: Brian Cully; +Cc: Po Lu, emacs-devel

On Sun, 10 Apr 2022 at 21:39, Brian Cully <bjc@spork.org> wrote:

> Po Lu <luangruo@yahoo.com> writes:
>
>> Juri Linkov <juri@jurta.org> writes:
>>
>>> +This function allows to set up the minibuffer so that lazy
>>> +highlighting of its content is applied in the original window.
>>
>> I used to be guilty of this mistake as well, but yesterday I read an
>> style guide according to which "allows to" is not correct English.

Sorry, I was also aware of this; as far as grammar rules go, it is a
pretty logical one.  I guess just let it slip out.

I can always create a patch, but it's probably easier for everybody if
someone with commit rights just edit this directly?

> 	It has always struck my (native speaker) ears as odd, but this
> construction seems to be gaining prominence within the US.
>
>> It's probably prudent to replace that with "allows you to" or "allows
>> users to".
>
> 	One may also say “allows setting up the minibuffer”, which I
> find the most natural. But any of these choices would be acceptable over
> “allows to”, IMHO.

I slightly prefer "allows doing something".  It seems quite normal in
English to use "you" to refer to a generic person (as in "apples are
good for you"), but this is kinda funny if think about it.

> -bjc



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: master 4c0c9d23ab 1/2: Rewrite the minibuffer lazy highlight feature
  2022-04-11  6:05       ` Augusto Stoffel
@ 2022-04-11 16:49         ` Juri Linkov
  2022-04-11 17:14           ` [External] : " Drew Adams
  0 siblings, 1 reply; 7+ messages in thread
From: Juri Linkov @ 2022-04-11 16:49 UTC (permalink / raw)
  To: Augusto Stoffel; +Cc: Po Lu, emacs-devel, Brian Cully

>>>> +This function allows to set up the minibuffer so that lazy
>>>> +highlighting of its content is applied in the original window.
>>>
>>> I used to be guilty of this mistake as well, but yesterday I read an
>>> style guide according to which "allows to" is not correct English.
>
> Sorry, I was also aware of this; as far as grammar rules go, it is a
> pretty logical one.  I guess just let it slip out.
>
> I can always create a patch, but it's probably easier for everybody if
> someone with commit rights just edit this directly?
>
>> 	It has always struck my (native speaker) ears as odd, but this
>> construction seems to be gaining prominence within the US.
>>
>>> It's probably prudent to replace that with "allows you to" or "allows
>>> users to".
>>
>> 	One may also say “allows setting up the minibuffer”, which I
>> find the most natural. But any of these choices would be acceptable over
>> “allows to”, IMHO.
>
> I slightly prefer "allows doing something".  It seems quite normal in
> English to use "you" to refer to a generic person (as in "apples are
> good for you"), but this is kinda funny if think about it.

So rephrased now to the suggested wording.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: [External] : Re: master 4c0c9d23ab 1/2: Rewrite the minibuffer lazy highlight feature
  2022-04-11 16:49         ` Juri Linkov
@ 2022-04-11 17:14           ` Drew Adams
  2022-04-12  3:21             ` Richard Stallman
  0 siblings, 1 reply; 7+ messages in thread
From: Drew Adams @ 2022-04-11 17:14 UTC (permalink / raw)
  To: Juri Linkov, Augusto Stoffel; +Cc: Po Lu, Brian Cully, emacs-devel@gnu.org

> >> “allows to”, IMHO.
> >
> > I slightly prefer "allows doing something".  It seems quite normal in
> > English to use "you" to refer to a generic person (as in "apples are
> > good for you"), but this is kinda funny if think about it.
> 
> So rephrased now to the suggested wording.

FWIW -

Generally the simplest, easiest to understand,
and most direct language uses active phrases
like these:

  "You can do XYZ."
  "ABC lets you do XYZ."

In general, you can drop using "enable" and
"allow".  They're use is more verbose and
typically less clear.  Just use "let".

["Enable" can be useful for talking about a
feature/widget, etc.  But then it's about a
person/program etc. enabling something, not
about something enabling a person to do
something.]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [External] : Re: master 4c0c9d23ab 1/2: Rewrite the minibuffer lazy highlight feature
  2022-04-11 17:14           ` [External] : " Drew Adams
@ 2022-04-12  3:21             ` Richard Stallman
  2022-04-12 19:53               ` Drew Adams
  0 siblings, 1 reply; 7+ messages in thread
From: Richard Stallman @ 2022-04-12  3:21 UTC (permalink / raw)
  To: Drew Adams; +Cc: luangruo, emacs-devel, bjc, arstoffel, juri

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    > "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.

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

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: [External] : Re: master 4c0c9d23ab 1/2: Rewrite the minibuffer lazy highlight feature
  2022-04-12  3:21             ` Richard Stallman
@ 2022-04-12 19:53               ` Drew Adams
  0 siblings, 0 replies; 7+ messages in thread
From: Drew Adams @ 2022-04-12 19:53 UTC (permalink / raw)
  To: rms@gnu.org
  Cc: luangruo@yahoo.com, emacs-devel@gnu.org, bjc@spork.org,
	arstoffel@gmail.com, juri@linkov.net

> > "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


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2022-04-12 19:53 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [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

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).