Bug 997293: Enable MDN language-specific highlighting in js/src/doc/Debugger. DONTBUILD r=jorendorff
authorJim Blandy <jimb@mozilla.com>
Mon, 12 May 2014 17:59:50 -0700
changeset 202003 49c7ce97868f3be635e0da74013cb9f48f02ee5f
parent 202002 a7666d470ffbd95a0b3f7b0d3470e102f8b7020e
child 202004 247f04ad3201f4c3a56a35e0da41a52889c72bdb
push id3741
push userasasaki@mozilla.com
push dateMon, 21 Jul 2014 20:25:18 +0000
treeherdermozilla-beta@4d6f46f5af68 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersjorendorff
bugs997293
milestone32.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 997293: Enable MDN language-specific highlighting in js/src/doc/Debugger. DONTBUILD r=jorendorff
js/src/doc/Debugger/Debugger-API.md
js/src/doc/Debugger/Debugger.Object.md
js/src/doc/Debugger/Debugger.Script.md
js/src/doc/Debugger/Debugger.Source.md
--- a/js/src/doc/Debugger/Debugger-API.md
+++ b/js/src/doc/Debugger/Debugger-API.md
@@ -105,43 +105,47 @@ You can try out `Debugger` yourself in F
 1)  Visit the URL `about:config`, and set the `devtools.chrome.enabled`
     preference to `true`:
 
     ![Setting the 'devtools.chrome.enabled' preference][img-chrome-pref]
 
 2)  Save the following HTML text to a file, and visit the file in your
     browser:
 
-        <div onclick="var x = 'snoo'; debugger;">Click me!</div>
+    ```language-html
+    <div onclick="var x = 'snoo'; debugger;">Click me!</div>
+    ```
 
 3)  Open a developer Scratchpad (Menu button > Developer > Scratchpad), and
     select "Browser" from the "Environment" menu. (This menu will not be
     present unless you have changed the preference as explained above.)
 
     ![Selecting the 'browser' context in the Scratchpad][img-scratchpad-browser]
 
 4)  Enter the following code in the Scratchpad:
 
-        // This simply defines 'Debugger' in this Scratchpad;
-        // it doesn't actually start debugging anything.
-        Cu.import("resource://gre/modules/jsdebugger.jsm");
-        addDebuggerToGlobal(window);
+    ```language-js
+    // This simply defines 'Debugger' in this Scratchpad;
+    // it doesn't actually start debugging anything.
+    Cu.import("resource://gre/modules/jsdebugger.jsm");
+    addDebuggerToGlobal(window);
 
-        // Create a 'Debugger' instance.
-        var dbg = new Debugger;
+    // Create a 'Debugger' instance.
+    var dbg = new Debugger;
 
-        // Get the current tab's content window, and make it a debuggee.
-        var w = gBrowser.selectedBrowser.contentWindow.wrappedJSObject;
-        dbg.addDebuggee(w);
+    // Get the current tab's content window, and make it a debuggee.
+    var w = gBrowser.selectedBrowser.contentWindow.wrappedJSObject;
+    dbg.addDebuggee(w);
 
-        // When the debuggee executes a 'debugger' statement, evaluate
-        // the expression 'x' in that stack frame, and show its value.
-        dbg.onDebuggerStatement = function (frame) {
-            alert('hit debugger statement; x = ' + frame.eval('x').return);
-        }
+    // When the debuggee executes a 'debugger' statement, evaluate
+    // the expression 'x' in that stack frame, and show its value.
+    dbg.onDebuggerStatement = function (frame) {
+        alert('hit debugger statement; x = ' + frame.eval('x').return);
+    }
+    ```
 
 5)  In the Scratchpad, ensure that no text is selected, and press the "Run"
     button.
 
 6)  Now, click on the text that says "Click me!" in the web page. This runs
     the `div` element's `onclick` handler. When control reaches the
     `debugger;` statement, `Debugger` calls your callback function, passing
     a `Debugger.Frame` instance. Your callback function evaluates the
