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