DOC: Don't use Python highlighting for non-python code

11 files changed, 104 insertions, 50 deletions

diff --git a/doc/neps/nep-0000.rst b/doc/neps/nep-0000.rst
index dcc7f4cf8..590976081 100644
--- a/doc/neps/nep-0000.rst
+++ b/doc/neps/nep-0000.rst
@@ -234,7 +234,9 @@ Header Preamble
 
 Each NEP must begin with a header preamble.  The headers
 must appear in the following order.  Headers marked with ``*`` are
-optional.  All other headers are required. ::
+optional.  All other headers are required.
+
+.. code-block:: rst
 
     :Author: <list of authors' real names and optionally, email addresses>
     :Status: <Draft | Active | Accepted | Deferred | Rejected |
@@ -251,10 +253,14 @@ The Author header lists the names, and optionally the email addresses
 of all the authors of the NEP.  The format of the Author header
 value must be
 
+.. code-block:: rst
+
     Random J. User <address@dom.ain>
 
 if the email address is included, and just
 
+.. code-block:: rst
+
     Random J. User
 
 if the address is not given.  If there are multiple authors, each should be on
diff --git a/doc/neps/nep-0002-warnfix.rst b/doc/neps/nep-0002-warnfix.rst
index dfccd5ab8..a1138b2f1 100644
--- a/doc/neps/nep-0002-warnfix.rst
+++ b/doc/neps/nep-0002-warnfix.rst
@@ -9,6 +9,8 @@ NEP 2 — A proposal to build numpy without warning with a big set of warning fl
 :Date: 2008-09-04
 :Status: Deferred
 
+.. highlight:: c
+
 Executive summary
 =================
 
@@ -23,7 +25,9 @@ Warning flags
 =============
 
 Each compiler detects a different set of potential errors. The baseline will
-be gcc -Wall -W -Wextra. Ideally, a complete set would be nice::
+be gcc -Wall -W -Wextra. Ideally, a complete set would be nice:
+
+.. code-block:: bash
 
   -W -Wall -Wextra -Wstrict-prototypes -Wmissing-prototypes -Waggregate-return
   -Wcast-align -Wcast-qual -Wnested-externs -Wshadow -Wbad-function-cast
@@ -67,9 +71,7 @@ When applied to a variable, one would get::
 
   int foo(int * NPY_UNUSED(dummy))
 
-expanded to
-
-::
+expanded to::
 
    int foo(int * __NPY_UNUSED_TAGGEDdummy __COMP_NPY_UNUSED)
 
diff --git a/doc/neps/nep-0010-new-iterator-ufunc.rst b/doc/neps/nep-0010-new-iterator-ufunc.rst
index 87617f414..358018c46 100644
--- a/doc/neps/nep-0010-new-iterator-ufunc.rst
+++ b/doc/neps/nep-0010-new-iterator-ufunc.rst
@@ -393,7 +393,9 @@ The proposed ‘order=’ flags become as follows:
 ‘K’  a layout equivalent to ‘C’ followed by some permutation of the axes, as close to the layout of the input(s) as possible (“Keep Layout”)
 ===  =====================================================================================
 
