Misc RST formatting fixes

doc/json.rst

@@ -63,6 +63,7 @@ because JSON.parse() and JSON.stringify() are intended to be strict interfaces.
 See also:
 
 * http://json.org/
+
 * http://bolinfest.com/essays/json.html
 
 Notes on stringify()

doc/lightweight-function-value.rst

@@ -109,4 +109,3 @@ and don't have an automatic prototype object.
 Even so, there are close to 200 built-in functions, so the footprint of
 the ``duk_hnativefunction`` objects is around 16kB, not taking into account
 allocator overhead.
-

doc/logging.rst

@@ -134,7 +134,9 @@ Each logger object has as its internal prototype ``Duktape.Logger.prototype``.
 The prototype provides:
 
 * ``n``: a default name ('anon')
+
 * ``l``: a default log level (2, info level)
+
 * log writing methods for each level
 
 Lazy formatting
@@ -238,9 +240,13 @@ Existing frameworks and related links
 =====================================
 
 * http://ajaxpatterns.org/Javascript_Logging_Frameworks
+
 * http://getfirebug.com/logging
+
 * http://log4javascript.org/docs/quickstart.html
+
 * http://log4js.berlios.de/
+
 * http://benalman.com/projects/javascript-debug-console-log/
 
 Future work

doc/modules.rst

@@ -252,6 +252,7 @@ have been defined.
 References summarizing several module frameworks:
 
 * http://addyosmani.com/writing-modular-js/
+
 * http://wiki.commonjs.org/wiki/Modules
 
 Module loading APIs or "formats":
@@ -263,9 +264,13 @@ Module loading APIs or "formats":
 * CommonJS:
 
   - http://wiki.commonjs.org/wiki/Modules/1.1.1
+
   - https://github.com/joyent/node/blob/master/lib/module.js
+
   - https://github.com/commonjs/commonjs/tree/master/tests/modules
+
   - http://requirejs.org/docs/commonjs.html
+
   - http://dailyjs.com/2010/10/18/modules/
 
 * NodeJS, more or less CommonJS:

doc/number-conversion.rst

@@ -213,8 +213,11 @@ output.
 Example:
 
 * (123).toFixed(3) -> "123.000"
+
 * (0.1).toFixed(0) -> "0"
+
 * (0.9).toFixed(0) -> "1"  (rounds up)
+
 * (1e21).toFixed(10) -> "1e+21"  (falls back to ToString())
 
 toExponential()
@@ -245,11 +248,16 @@ or if the topmost (most significant) digit has an exponent of -7 or less
 toPrecision() uses an exponent notation.  Examples:
 
 * (1234).toPrecision(4) -> "1234"
+
 * (1234).toPrecision(3) -> "1.23e+3"
+
 * (9876).toPrecision(3) -> "9.88e+3" (rounding up is necessary)
+
 * (9999).toPrecision(3) -> "1.00e+4" (rounding up and carrying over the
   leading digit is necessary)
+
 * (0.000001).toPrecision(2) -> "0.0000010"
+
 * (0.0000001).toPrecision(2) -> "1.0e-7"
 
 Note that leading fractional zeroes are prepended if necessary.  Trailing
@@ -730,4 +738,3 @@ Future work
   as arbitrary radix support, some of the precision modes etc), even if it
   is not fully compatible with Ecmascript semantics.  The impact of custom
   number formatting is about 8-9 kilobytes of code footprint at the moment.
-

doc/release-checklist.rst

@@ -5,9 +5,13 @@ Release checklist
 * Git maintenance
 
   - ensure git commits are up-to-date
+
   - ensure branches are merged, unused branches deleted (also remotely)
+
   - ensure branches are rebased where applicable
+
   - git fsck --full
+
   - git gc --aggressive
 
 * Ditz maintenance
@@ -31,7 +35,9 @@ Release checklist
   build because dist package contains RELEASES.txt)
 
   - New release is in place
+
   - Release log entries match ditz issues
+
   - Release date is in place
 
 * Compilation tests: clean compile with common debug options
@@ -39,16 +45,27 @@ Release checklist
   and with no debug options:
 
   - **FIXME: incomplete list, automate compilation tests**
