minor clarification regarding keep_alive; fixed some typos
diff --git a/docs/advanced.rst b/docs/advanced.rst
index 9195d57..e8ce71f 100644
--- a/docs/advanced.rst
+++ b/docs/advanced.rst
@@ -515,12 +515,13 @@
one policy named ``keep_alive<Nurse, Patient>``, which indicates that the
argument with index ``Patient`` should be kept alive at least until the
argument with index ``Nurse`` is freed by the garbage collector; argument
-indices start at one, while zero refers to the return value. Arbitrarily many
-call policies can be specified.
+indices start at one, while zero refers to the return value. For methods, index
+one refers to the implicit ``this`` pointer, while regular arguments begin at
+index two. Arbitrarily many call policies can be specified.
-For instance, binding code for a a list append operation that ties the lifetime
-of the newly added element to the underlying container might be declared as
-follows:
+Consider the following example: the binding code for a list append operation
+that ties the lifetime of the newly added element to the underlying container
+might be declared as follows:
.. code-block:: cpp
@@ -542,7 +543,7 @@
=========================
Suppose that instances of two types ``A`` and ``B`` are used in a project, and
-that an ``A`` can easily be converted into a an instance of type ``B`` (examples of this
+that an ``A`` can easily be converted into an instance of type ``B`` (examples of this
could be a fixed and an arbitrary precision number type).
.. code-block:: cpp
@@ -815,7 +816,7 @@
};
The following binding code exposes the ``Matrix`` contents as a buffer object,
-making it possible to cast Matrixes into NumPy arrays. It is even possible to
+making it possible to cast Matrices into NumPy arrays. It is even possible to
completely avoid copy operations with Python expressions like
``np.array(matrix_instance, copy = False)``.
@@ -930,7 +931,7 @@
m.def("vectorized_func", py::vectorize(my_func));
Invoking the function like below causes 4 calls to be made to ``my_func`` with
-each of the the array elements. The significant advantage of this compared to
+each of the array elements. The significant advantage of this compared to
solutions like ``numpy.vectorize()`` is that the loop over the elements runs
entirely on the C++ side and can be crunched down into a tight, optimized loop
by the compiler. The result is returned as a NumPy array of type
@@ -948,7 +949,7 @@
are of type ``numpy.dtype.int64`` but need to be ``numpy.dtype.int32`` and
``numpy.dtype.float32``, respectively)
-Sometimes we might want to explitly exclude an argument from the vectorization
+Sometimes we might want to explicitly exclude an argument from the vectorization
because it makes little sense to wrap it in a NumPy array. For instance,
suppose the function signature was
@@ -1255,7 +1256,7 @@
PYBIND11_MAKE_OPAQUE(std::vector<int>);
-before any binding code (e.g. invocations to ``class_::def()``, etc). This
+before any binding code (e.g. invocations to ``class_::def()``, etc.). This
macro must be specified at the top level, since instantiates a partial template
overload. If your binding code consists of multiple compilation units, it must
be present in every file preceding any usage of ``std::vector<int>``. Opaque