docs: correct spelling and grammar

Author: ivanpanch

doc/acknowledgements.xml

@@ -8,7 +8,7 @@
 <section>
   <title>Acknowledgements</title>
 
-  <para>I'm very gratefull to all the people who helped with the development, 
+  <para>I'm very grateful to all the people who helped with the development, 
     by discussion, fixes, and as users. It was pleasant
     to see all that involvement, which made the library much better than it
     would be otherwise.
@@ -25,7 +25,7 @@
   <para>The formal review lead to numerous comments and enhancements. Pavol
   Droba helped with the option description semantic. Gennadiy Rozental has
   criticised many aspects of the library which caused various simplifications.
-  Pavel Vozenilek did carefull review of the implementation. A number of
+  Pavel Vozenilek did careful review of the implementation. A number of
   comments were made by:
     <itemizedlist>
       <listitem><para>David Abrahams</para></listitem>

doc/design.xml

@@ -74,7 +74,7 @@
       of the library -- ascii and Unicode.
     </para>
 
-    <para>Another important point is that ascii strings are passed though
+    <para>Another important point is that ascii strings are passed through
       without modification. In other words, it's not possible to just convert
       ascii to Unicode and process the Unicode further. The problem is that the
       default conversion mechanism -- the <code>codecvt</code> facet -- might
@@ -85,7 +85,7 @@
       don't support Unicode option names. Unicode support is hard and
       requires a Boost-wide solution. Even comparing two arbitrary Unicode
       strings is non-trivial. Finally, using Unicode in option names is
-      related to internationalization, which has it's own
+      related to internationalization, which has its own
       complexities. E.g. if option names depend on current locale, then all
       program parts and other parts which use the name must be
       internationalized too.
@@ -210,4 +210,4 @@
      sgml-parent-document: ("program_options.xml" "section")
      sgml-set-face: t
      End:
--->
+-->

doc/howto.xml

@@ -23,7 +23,7 @@ options groups/hidden options
     <title>Non-conventional Syntax</title>
 
     <para>Sometimes, standard command line syntaxes are not enough. For
-    example, the gcc compiler has "-frtti" and -fno-rtti" options, and this
+    example, the gcc compiler has "-frtti" and "-fno-rtti" options, and this
     syntax is not directly supported.
     </para>
 
@@ -66,7 +66,7 @@ store(command_line_parser(ac, av).options(desc).extra_parser(reg_foo)
 
     <indexterm><primary>response files</primary></indexterm>
 
-    <para>Some operating system have very low limits of the command line
+    <para>Some operating systems have very low limits of the command line
       length. The common way to work around those limitations is using
       <firstterm>response files</firstterm>.  A response file is just a
       configuration file which uses the same syntax as the command line. If
@@ -304,7 +304,7 @@ void validate(boost::any& v,
       for the value, and in this case is either empty or contains an instance of
       the <code>magic_number</code> class. The second is the list of strings
       found in the next occurrence of the option. The remaining two parameters
-      are needed to workaround the lack of partial template specialization and
+      are needed to work around the lack of partial template specialization and
       partial function template ordering on some compilers.
     </para>
 
@@ -346,7 +346,7 @@ void validate(boost::any& v,
     <emphasis>some</emphasis> Unicode-aware options. They are different from
     ordinary options in that they accept <code>wstring</code> input, and
     process it using wide character streams. Creating an Unicode-aware option
-    is easy: just use the the <code>wvalue</code> function instead of the
+    is easy: just use the <code>wvalue</code> function instead of the
     regular <code>value</code>.
     </para>
 
@@ -379,7 +379,7 @@ locale::global(locale(""));
       implementation, though. The quick test involves three steps:
       <orderedlist>
         <listitem>
-          <para>Go the the "test" directory and build the "test_convert" binary.</para>
+          <para>Go to the "test" directory and build the "test_convert" binary.</para>
         </listitem>
         <listitem>
           <para>Set some non-ascii locale in the environment. On Linux, one can

doc/overview.xml

@@ -50,7 +50,7 @@
     provides a class which stores all option values and that class can be
     freely passed around your program to modules which need access to the
     options. All the other components can be used only in the place where
-    the actual parsing is the done.  However, it might also make sense for the
+    the actual parsing is done.  However, it might also make sense for the
     individual program modules to describe their options and pass them to the
     main module, which will merge all options. Of course, this is only
     important when the number of options is large and declaring them in one
@@ -208,7 +208,7 @@ desc.add_options()
         <para>The description string has one or more paragraphs, separated by
         the newline character ('\n'). When an option is output, the library
         will compute the indentation for options's description. Each of the
-        paragraph is output as a separate line with that intentation. If
+        paragraph is output as a separate line with that indentation. If
         a paragraph does not fit on one line it is spanned over multiple
         lines (which will have the same indentation).
         </para>
@@ -538,21 +538,21 @@ desc.add_options()
       </para>
 
       <para>The environment variables can be parsed with the
-      &parse_environment; function. The function have several overloaded
+      &parse_environment; function. The function has several overloaded
       versions. The first parameter is always an &options_description;
       instance, and the second specifies what variables must be processed, and
       what option names must correspond to it. To describe the second
       parameter we need to consider naming conventions for environment
       variables.</para>
 
       <para>If you have an option that should be specified via environment
-      variable, you need make up the variable's name. To avoid name clashes,
+      variable, you need to make up the variable's name. To avoid name clashes,
       we suggest that you use a sufficiently unique prefix for environment
       variables. Also, while option names are most likely in lower case,
       environment variables conventionally use upper case. So, for an option
       name <literal>proxy</literal> the environment variable might be called
       <envar>BOOST_PROXY</envar>. During parsing, we need to perform reverse
-      conversion of the names. This is accomplished by passing the choosen
+      conversion of the names. This is accomplished by passing the chosen
       prefix as the second parameter of the &parse_environment; function.
       Say, if you pass <literal>BOOST_</literal> as the prefix, and there are
       two variables, <envar>CVSROOT</envar> and <envar>BOOST_PROXY</envar>, the
@@ -588,7 +588,7 @@ desc.add_options()
     representations that are available in C++ literals are not supported by
     lexical_cast, and thus will not work with program_options.</para>
 
-    <para>Booleans a special in that there are multiple ways to come at them. 
+    <para>Booleans are special in that there are multiple ways to come at them. 
     Similar to another value type, it can be specified as <code>("my-option",
     value&lt;bool&gt;())</code>, and then set as:</para>
     <screen>
@@ -648,7 +648,7 @@ example --other-switch
 
           <row>
             <entry>&parse_command_line;</entry>
-            <entry>parses command line (simpified interface)</entry>
+            <entry>parses command line (simplified interface)</entry>
           </row>
 
           <row>

doc/program_options.xml

@@ -70,7 +70,7 @@
     </para>
 
     <para>
-      Now let's see some examples of the library usage in the <xref
+      Now let's see some examples of the library usage in <xref
       linkend="program_options.tutorial"/>.
     </para>
 

include/boost/program_options/cmdline.hpp

@@ -9,7 +9,7 @@
 namespace boost { namespace program_options { namespace command_line_style {
     /** Various possible styles of options.
         
-    There are "long" options, which start with "--" and "short",
+    There are "long" options, which start with "--", and "short",
     which start with either "-" or "/". Both kinds can be allowed or
     disallowed, see allow_long and allow_short. The allowed character
     for short options is also configurable.
@@ -51,7 +51,7 @@ namespace boost { namespace program_options { namespace command_line_style {
         /** Allow to merge several short options together,
             so that "-s -k" become "-sk". All of the options
             but last should accept no parameter. For example, if
-            "-s" accept a parameter, then "k" will be taken as
+            "-s" accepts a parameter, then "k" will be taken as
             parameter, not another short option. 
             Dos-style short options cannot be sticky.
         */

include/boost/program_options/eof_iterator.hpp

@@ -11,12 +11,12 @@
 namespace boost {
 
     /** The 'eof_iterator' class is useful for constructing forward iterators
-        in cases where iterator extract data from some source and it's easy
+        in cases where the iterator extracts data from some source and it's easy
         to detect 'eof' \-- i.e. the situation where there's no data. One
         apparent example is reading lines from a file.
 
         Implementing such iterators using 'iterator_facade' directly would
-        require to create class with three core operation, a couple of
+        require to create class with three core operations, a couple of
         constructors. When using 'eof_iterator', the derived class should define
         only one method to get new value, plus a couple of constructors.
 

include/boost/program_options/errors.hpp

@@ -51,7 +51,7 @@ namespace boost { namespace program_options {
         {}
     };
 
-    /** Class thrown when there are programming error related to style */
+    /** Class thrown when there are programming errors related to style */
     class BOOST_PROGRAM_OPTIONS_DECL BOOST_SYMBOL_VISIBLE invalid_command_line_style : public error {
     public:
         invalid_command_line_style(const std::string& msg)
@@ -83,7 +83,7 @@ namespace boost { namespace program_options {
      *  Options are displayed in "canonical" form
      *      This is the most unambiguous form of the
      *      *parsed* option name and would correspond to
-     *      option_description::format_name()
+     *      option_description::format_name(),
      *      i.e. what is shown by print_usage()
      *  
      *  The "canonical" form depends on whether the option is
@@ -243,7 +243,7 @@ namespace boost { namespace program_options {
      *  It makes no sense to have an option name, when we can't match an option to the
      *      parameter
      *  
-     *  Having this a part of the error_with_option_name hierachy makes error handling
+     *  Having this as part of the error_with_option_name hierarchy makes error handling
      *      a lot easier, even if the name indicates some sort of conceptual dissonance!
      *  
      *   */
@@ -275,7 +275,7 @@ namespace boost { namespace program_options {
 
 
 
-    /** Class thrown when there's ambiguity amoung several possible options. */
+    /** Class thrown when there's ambiguity among several possible options. */
     class BOOST_PROGRAM_OPTIONS_DECL BOOST_SYMBOL_VISIBLE ambiguous_option : public error_with_no_option_name {
     public:
         ambiguous_option(const std::vector<std::string>& xalternatives)

include/boost/program_options/options_description.hpp

@@ -105,7 +105,7 @@ namespace program_options {
 
 
         /** Returns the canonical name for the option description to enable the user to
-            recognised a matching option.
+            recognise a matching option.
             1) For short options ('-', '/'), returns the short name prefixed.
             2) For long options ('--' / '-') returns the first long name prefixed
             3) All other cases, returns the first long name (if present) or the short

include/boost/program_options/parsers.hpp

@@ -150,7 +150,7 @@ namespace boost { namespace program_options {
             instance of basic_option<charT> will be added to result,
             with 'unrecognized' field set to 'true'. It's possible to
             collect all unrecognized options with the 'collect_unrecognized'
-            funciton.
+            function.
         */
         basic_command_line_parser& allow_unregistered();
 
@@ -214,7 +214,7 @@ namespace boost { namespace program_options {
     /** Collects the original tokens for all named options with
         'unregistered' flag set. If 'mode' is 'include_positional'
         also collects all positional options.
-        Returns the vector of origianl tokens for all collected
+        Returns the vector of original tokens for all collected
         options.
     */
     template<class charT>
@@ -254,8 +254,8 @@ namespace boost { namespace program_options {
 
     /** Splits a given string to a collection of single strings which
         can be passed to command_line_parser. The second parameter is
-        used to specify a collection of possible seperator chars used
-        for splitting. The seperator is defaulted to space " ".
+        used to specify a collection of possible separator chars used
+        for splitting. The separator is defaulted to space " ".
         Splitting is done in a unix style way, with respect to quotes '"'
         and escape characters '\'
     */