Update generated API docs

docs/_html/ppx_minidebug/index.html

@@ -374,7 +374,7 @@
       │3/0│3/1│3/2│3/3│3/4│
       ├───┼───┼───┼───┼───┤
       │4/0│4/1│4/2│4/3│4/4│
-      └───┴───┴───┴───┴───┘ |}</code></pre><h3 id="lexical-scopes-vs.-dynamic-scopes"><a href="#lexical-scopes-vs.-dynamic-scopes" class="anchor"></a>Lexical scopes vs. dynamic scopes</h3><p>We track lexical scoping: every log has access to the <code>entry_id</code> number of the lexical scope it is in. Lexical scopes are computations: bindings, functions, tracked code branches (even if not annotated with an extension point, but always within some <code>ppx_minidebug</code> registered extension point). There is also dynamic scoping: which entry a particular log actually ends up belonging in. Currently, we do not expose the (lexical) entry id of an individual log, except when the log &quot;wandered&quot; out of all dynamic scopes. To be able to locate where such log originates from, pass <code>~print_entry_ids:true</code> when creating the runtime, and look for the header with the log's entry id. Example from the test suite:</p><pre class="language-ocaml"><code>let module Debug_runtime =
+      └───┴───┴───┴───┴───┘ |}</code></pre><h3 id="lexical-scopes-vs.-dynamic-scopes"><a href="#lexical-scopes-vs.-dynamic-scopes" class="anchor"></a>Lexical scopes vs. dynamic scopes</h3><p>We track lexical scoping: every log has access to the <code>entry_id</code> number of the lexical scope it is in. Lexical scopes are computations: bindings, functions, tracked code branches (even if not annotated with an extension point, but always within some <code>ppx_minidebug</code> registered extension point). There is also dynamic scoping: which entry a particular log actually ends up belonging in. We do not expose the (lexical) entry id of an individual log, except when the log &quot;wandered&quot; out of all dynamic scopes, or you passed <code>~verbose_entry_ids:true</code> when creating a runtime. To be able to locate where such log originates from, pass <code>~print_entry_ids:true</code> when creating the runtime, and look for the path line with the log's entry id. When the backend is HTML or Markdown, the entry id is a hyperlink to the anchor of the entry. Example from the test suite:</p><pre class="language-ocaml"><code>let module Debug_runtime =
   (val Minidebug_runtime.debug ~print_entry_ids:true ~values_first_mode:true ())
 in
 let i = 3 in
@@ -476,7 +476,7 @@
   │ └─&quot;test/test_expect_test.ml&quot;:351:12: &lt;for i&gt;
   │   └─&quot;test/test_expect_test.ml&quot;:352:14: _baz
   │     └─_baz = 60
-  └─_bar = () |}]</code></pre><p>If you provide the <code>split_files_after</code> setting, the logging will transition to a new file after the current file exceeds the given number of characters. However, the splits only happen at the &quot;toplevel&quot;, to not interrupt laying out the log trees. If required, you can remove logging indicators from your high-level functions, to bring the deeper logic log trees to the toplevel. This matters when you prefer Markdown output over HTML output -- in my experience, Markdown renderers (VS Code Markdown Preview, GitHub Preview) fail for files larger than 2MB, while browsers easily handle HTML files of over 200MB (including via VS Code Live Preview).</p><h3 id="navigating-large-logs"><a href="#navigating-large-logs" class="anchor"></a>Navigating large logs</h3><p>There are a few ways <code>ppx_minidebug</code> is helpful with large logs. You can:</p><ul><li>Use the HTML backend with foldable trees. Unlike with the Markdown backend, HTML browsers can render really large files.</li><li>Set <code>elapsed_times</code> to see how much time was spent in a subtree even if it is folded.</li><li>Use <code>~time_tagged:Elapsed</code> to keep track of when in the course of the program particular entries are computed.</li><li>Enable the <em>Table of Contents</em> feature by e.g. passing <code>~with_table_of_contents:true</code>; tune <code>toc_entry_minimal_depth</code> and <code>toc_entry_minimal_size</code> so that the tables of contents are concise enough to provide an overview.</li></ul><p>The <em>table of contents</em> generation is enabled via <code>~with_table_of_contents:true</code> (for file-based runtimes -- via <code>table_of_contents_ch</code> for channel-based runtimes). This will create an additional file (name ending in <code>-toc</code>), mirroring the main logs in a summarized way. Selected log headers are output there preserving the tree structure, and there is no folding. The headers are hyperlinks pointing to the main log file (or files, if file splitting is enabled).</p><p>Example demonstrating foldable trees in Markdown:</p><pre class="language-ocaml"><code>module Debug_runtime =
+  └─_bar = () |}]</code></pre><p>If you provide the <code>split_files_after</code> setting, the logging will transition to a new file after the current file exceeds the given number of characters. However, the splits only happen at the &quot;toplevel&quot;, to not interrupt laying out the log trees. If required, you can remove logging indicators from your high-level functions, to bring the deeper logic log trees to the toplevel. This matters when you prefer Markdown output over HTML output -- in my experience, Markdown renderers (VS Code Markdown Preview, GitHub Preview) fail for files larger than 2MB, while browsers easily handle HTML files of over 200MB (including via VS Code Live Preview).</p><h3 id="navigating-large-logs"><a href="#navigating-large-logs" class="anchor"></a>Navigating large logs</h3><p>There are a few ways <code>ppx_minidebug</code> is helpful with large logs. You can:</p><ul><li>Use the HTML backend with foldable trees. Unlike with the Markdown backend, HTML browsers can render really large files.</li><li>Set <code>elapsed_times</code> to see how much time was spent in a subtree even if it is folded.</li><li>Use <code>~time_tagged:Elapsed</code> to keep track of when in the course of the program particular entries are computed.</li><li>Enable the <em>Table of Contents</em> feature by e.g. passing <code>~with_table_of_contents:true</code>; tune <code>toc_entry_minimal_depth</code> and <code>toc_entry_minimal_size</code> so that the tables of contents are concise enough to provide an overview.</li></ul><p>The <em>table of contents</em> generation is enabled via <code>~with_table_of_contents:true</code> (for file-based runtimes -- via <code>table_of_contents_ch</code> for channel-based runtimes). This will create an additional file (name ending in <code>-toc</code>), mirroring the main logs in a summarized way. Selected log headers are output there preserving the tree structure, and there is no folding. The headers are hyperlinks pointing to the main log file (or files, if file splitting is enabled).</p><p>If you collaborate with someone or take notes, you can pass <code>~print_entry_ids:true</code>. In HTML and Markdown, this will output links to the anchors of the corresponding log entries. You can share them to point to specific log file locations.</p><p>Example demonstrating foldable trees in Markdown:</p><pre class="language-ocaml"><code>module Debug_runtime =
   (val Minidebug_runtime.debug_file ~elapsed_times:Microseconds ~hyperlink:&quot;./&quot;
          ~backend:(`Markdown Minidebug_runtime.default_md_config) ~values_first_mode:true
          ~truncate_children:4 &quot;debugger_sexp_time_spans&quot;)