Spelling fixes, thanks to @jschleus.

Author: balthisar

README/CODESTYLE.md

@@ -16,7 +16,7 @@ From reading of the Tidy source, some things are self evident,  in no particular
 
  - Use of 4-space indenting, and no tabs.
  - No C++ single line comments using `//`.
- - The openning `{` is indented on the next newline.
+ - The opening `{` is indented on the next newline.
  - While the maximum code line length varies, generally long `if`, `while`, ... statements are wrapped to newlines.
  - Pointer operators in declarations must precede any macro documentation, e.g, `const tidyLocaleMapItem* TIDY_CALL getNextWindowsLanguage( TidyIterator* iter )` instead of `const tidyLocaleMapItem TIDY_CALL *getNextWindowsLanguage( TidyIterator* iter )` in case `TIDY_CALL` is defined.
 

README/MESSAGES.md

@@ -36,6 +36,6 @@ Note that Tidy doesn't currently support numbered `printf` parameters; parameter
 
 The last step — hopefully — is adding the message key to the `dispatchTable[]` structure in `message.c`. This structure determines the `TidyReportLevel` (report severity) and message formatter (how to print the message). Then whenever you issue the report with `TY_(Report)()` or one of the existing convenience report functions, the correct message formatter will be used for the parameters that you specify.
 
-Please read the source code in `message.c` for help on how to choose a message formatter, or how to modify one of the existing message formatters if you need to accomodate a new function signature for your report.
+Please read the source code in `message.c` for help on how to choose a message formatter, or how to modify one of the existing message formatters if you need to accommodate a new function signature for your report.
 
 eof;

README/OPTIONS.md

@@ -2,7 +2,7 @@
 
 Tidy supports a quite large number of configuration options. The full list can be output using `-help-config`. This will show the option to be used either on the command line or in a configuration file, the type of option, and the value(s) that can be used. The current default value for each option can be seen using `-show-config`.
 