-Or as an enum::
+Or as an enum:
+
+.. code-block:: c
 
     /* For specifying array memory layout or iteration order */
     typedef enum {
@@ -416,7 +418,9 @@ parameter to control the layout of their output(s).
 
 The iterator can do automatic casting, and I have created a sequence
 of progressively more permissive casting rules.  Perhaps for 2.0, NumPy
-could adopt this enum as its preferred way of dealing with casting.::
+could adopt this enum as its preferred way of dealing with casting.
+
+.. code-block:: c
 
     /* For specifying allowed casting in operations which support it */
     typedef enum {
@@ -496,7 +500,9 @@ Proposed Iterator Memory Layout
 
 The following struct describes the iterator memory.  All items
 are packed together, which means that different values of the flags,
-ndim, and niter will produce slightly different layouts.  ::
+ndim, and niter will produce slightly different layouts.
+
+.. code-block:: c
 
     struct {
         /* Flags indicate what optimizations have been applied, and
@@ -710,13 +716,17 @@ Construction and Destruction
     Returns NULL if there is an error, otherwise returns the allocated
     iterator.
 
-    To make an iterator similar to the old iterator, this should work.::
+    To make an iterator similar to the old iterator, this should work.
+
+    .. code-block:: c
 
         iter = NpyIter_New(op, NPY_ITER_READWRITE,
                             NPY_CORDER, NPY_NO_CASTING, NULL, 0, NULL);
 
     If you want to edit an array with aligned ``double`` code,
-    but the order doesn't matter, you would use this.::
+    but the order doesn't matter, you would use this.
+
+    .. code-block:: c
 
         dtype = PyArray_DescrFromType(NPY_DOUBLE);
         iter = NpyIter_New(op, NPY_ITER_READWRITE |
@@ -764,7 +774,9 @@ Construction and Destruction
     In ``op_axes[j][i]`` is stored either a valid axis of ``op[j]``, or
     -1 which means ``newaxis``.  Within each ``op_axes[j]`` array, axes
     may not be repeated.  The following example is how normal broadcasting
-    applies to a 3-D array, a 2-D array, a 1-D array and a scalar.::
+    applies to a 3-D array, a 2-D array, a 1-D array and a scalar.
+
+    .. code-block:: c
 
         npy_intp oa_ndim = 3;               /* # iteration axes */
         npy_intp op0_axes[] = {0, 1, 2};    /* 3-D operand */
@@ -1139,7 +1151,9 @@ Construction and Destruction
     If you want to reset both the ``iterindex`` range and the base
     pointers at the same time, you can do the following to avoid
     extra buffer copying (be sure to add the return code error checks
-    when you copy this code).::
+    when you copy this code).
+
+    .. code-block:: c
 
         /* Set to a trivial empty range */
         NpyIter_ResetToIterIndexRange(iter, 0, 0);
@@ -1190,7 +1204,9 @@ Construction and Destruction
     is used as the source for ``baseptrs``, it will point into a small buffer
     instead of the array and the inner iteration will be invalid.
 
-    The pattern for using nested iterators is as follows.::
+    The pattern for using nested iterators is as follows:
+
+    .. code-block:: c
 
         NpyIter *iter1, *iter1;
         NpyIter_IterNext_Fn iternext1, iternext2;
@@ -1412,7 +1428,9 @@ Functions For Iteration
     non-NULL, the function may be safely called without holding
     the Python GIL.
 
-    The typical looping construct is as follows.::
+    The typical looping construct is as follows:
+
+    .. code-block:: c
 
         NpyIter_IterNext_Fn iternext = NpyIter_GetIterNext(iter, NULL);
         char **dataptr = NpyIter_GetDataPtrArray(iter);
@@ -1422,7 +1440,9 @@ Functions For Iteration
         } while(iternext(iter));
 
     When ``NPY_ITER_NO_INNER_ITERATION`` is specified, the typical
-    inner loop construct is as follows.::
+    inner loop construct is as follows:
+
+    .. code-block:: c
 
         NpyIter_IterNext_Fn iternext = NpyIter_GetIterNext(iter, NULL);
         char **dataptr = NpyIter_GetDataPtrArray(iter);
@@ -1451,7 +1471,9 @@ Functions For Iteration
     to become zero when ``iternext()`` returns false, enabling the
     following loop construct.  Note that if you use this construct,
     you should not pass ``NPY_ITER_GROWINNER`` as a flag, because it
-    will cause larger sizes under some circumstances.::
+    will cause larger sizes under some circumstances:
+
+    .. code-block:: c
 
         /* The constructor should have buffersize passed as this value */
         #define FIXED_BUFFER_SIZE 1024
@@ -1571,7 +1593,9 @@ result.
 
 If the input is a reference type, this function will fail.
 To fix this, the code must be changed to specially handle writeable
-references, and add ``NPY_ITER_WRITEABLE_REFERENCES`` to the flags.::
+references, and add ``NPY_ITER_WRITEABLE_REFERENCES`` to the flags:
+
+.. code-block:: c
 
     /* NOTE: This code has not been compiled/tested */
     PyObject *CopyArray(PyObject *arr, NPY_ORDER order)
diff --git a/doc/neps/nep-0011-deferred-ufunc-evaluation.rst b/doc/neps/nep-0011-deferred-ufunc-evaluation.rst
index c40ca56d7..866a774d1 100644
--- a/doc/neps/nep-0011-deferred-ufunc-evaluation.rst
+++ b/doc/neps/nep-0011-deferred-ufunc-evaluation.rst
@@ -41,11 +41,15 @@ For an idea of how to get this kind of behavior in NumPy without
 changing the Python code, consider the C++ technique of
 expression templates. These can be used to quite arbitrarily
 rearrange expressions using
-vectors or other data structures, example,::
+vectors or other data structures, example:
+
+.. code-block:: cpp
 
     A = B + C + D;
 
-can be transformed into something equivalent to::
+can be transformed into something equivalent to:
+
+.. code-block:: cpp
 
     for(i = 0; i < A.size; ++i) {
         A[i] = B[i] + C[i] + D[i];
diff --git a/doc/neps/nep-0012-missing-data.rst b/doc/neps/nep-0012-missing-data.rst
index 0adcea69a..f47feadbd 100644
--- a/doc/neps/nep-0012-missing-data.rst
+++ b/doc/neps/nep-0012-missing-data.rst
@@ -957,6 +957,8 @@ so the later code will raise exceptions as desired.
 C Implementation Details
 ************************
 
+.. highlight:: c
+
 The first version to implement is the array masks, because it is
 the more general approach. The mask itself is an array, but since
 it is intended to never be directly accessible from Python, it won't
@@ -1159,32 +1161,32 @@ Acknowledgments
 In addition to feedback from Travis Oliphant and others at Enthought,
 this NEP has been revised based on a great deal of feedback from
 the NumPy-Discussion mailing list. The people participating in
-the discussion are::
-
-    Nathaniel Smith
-    Robert Kern
-    Charles Harris
-    Gael Varoquaux
-    Eric Firing
-    Keith Goodman
-    Pierre GM
-    Christopher Barker
-    Josef Perktold
-    Ben Root
-    Laurent Gautier
-    Neal Becker
-    Bruce Southey
-    Matthew Brett
-    Wes McKinney
-    Lluís
-    Olivier Delalleau
-    Alan G Isaac
-    E. Antero Tammi
-    Jason Grout
-    Dag Sverre Seljebotn
-    Joe Harrington
-    Gary Strangman
-    Chris Jordan-Squire
-    Peter
+the discussion are:
+
+- Nathaniel Smith
+- Robert Kern
+- Charles Harris
+- Gael Varoquaux
+- Eric Firing
+- Keith Goodman
+- Pierre GM
+- Christopher Barker
+- Josef Perktold
+- Ben Root
+- Laurent Gautier
+- Neal Becker
+- Bruce Southey
+- Matthew Brett
+- Wes McKinney
+- Lluís
+- Olivier Delalleau
+- Alan G Isaac
+- E. Antero Tammi
+- Jason Grout
+- Dag Sverre Seljebotn
+- Joe Harrington
+- Gary Strangman
+- Chris Jordan-Squire
+- Peter
 
 I apologize if I missed anyone.
diff --git a/doc/neps/nep-0013-ufunc-overrides.rst b/doc/neps/nep-0013-ufunc-overrides.rst
index 5c28e9446..698e45738 100644
--- a/doc/neps/nep-0013-ufunc-overrides.rst
+++ b/doc/neps/nep-0013-ufunc-overrides.rst
@@ -102,7 +102,7 @@ Take this example of ufuncs interoperability with sparse matrices.::
                     [ 4,  1,  4]], dtype=int64)
 
     In [5]: np.multiply(a, bsp) # Returns NotImplemented to user, bad!