--- a/js/src/doc/Debugger/Debugger.Object.md
+++ b/js/src/doc/Debugger/Debugger.Object.md
@@ -86,58 +86,66 @@ from its prototype:
 
     If a function has a given name, its display name is the same as its
     given name. In this case, the `displayName` and `name` properties are
     equal.
 
     If a function has no name, SpiderMonkey attempts to infer an appropriate
     name for it given its context. For example:
 
-        function f() {}          // display name: f (the given name)
-        var g = function () {};  // display name: g
-        o.p = function () {};    // display name: o.p
-        var q = {
-          r: function () {}      // display name: q.r
-        };
+    ```language-js
+    function f() {}          // display name: f (the given name)
+    var g = function () {};  // display name: g
+    o.p = function () {};    // display name: o.p
+    var q = {
+      r: function () {}      // display name: q.r
+    };
+    ```
 
     Note that the display name may not be a proper JavaScript identifier,
     or even a proper expression: we attempt to find helpful names even when
     the function is not immediately assigned as the value of some variable
     or property. Thus, we use <code><i>a</i>/<i>b</i></code> to refer to
     the <i>b</i> defined within <i>a</i>, and <code><i>a</i>&lt;</code> to
     refer to a function that occurs somewhere within an expression that is
     assigned to <i>a</i>. For example:
 
-        function h() {
-          var i = function() {};    // display name: h/i
-          f(function () {});        // display name: h/<
-        }
-        var s = f(function () {});  // display name: s<
+    ```language-js
+    function h() {
+      var i = function() {};    // display name: h/i
+      f(function () {});        // display name: h/<
+    }
+    var s = f(function () {});  // display name: s<
+    ```
 
 `parameterNames`
 :   If the referent is a debuggee function, the names of the its parameters,
     as an array of strings. If the referent is not a debuggee function, or
     not a function at all, this is `undefined`.
 
     If the referent is a host function for which parameter names are not
     available, return an array with one element per parameter, each of which
     is `undefined`.
 
     If the referent is a function proxy, return an empty array.
 
     If the referent uses destructuring parameters, then the array's elements
     reflect the structure of the parameters. For example, if the referent is
     a function declared in this way:
 
-        function f(a, [b, c], {d, e:f}) { ... }
+    ```language-js
+    function f(a, [b, c], {d, e:f}) { ... }
+    ```
 
     then this `Debugger.Object` instance's `parameterNames` property would
     have the value:
 
-        ["a", ["b", "c"], {d:"d", e:"f"}]
+    ```language-js
+    ["a", ["b", "c"], {d:"d", e:"f"}]
+    ```
 
 `script`
 :   If the referent is a function that is debuggee code, this is that
     function's script, as a [`Debugger.Script`][script] instance. If the
     referent is a function proxy or not debuggee code, this is `undefined`.
 
 `environment`
 :   If the referent is a function that is debuggee code, a
@@ -189,17 +197,19 @@ from its prototype:
 
     By convention, host annotation objects have a string-valued `"type"`
     property that, taken together with the object's class, indicate what
     sort of thing the referent is. The host annotation object's other
     properties provide further details, as appropriate for the type. For
     example, in Firefox, a metadata object for a JavaScript Module's global
     object might look like this:
 
-        { "type":"jsm", "uri":"resource:://gre/modules/XPCOMUtils.jsm" }
+    ```language-js
+    { "type":"jsm", "uri":"resource:://gre/modules/XPCOMUtils.jsm" }
+    ```
 
     Firefox provides [DebuggerHostAnnotationsForFirefox annotations] for its
     host objects.
 
 
 
 ## Function Properties of the Debugger.Object prototype
 
--- a/js/src/doc/Debugger/Debugger.Script.md
+++ b/js/src/doc/Debugger/Debugger.Script.md
@@ -92,22 +92,24 @@ from its prototype:
     is evaluated in the global scope.
 
     Note that a generator's expressions are considered to be part of the
     body of a synthetic function, produced by the compiler.
 
     Scripts' static level be useful in deciding where to set breakpoints.
     For example, a breakpoint set on line 3 in this code:
 
-        function f() {
-          x = function g() {  // line 2
-                              // line 3; no code here
-            ...;
-          }
-        }
+    ```language-js
+    function f() {
+      x = function g() {  // line 2
+                          // line 3; no code here
+        ...;
+      }
+    }
+    ```
 
     should be set in `g`'s script, not in `f`'s, even though neither script
     contains code at that line. In such a case, the most deeply nested
     script—the one with the highest static level—should receive the
     breakpoint.
 
 `strictMode`
 :   This is `true` if this script's code is ECMAScript strict mode code, and
@@ -146,24 +148,28 @@ methods of other kinds of objects.
     instruction offsets and source code positions in this script. <i>L</i>
     is sparse, and indexed by source line number. If a source line number
     <i>line</i> has no code, then <i>L</i> has no <i>line</i> property. If
     there is code for <i>line</i>, then <code><i>L</i>[<i>line</i>]</code> is an array
     of offsets of byte code instructions that are entry points to that line.
 
     For example, suppose we have a script for the following source code:
 
-        a=[]
-        for (i=1; i < 10; i++)
-            // It's hip to be square.
-            a[i] = i*i;
+    ```language-js
+    a=[]
+    for (i=1; i < 10; i++)
+        // It's hip to be square.
+        a[i] = i*i;
+    ```
 
     Calling `getAllOffsets()` on that code might yield an array like this:
 
-        [[0], [5, 20], , [10]]
+    ```language-js
+    [[0], [5, 20], , [10]]
+    ```
 
     This array indicates that:
 
     * the first line's code starts at offset 0 in the script;
 
     * the `for` statement head has two entry points at offsets 5 and 20 (for
       the initialization, which is performed only once, and the loop test,
       which is performed at the start of each iteration);
@@ -188,20 +194,20 @@ methods of other kinds of objects.
     tree.
 
 <code>setBreakpoint(<i>offset</i>, <i>handler</i>)</code>
 :   Set a breakpoint at the bytecode instruction at <i>offset</i> in this
     script, reporting hits to the `hit` method of <i>handler</i>. If
     <i>offset</i> is not a valid offset in this script, throw an error.
 
     When execution reaches the given instruction, SpiderMonkey calls the
-    `hit<code> method of <i>handler</i>, passing a [</code>Debugger.Frame`][frame] instance
-    representing the currently executing stack frame. The `hit` method's
-    return value should be a [resumption value][rv], determining how execution should
-    continue.
+    `hit` method of <i>handler</i>, passing a [`Debugger.Frame`][frame]
+    instance representing the currently executing stack frame. The `hit`
+    method's return value should be a [resumption value][rv], determining
+    how execution should continue.
 
     Any number of breakpoints may be set at a single location; when control
     reaches that point, SpiderMonkey calls their handlers in an unspecified
     order.
 
     Any number of breakpoints may use the same <i>handler</i> object.
 
     Breakpoint handler method calls are cross-compartment, intra-thread
--- a/js/src/doc/Debugger/Debugger.Source.md
+++ b/js/src/doc/Debugger/Debugger.Source.md
@@ -203,10 +203,8 @@ from its prototype:
     the source code, then return `null`.
 
 <code>findScripts(<i>query</i>)</code> <i>(future plan)</i>
 :   Return an array of [`Debugger.Script`][script] instances for all debuggee scripts
     matching <i>query</i> that are produced from this `Debugger.Source`
     instance. Aside from the restriction to scripts produced from this
     source, <i>query</i> is interpreted as for
     `Debugger.prototype.findScripts`.
-
-