Correct misspellings in command line option descriptions & docs

cmakelang/configuration.py

@@ -49,7 +49,7 @@ class MarkupConfig(ConfigObject):
   explicit_trailing_pattern = FieldDescriptor(
       "#<",
       "If a comment line matches starts with this pattern then it is "
-      "explicitly a trailing comment for the preceeding argument. Default "
+      "explicitly a trailing comment for the preceding argument. Default "
       "is '#<'"
   )
   hashruler_min_length = FieldDescriptor(
@@ -329,7 +329,7 @@ class FormattingConfig(ConfigObject):
   require_valid_layout = FieldDescriptor(
       False,
       "By default, if cmake-format cannot successfully fit everything into"
-      " the desired linewidth it will apply the last, most agressive"
+      " the desired linewidth it will apply the last, most aggressive"
       " attempt that it made. If this flag is True, however, cmake-format"
       " will print error, exit with non-zero status code, and write-out"
       " nothing"

cmakelang/doc/changelog.rst

@@ -450,7 +450,7 @@ v0.5.1
   children
 * Fix ``file(READ ...)`` and ``file(STRINGS ...)`` parser kwargs using set
   syntax instead of dict syntax
-* Fix agressive positional parser within conditional parser
+* Fix aggressive positional parser within conditional parser
 * Fix missing endif, endwhile in parsemap
 * Split parse functions out into separate modules for better organization
 * Add more sanity tests for ``file(...)``.

cmakelang/doc/configopts.rst

@@ -414,7 +414,7 @@ require_valid_layout
 ====================
 
 By default, if cmake-format cannot successfully fit everything into the
-desired linewidth it will apply the last, most agressive attempt that it made.
+desired linewidth it will apply the last, most aggressive attempt that it made.
 If this flag is True, however, cmake-format will print error, exit with non-
 zero status code, and write-out nothing
 
@@ -551,10 +551,10 @@ a particular argument, and will format it accordingly. For example:
     "BOZ" # multi value keywords
     ${ARGN})
 
-The rules for associating a comment with the preceeding argument depend on
+The rules for associating a comment with the preceding argument depend on
 how much (and what kinds) of whitespace separate them. Alternatively, if
 the comments match the ``explicit_trailing_pattern``, then they are associated
-with the preceeding argument regardless of the whitespace separating them.
+with the preceding argument regardless of the whitespace separating them.
 The format for this variable is a python regular expression matching prefix
 characters for such explicit trailing comments. The default value is ``#<``,
 such that the above example using explicit trailing comments would  be:

cmakelang/doc/format-algorithm.rst

@@ -181,14 +181,14 @@ of it's children.
 2. If the token is the last token before a closing parenthesis, and the
    token plus the parenthesis would overflow the column limit, then insert a
    newline.
-3. If a token is preceeded by a line comment, then the token cannot be placed
+3. If a token is preceded by a line comment, then the token cannot be placed
    on the same line as the comment (or it will become part of the comment) so
    a newline is inserted between them.
 4. If a token is a line comment which is not associated with an argument (e.g.
    it is  a "free" comment at the current scope) then it will not be placed
-   on the same line as a preceeding argument token. If it was, then subsequent
+   on the same line as a preceding argument token. If it was, then subsequent
    parses would associate this comment with that argument. In such a case, a
-   newline is inserted between the preceeding argument and the line comment.
+   newline is inserted between the preceding argument and the line comment.
 5. If the node is an interior node, and one of it's children is internally
    wrapped (i.e. consumes more than two lines) then it will not be placed
    on the same line as another node. In such a case a newlines is inserted.

cmakelang/doc/parse-automatic.rst

@@ -64,7 +64,7 @@ can't really figure a pattern for when they are used and when  they are not.
 Ellipses
 ========
 
-Whether or not there is a space between an elipsis and the preceeding token
+Whether or not there is a space between an elipsis and the preceding token
 seems to imply something about what is repeated.
 
 ::

cmakelang/lint/lintdb.py

@@ -61,7 +61,7 @@ def get_database():
 "C0111", "Missing docstring on function or macro declaration", {
 "description": """\
 Used when a function or macro is defined without a documentation comment
-immediately preceeding it.
+immediately preceding it.
 
 This message belongs to the basic checker.
 """,
@@ -75,7 +75,7 @@ def get_database():
 }), (
 "C0112", "Empty docstring on function or macro declaration", {
 "description": """\
-Used when a function or macro is preceeded by an empty comment string, rather
+Used when a function or macro is preceded by an empty comment string, rather
 that one with useful documentation.
 
 This message belongs to the basic checker.

cmakelang/parse/argument_nodes.py

@@ -348,7 +348,7 @@ def parse2(cls, ctx, tokens, spec, breakstack):
     tree.spec = spec
     nconsumed = 0
 
-    # Strip off any preceeding whitespace (note that in most cases this has
+    # Strip off any preceding whitespace (note that in most cases this has
     # already been done but in some cases (such ask kwarg subparser) where
     # it hasn't
     while tokens and tokens[0].type in WHITESPACE_TOKENS: