doc: fix typos
authorMaxime Roussin-Bélanger <maxime.roussinbelanger@gmail.com>
Thu, 17 Dec 2020 20:39:46 +0000 (15:39 -0500)
committerMaxime Roussin-Bélanger <maxime.roussinbelanger@gmail.com>
Thu, 17 Dec 2020 21:03:14 +0000 (16:03 -0500)
doc/publican/protocol-to-docbook.xsl
doc/publican/sources/Protocol.xml
doc/publican/sources/Server.xml
doc/publican/sources/Xwayland.xml

index 210e0db..79c938b 100644 (file)
   </varlistentry>
 </xsl:template>
 
-<!-- enum and bitfield arguemnts -->
+<!-- enum and bitfield arguments -->
 <xsl:template match="arg[@enum]">
   <varlistentry>
     <term><xsl:value-of select="@name"/></term>
index a472f1d..97e9ba2 100644 (file)
            <para>
              The 32-bit object ID.  Generally, the interface used for the new
              object is inferred from the xml, but in the case where it's not
-             specified, a new_id is preceeded by a <code>string</code> specifying
+             specified, a new_id is preceded by a <code>string</code> specifying
              the interface name, and a <code>uint</code> specifying the version.
            </para>
          </listitem>
        <listitem>
          <para>
            The object creation hierarchy must be a tree.  Otherwise,
-           infering object versions from the parent object becomes a much
+           inferring object versions from the parent object becomes a much
            more difficult to properly track.
          </para>
        </listitem>
       creating the object (either client or server).  IDs allocated by the
       client are in the range [1, 0xfeffffff] while IDs allocated by the
       server are in the range [0xff000000, 0xffffffff].  The 0 ID is
-      reserved to represent a null or non-existant object.
+      reserved to represent a null or non-existent object.
 
       For efficiency purposes, the IDs are densely packed in the sense that
       the ID N will not be used until N-1 has been used.  Any ID allocation
index f627d64..2333b1a 100644 (file)
@@ -24,7 +24,7 @@
   </para>
   <para>
     Each open socket to a client is represented by a <link
-    linkend="Server-structwl__client">wl_client</link>.  The equvalent
+    linkend="Server-structwl__client">wl_client</link>.  The equivalent
     of the <link linkend="Client-classwl__proxy">wl_proxy</link> that
     libwayland-client uses to represent an object is <link
     linkend="Server-structwl__resource">wl_resource</link> for
index e439991..7915559 100644 (file)
       Xwayland. It is often nearly impossible to prove that synchronous or
       blocking X11 calls from XWM cannot cause a deadlock, and therefore it is
       strongly recommended to make all X11 communications asynchronous. All
-      Wayland communications are already asynchonous by design.
+      Wayland communications are already asynchronous by design.
     </para>
     <section id="sect-X11-Application-Support-xwm-window-identification">
       <title>Window identification</title>