From: Eli Zaretskii <eliz@gnu.org>
To: Sean Whitton <spwhitton@spwhitton.name>
Cc: emacs-devel@gnu.org
Subject: Re: emacs-30 baaf97ce1a1: ; Fix some ungrammatical uses of "allows to"
Date: Fri, 30 Aug 2024 22:18:59 +0300 [thread overview]
Message-ID: <86cylpes4c.fsf@gnu.org> (raw)
In-Reply-To: <87ed65al96.fsf@zephyr.silentflame.com> (message from Sean Whitton on Fri, 30 Aug 2024 20:00:53 +0100)
> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: emacs-devel@gnu.org
> Date: Fri, 30 Aug 2024 20:00:53 +0100
>
> It's just m4/gnulib-common.m4 I should undo, right?
No, not just that. Quite a few m4/*.m4 files are from Gnulib. You
need to look at the Git history to know which ones.
> Or do we not need to undo it now, and just wait for the next gnulib
> import?
We don't need to undo, but we definitely should tell Gnulib folks
about the issue.
> > More generally, "allows to" is AFAIK not necessarily a grammatical
> > mistake, it's a stylistic preference. So this kind of changes should
> > not have been made automatically and without discussion.
>
> It's not just stylistic -- it's certainly incorrect in American English,
> which is Emacs's dialect.
I disagree, but that is not the important aspect of this. The
important aspect is that changing grammar should not make the text
harder to read and understand. By mechanically changing those places
to be grammatically you definitely made at least some of the text more
awkward and hard to read. E.g., look at this one:
-The command @code{recover-file} no longer allows to display the diffs
+The command @code{recover-file} no longer allows displaying the diffs
Does this really read well to you? Or how about this one:
-dnl The first variable allows to distinguish all three cases.
+dnl The first variable allows distinguishing all three cases.
"Allows distinguishing"? really?
You should have instead reworded the text to avoid the use of these
constructs, making the text more clear and side-stepping the issue of
"allow to" entirely.
next prev parent reply other threads:[~2024-08-30 19:18 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-30 17:40 emacs-30 baaf97ce1a1: ; Fix some ungrammatical uses of "allows to" Eli Zaretskii
2024-08-30 18:14 ` Alan Mackenzie
2024-08-30 19:00 ` Eli Zaretskii
2024-08-30 21:09 ` Sean Whitton
2024-08-30 19:03 ` Sean Whitton
2024-08-30 19:22 ` Eli Zaretskii
2024-08-30 21:07 ` Sean Whitton
2024-08-30 23:22 ` [External] : " Drew Adams
2024-08-31 0:23 ` Po Lu
2024-08-31 6:26 ` Sean Whitton
2024-08-31 6:49 ` Gerd Möllmann
2024-08-30 19:00 ` Sean Whitton
2024-08-30 19:18 ` Eli Zaretskii [this message]
2024-08-30 21:00 ` Sean Whitton
2024-08-30 21:15 ` Ship Mints
2024-08-30 23:39 ` Mike Kupfer
2024-08-31 6:15 ` Sean Whitton
2024-08-31 6:54 ` Eli Zaretskii
2024-08-31 14:54 ` Mike Kupfer
2024-08-31 6:44 ` Eli Zaretskii
2024-09-01 10:20 ` Sean Whitton
2024-09-01 10:37 ` Eli Zaretskii
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=86cylpes4c.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=spwhitton@spwhitton.name \
/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).