-The options can also be listed in xml format. `-xml-help` will output each option plus a description. `-xml-config` will not only output the option and a desciption, but will include the type, default and examples. These xml outputs are used, with the aid of `xsltproc` and `doxygen`, to generate the [API Documentation](http://api.html-tidy.org/).
+The options can also be listed in xml format. `-xml-help` will output each option plus a description. `-xml-config` will not only output the option and a description, but will include the type, default and examples. These xml outputs are used, with the aid of `xsltproc` and `doxygen`, to generate the [API Documentation](http://api.html-tidy.org/).
 
 These options can also be used by application linking with `libtidy`. For each option there is a `TidyOptionId` enumeration in the `tidyenum.h` file, and get/set functions for each option type.
 
@@ -17,7 +17,7 @@ This file indicates how to add a new option to tidy, here adding an option `Tidy
 
 In `tidyenum.h` the `TidyOptionId` can be in any order, but please try to keep things alphabetical, and keep in mind that `N_TIDY_OPTIONS` must remain the last. Choosing the id name can be any string, but by convention it will commence with `Tidy` followed by brief descriptive text.
 
-Naturally it can not be the same as any exisitng option. That is, it must be unique. And it will be followed by a brief descriptive special doxygen formatted comment. So for this new option I have chosen -
+Naturally it can not be the same as any existing option. That is, it must be unique. And it will be followed by a brief descriptive special doxygen formatted comment. So for this new option I have chosen -
 
 ~~~
   TidyEscapeScripts,       /**< Escape items that look like closing tags */
@@ -105,7 +105,7 @@ The `key` is the option `ID`; The `pluralForm` is not used for options, and shou
 
 Some care has to be taken with the description string. The only html allowed here is `<code>...</code>`, `<var>...</var>`, `<em>...</em>`, `<strong>...</strong>`, and `<br/>`. Entities, tags, attributes, etc., should be enclosed in `<code>...</code>`. Option values should be enclosed in `<var>...</var>`. It's very important that `<br/>` be self-closing! This string is processed to build the API documentation.
 
-This is the desription added for this new option.
+This is the description added for this new option.
 
 ~~~
     {

README/README.html

@@ -11,7 +11,7 @@ <h2 id="prerequisites">Prerequisites</h2>
 
 <p>CMake comes in two forms - command line and GUI. Some installations only install one or the other, but sometimes both. The build commands below are only for command line use.</p>
 
-<p>Also the actual build tools vary for each platform. But that is one of the great features of CMake, it can generate variuous &#8216;native&#8217; build files. Running <code>cmake --help</code> should list the generators available on that platform. For sure one of the common ones is &#8220;Unix Makefiles&#8221;, which needs autotools make installed, but many other generators are supported.</p>
+<p>Also the actual build tools vary for each platform. But that is one of the great features of CMake, it can generate various &#8216;native&#8217; build files. Running <code>cmake --help</code> should list the generators available on that platform. For sure one of the common ones is &#8220;Unix Makefiles&#8221;, which needs autotools make installed, but many other generators are supported.</p>
 
 <p>In Windows CMake offers various versions for MSVC. Again below only the command line use of MSVC is shown, but the tidy solution (*.sln) file can be loaded into the MSVC IDE, and the building done in there.</p>
 

README/TAGS.md

@@ -2,7 +2,7 @@
 
 This is about adding a new HTML **tag**.
 
-Tidy tries to support all **tags** supported by the W3C. To add a new supported **tag**, the defintion begins in `tidyenum.h`, to give it a value. Then it is added to the `tag_defs[]` table in `tags.c`, where it is given a unique string, supported html versions, attributes support, and a bit `type`.
+Tidy tries to support all **tags** supported by the W3C. To add a new supported **tag**, the definition begins in `tidyenum.h`, to give it a value. Then it is added to the `tag_defs[]` table in `tags.c`, where it is given a unique string, supported html versions, attributes support, and a bit `type`.
 
 Note, there are a group of configuration options to add **tags** not yet approved by the W3C. These are [new-blocklevel-tags](http://api.html-tidy.org/tidy/quickref_5.2.0.html#new-blocklevel-tags), [new-empty-tags](http://api.html-tidy.org/tidy/quickref_5.2.0.html#new-empty-tags), [new-inline-tags](http://api.html-tidy.org/tidy/quickref_5.2.0.html#new-inline-tags). and [new-pre-tags](http://api.html-tidy.org/tidy/quickref_5.2.0.html#new-pre-tags). This provides a way to extend the `tag_defs[]` table just for that tidy session.
 

README/TESTING.md

@@ -37,7 +37,7 @@ write at least one test case in `github-cases` and put the expected results in
 importantly, will become part of the standard regression testing suite once the
 PR is merged.
 
-Try to keep your test case(s) as succint as possible, and do try to put some HTML
+Try to keep your test case(s) as succinct as possible, and do try to put some HTML
 comments in the file explaining the purpose of the test case, and if applicable,
 the Github issue and/or PR number.
 
@@ -69,4 +69,4 @@ determined that a standards change #yyyy impacts us because of zzz.
 
 ## Regression Testing Specifics
 
-The regression testing mechanism is described more fully in [regression_testing/README.md](../regression_testing/README.md).
+The regression testing mechanism is described more fully in [regression_testing/README.md](../regression_testing/README.md).

README/VERSION.md

@@ -70,7 +70,7 @@ add_definitions ( -DLIBTIDY_VERSION="${LIBTIDY_VERSION}" )
 add_definitions ( -DRELEASE_DATE="${tidy_YEAR}/${tidy_MONTH}/${tidy_DAY}" )
 ~~~
 
-And in `CMakeLists.txt` there is the posibility to define another macro, when and if required:
+And in `CMakeLists.txt` there is the possibility to define another macro, when and if required:
 
 ~~~
 # add_definitions ( -DRC_NUMBER="D231" )

build/cmake/build-api.sh

@@ -37,7 +37,7 @@ TMPZFIL="../../documentation/$TMPZIP"
 if [ -f "$TMPZFIL" ]; then
     ls -l $TMPZFIL
     echo "$BN: WARNING: Current ZIP will be overwritten!"
-    echo "$BN: DO you want to coninue?"
+    echo "$BN: DO you want to continue?"
     ask
 fi
 
@@ -49,7 +49,7 @@ if [ ! -x "$TMPFIL" ]; then
 fi
 
 if [ -d "$TMPDIR" ]; then
-    echo "$BN: Directory '$TMPDIR' will be deleted prior the documentaion build..."
+    echo "$BN: Directory '$TMPDIR' will be deleted prior the documentation build..."
 fi
 
 ./$TMPFIL -DBUILD_DOCUMENTATION:BOOL=YES

build/cmake/build-me.bat

@@ -66,7 +66,7 @@
 @if "%TMPINDBG%x" == "1x" (
 @echo Will install Debug and Release
 ) else {
-@echo Will only intall Release
+@echo Will only install Release
 )
 @echo.
 

build/win64/build-me.bat

@@ -67,7 +67,7 @@
 @if "%TMPINDBG%x" == "1x" (
 @echo Will install Debug and Release
 ) else (
-@echo Will only intall Release
+@echo Will only install Release
 )
 @echo.