+
   - Linux x86-64 gcc
+
   - Linux x86-64 gcc + -m32
+
   - Linux x86-64 clang
+
   - Linux x86-64 clang + -m32
+
   - FreeBSD clang
+
   - FreeBSD clang + -m32
+
   - Windows MinGW
+
   - Windows MinGW-w64
+
   - Windows MSVC (cl) x86
+
   - Windows MSVC (cl) x64
+
   - Linux MIPS gcc
 
 * Ecmascript testcases
@@ -58,6 +75,7 @@ Release checklist
   - On x86-64:
 
     - make qecmatest   # quick test
+
     - make vgecmatest  # valgrind test
 
   - Run testcases on all endianness targets
@@ -120,31 +138,40 @@ Release checklist
 * Check source dist contents
 
   - Check file list
+
   - Grep for FIXME and XXX
+
   - Trivial compile test for combined source
+
   - Trivial compile test for separate sources (important because
     it's easy to forget to add files in make_dist.sh)
 
 * Store binaries and update website downloads page
 
   - Release date
+
   - Link
+
   - Date
+
   - "latest" class
 
 * Build website
 
   - Readthrough
+
   - Test that the Duktape REPL (Dukweb) works
 
 * Ditz release
 
   - ``ditz release vN.N``
+
   - git add and commit ditz issues
 
 * Git release and tag
 
   - ``git tag -l -n1`` to list current tags
+
   - ``git tag -s -m "<one line release description>" vN.N.N``
 
 * Upload and test

doc/sorting.rst

@@ -21,10 +21,15 @@ Array.prototype.sort()
 Some desirable qualities:
 
 * Small code footprint
+
 * Bounded C recursion
+
 * In-place sorting (no large temporary allocations)
+
 * O(n log n) average performance (weaker)
+
 * O(n log n) worst case performance (stronger)
+
 * Stability (don't reorder elements which compare equal)
 
 C recursion is effectively bounded if recursion depth is O(log n) for a small
@@ -86,4 +91,3 @@ elements are expected to be almost always already in order.
 
 Current algorithm used is insertion sort, which works well in-place and
 handles already (almost) ordered cases efficiently.
-

doc/test262-status.rst

@@ -36,10 +36,13 @@ cases to fail:
 * Duktape follows the E5.1 regexp syntax strictly (except for allowing the
   ``\$`` identity escape).  Some things that fail in test cases:
 
-    - invalid backreferences (e.g. ``/\1/``)
-    - invalid identity escapes (e.g. ``/\a/``)
-    - invalid decimal escapes in character classes (e.g. ``[\12-\14]``)
-    - special characters appearing literally without escape (e.g. ``]``)
+  - invalid backreferences (e.g. ``/\1/``)
+
+  - invalid identity escapes (e.g. ``/\a/``)
+
+  - invalid decimal escapes in character classes (e.g. ``[\12-\14]``)
+
+  - special characters appearing literally without escape (e.g. ``]``)
 
 * Duktape has a conservative limit on the C recursion required to execute
   regexps.  This limit can cause several test cases to fail.
@@ -392,9 +395,13 @@ Arrays over 2G elements long will probably have such issues.  There are
 several similar failing test cases, e.g.:
 
 * ch15/15.4/15.4.4/15.4.4.12/S15.4.4.12_A3_T3
+
 * ch15/15.4/15.4.4/15.4.4.14/15.4.4.14-9-9
+
 * ch15/15.4/15.4.4/15.4.4.15/15.4.4.15-5-12
+
 * ch15/15.4/15.4.4/15.4.4.15/15.4.4.15-5-16
+
 * ch15/15.4/15.4.4/15.4.4.15/15.4.4.15-8-9
 
 Fortunately these don't have much real world relevance.

doc/testcases.rst

@@ -227,5 +227,3 @@ Future work
 
 * Keep simple input-output model but add includes.  There is a lot of
   boilerplate now for basic things like dumping descriptors.
-
-

doc/uri.rst

@@ -116,4 +116,3 @@ It would be nice to be able to:
 Because the API requirements are strict, these cannot be added to the standard
 API without breaking compliance.  Custom URI encoding/decoding functions could
 provide these extended semantics.
-