From 423bdd5f7f273f40f750eac83017074501d52823 Mon Sep 17 00:00:00 2001 From: Stefan Kangas Date: Thu, 29 Sep 2022 15:19:01 +0200 Subject: [PATCH] ; Fix typos (prefer American spelling) --- doc/misc/modus-themes.org | 6 +++--- etc/themes/modus-themes.el | 2 +- lisp/comint.el | 2 +- lisp/emacs-lisp/byte-opt.el | 4 ++-- lisp/ielm.el | 2 +- lisp/progmodes/cc-fonts.el | 2 +- lisp/shell.el | 2 +- test/lisp/net/mailcap-tests.el | 2 +- 8 files changed, 11 insertions(+), 11 deletions(-) diff --git a/doc/misc/modus-themes.org b/doc/misc/modus-themes.org index 1b4bf88a0cc..fdc1dfcaba1 100644 --- a/doc/misc/modus-themes.org +++ b/doc/misc/modus-themes.org @@ -5852,7 +5852,7 @@ interface virtually unusable. [[#h:5808be52-361a-4d18-88fd-90129d206f9b][Option for links]]. -Again, one must exercise judgement in order to avoid discrimination, +Again, one must exercise judgment in order to avoid discrimination, where "discrimination" refers to: + The treatment of substantially different magnitudes as if they were of @@ -5868,11 +5868,11 @@ usability beyond matters of color---they would be making a not-so-obvious error of treating different cases as if they were the same. -The Modus themes prioritise "thematic consistency" over abstract harmony +The Modus themes prioritize "thematic consistency" over abstract harmony or regularity among their applicable colors. In concrete terms, we do not claim that, say, our yellows are the best complements for our blues because we generally avoid using complementary colors side-by-side, so -it is wrong to optimise for a decontextualised blue+yellow combination. +it is wrong to optimize for a decontextualised blue+yellow combination. Not to imply that our colors do not work well together because they do, just to clarify that consistency of context is what themes must strive for, and that requires widening the scope of the design beyond the diff --git a/etc/themes/modus-themes.el b/etc/themes/modus-themes.el index 6296bf90251..a6bbdfe0bb8 100644 --- a/etc/themes/modus-themes.el +++ b/etc/themes/modus-themes.el @@ -1435,7 +1435,7 @@ By default, customizing a theme-related user option through the Custom interfaces or with `customize-set-variable' will not reload the currently active Modus theme. -Enable this behaviour by setting this variable to nil." +Enable this behavior by setting this variable to nil." :group 'modus-themes :package-version '(modus-themes . "1.5.0") :version "28.1" diff --git a/lisp/comint.el b/lisp/comint.el index b2a04ea55ae..e7d2136c841 100644 --- a/lisp/comint.el +++ b/lisp/comint.el @@ -3966,7 +3966,7 @@ an indirect buffer, whose major mode and syntax highlighting are set up according to `comint-indirect-setup-function'. After this setup is done, run this hook with the indirect buffer as the current buffer. This can be used to further customize -fontification and other behaviour of the indirect buffer." +fontification and other behavior of the indirect buffer." :group 'comint :type 'hook :version "29.1") diff --git a/lisp/emacs-lisp/byte-opt.el b/lisp/emacs-lisp/byte-opt.el index ed6b7b08a49..5ef2d7fe827 100644 --- a/lisp/emacs-lisp/byte-opt.el +++ b/lisp/emacs-lisp/byte-opt.el @@ -812,7 +812,7 @@ for speeding up processing.") (defun byte-compile-nilconstp (form) "Return non-nil if FORM always evaluates to a nil value." (setq form (byte-opt--bool-value-form form)) - (or (not form) ; assume (quote nil) always being normalised to nil + (or (not form) ; assume (quote nil) always being normalized to nil (and (consp form) (let ((head (car form))) ;; FIXME: There are many other expressions that are statically nil. @@ -1184,7 +1184,7 @@ See Info node `(elisp) Integer Basics'." (if (equal new-args (cdr form)) ;; Input is unchanged: keep original form, and don't represent ;; a nil result explicitly because that would lead to infinite - ;; growth when the optimiser is iterated. + ;; growth when the optimizer is iterated. (setq nil-result nil) (setq form (cons (car form) new-args))) diff --git a/lisp/ielm.el b/lisp/ielm.el index 4a10c002976..ad41cb1f6bd 100644 --- a/lisp/ielm.el +++ b/lisp/ielm.el @@ -491,7 +491,7 @@ and syntax highlighting are set up with `emacs-lisp-mode'. In addition to `comint-indirect-setup-hook', run this hook with the indirect buffer as the current buffer after its setup is done. This can be used to further customize fontification and other -behaviour of the indirect buffer." +behavior of the indirect buffer." :type 'boolean :safe 'booleanp :version "29.1") diff --git a/lisp/progmodes/cc-fonts.el b/lisp/progmodes/cc-fonts.el index 753ae480878..d2af53e837c 100644 --- a/lisp/progmodes/cc-fonts.el +++ b/lisp/progmodes/cc-fonts.el @@ -1972,7 +1972,7 @@ casts and declarations are fontified. Used on level 2 and higher." (c-forward-syntactic-ws limit)))) (defun c-font-lock-c++-modules (limit) - ;; Fontify the C++20 module stanzas, characterised by the keywords `module', + ;; Fontify the C++20 module stanzas, characterized by the keywords `module', ;; `export' and `import'. Note that this has to be done by a function (as ;; opposed to regexps) due to the presence of optional C++ attributes. ;; diff --git a/lisp/shell.el b/lisp/shell.el index 87fd36a5929..18bb3722427 100644 --- a/lisp/shell.el +++ b/lisp/shell.el @@ -324,7 +324,7 @@ enabled, is performed in an indirect buffer, whose indentation and syntax highlighting is set up with `sh-mode'. In addition to `comint-indirect-setup-hook', run this hook with the indirect buffer as the current buffer after its setup is done. This can -be used to further customize fontification and other behaviour of +be used to further customize fontification and other behavior of the indirect buffer." :type 'boolean :group 'shell diff --git a/test/lisp/net/mailcap-tests.el b/test/lisp/net/mailcap-tests.el index 8d047c7ff50..9e60a243b3d 100644 --- a/test/lisp/net/mailcap-tests.el +++ b/test/lisp/net/mailcap-tests.el @@ -515,7 +515,7 @@ in ‘mailcap-mime-data’." In its current implementation ‘mailcap-add-mailcap-entry’ loses extra fields of an entry already existing in ‘mailcap-mime-data’. This test does not actually verify a correct result; it merely -checks whether ‘mailcap-add-mailcap-entry’ behaviour is still the +checks whether ‘mailcap-add-mailcap-entry’ behavior is still the incorrect one. As such, it can be satisfied by any other result than the expected and known wrong one, and its success does not help to verify the correct addition and merging of an entry." -- 2.39.2