-    Out[5]: NotImplemted
+    Out[5]: NotImplemented
 
 Returning :obj:`NotImplemented` to user should not happen. Moreover::
 
diff --git a/doc/neps/nep-0025-missing-data-3.rst b/doc/neps/nep-0025-missing-data-3.rst
index 19be3cf1e..ffe208c98 100644
--- a/doc/neps/nep-0025-missing-data-3.rst
+++ b/doc/neps/nep-0025-missing-data-3.rst
@@ -132,6 +132,8 @@ Some example use cases:
 dtype C-level API extensions
 ============================
 
+.. highlight:: c
+
 The `PyArray_Descr`_ struct gains the following new fields::
 
   void * NA_value;
@@ -357,6 +359,8 @@ so convenient as that for NaN values now, but then, NaN values don't have their
 own global singleton.) So for now we stick to scalar indexing just returning
 ``np.NA``, but this can be revisited if anyone objects.
 
+.. highlight:: python
+
 Python API for generic NA support
 =================================
 
diff --git a/doc/neps/nep-0043-extensible-ufuncs.rst b/doc/neps/nep-0043-extensible-ufuncs.rst
index 008cfad5f..974a705e6 100644
--- a/doc/neps/nep-0043-extensible-ufuncs.rst
+++ b/doc/neps/nep-0043-extensible-ufuncs.rst
@@ -572,6 +572,8 @@ fast C-functions and NumPy API creates the new ``ArrayMethod`` or
 ArrayMethod Specifications
 ==========================
 
+.. highlight:: c
+
 These specifications provide a minimal initial C-API, which shall be expanded
 in the future, for example to allow specialized inner-loops.
 
@@ -696,6 +698,7 @@ to contain the following (this may extend in the future)::
         PyType_Slot *slots;
     } PyArrayMethod_Spec;
 
+.. highlight:: python
 
 Discussion and alternatives
 ===========================
@@ -810,10 +813,12 @@ Both are discussed in the next section.
 Error Handling
 """"""""""""""
 
+.. highlight:: c
+
 We expect that future inner-loops will generally set Python errors as soon
 as an error is found. This is complicated when the inner-loop is run without
 locking the GIL.  In this case the function will have to lock the GIL,
-set the Python error and return ``-1`` to indicate an error occurred::
+set the Python error and return ``-1`` to indicate an error occurred:::
 
     int
     inner_loop(PyArrayMethod_Context *context, ..., void *userdata)
@@ -891,6 +896,7 @@ is not set seems convenient, but I am uncertain about it, since I am not
 aware of any similar prior art.  This "scratch space" could also be part of
 the ``context`` in principle.
 
+.. highlight:: python
 
 Reusing existing Loops/Implementations
 ======================================
diff --git a/doc/neps/nep-0045-c_style_guide.rst b/doc/neps/nep-0045-c_style_guide.rst
index f579e4f69..5a2fcf946 100644
--- a/doc/neps/nep-0045-c_style_guide.rst
+++ b/doc/neps/nep-0045-c_style_guide.rst
@@ -10,6 +10,8 @@ NEP 45 — C Style Guide
 :Created: 2012-02-26
 :Resolution: https://github.com/numpy/numpy/issues/11911
 
+.. highlight:: c
+
 Abstract
 --------
 
diff --git a/doc/source/reference/c-api/array.rst b/doc/source/reference/c-api/array.rst
index b22e20818..e9717d59a 100644
--- a/doc/source/reference/c-api/array.rst
+++ b/doc/source/reference/c-api/array.rst
@@ -2353,7 +2353,9 @@ it is possible to do this.
 Defining an :c:type:`NpyAuxData` is similar to defining a class in C++,
 but the object semantics have to be tracked manually since the API is in C.
 Here's an example for a function which doubles up an element using
-an element copier function as a primitive.::
+an element copier function as a primitive.
+
+.. code-block:: c
 
     typedef struct {
         NpyAuxData base;
diff --git a/doc/source/reference/c-api/deprecations.rst b/doc/source/reference/c-api/deprecations.rst
index a382017a2..5b1abc6f2 100644
--- a/doc/source/reference/c-api/deprecations.rst
+++ b/doc/source/reference/c-api/deprecations.rst
@@ -48,7 +48,9 @@ warnings).
 
 To use the NPY_NO_DEPRECATED_API mechanism, you need to #define it to
 the target API version of NumPy before #including any NumPy headers.
-If you want to confirm that your code is clean against 1.7, use::
+If you want to confirm that your code is clean against 1.7, use:
+
+.. code-block:: c
 
     #define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION