Fix markdown code block wrapping which was causing pdf font issues

Author: MungoG

CLAUDE.md

@@ -96,6 +96,29 @@ Rules for all work on WG21 papers in this repository.
     summarize arithmetic or data
 30. Align trailing comment columns when consecutive lines have
     trailing comments
+31. Fenced code blocks must not exceed 80 characters per
+    line. This rule does not apply to mermaid blocks -
+    never reformat mermaid source. When wrapping is
+    needed, follow the conventions for the block's
+    language:
+
+    **C++** - break at a natural syntactic boundary and
+    indent the continuation 4 spaces from the construct
+    it belongs to:
+    - Function signatures: break after the return type,
+      or after the opening parenthesis
+    - Template parameter lists: break after a comma,
+      align with the first parameter or indent 4 spaces
+    - Chained expressions (pipe `|`, `<<`, etc.): break
+      before the operator, align operators vertically
+    - Trailing comments: shorten the gap between code and
+      comment rather than wrapping the code, but keep
+      grouped comments aligned with each other (rule 30)
+    - If shortening the gap is not enough, move the
+      comment to the line above the code it describes
+
+    **Prose in code fences** (markdown, plain text) -
+    wrap at word boundaries with no continuation indent
 
 ## Structure
 

d4003-coroutine-io.html

@@ -837,8 +837,8 @@ <h2 class="toc-title">Table of Contents</h2>
   <li><a href="#revision-history" id="toc-revision-history">Revision
   History</a>
   <ul>
-  <li><a href="#r0-february-2026-pre-tokyo-mailing" id="toc-r0-february-2026-pre-tokyo-mailing">R0: February 2026
-  (pre-Tokyo mailing)</a></li>
+  <li><a href="#r0-february-2026-post-croydon-mailing" id="toc-r0-february-2026-post-croydon-mailing">R0: February 2026
+  (post-Croydon mailing)</a></li>
   </ul></li>
   <li><a href="#the-need-for-escape-hatches" id="toc-the-need-for-escape-hatches">1. The Need for Escape
   Hatches</a></li>
@@ -859,17 +859,17 @@ <h2 id="abstract">Abstract</h2>
 possible.”</p>
 <hr />
 <h2 id="revision-history">Revision History</h2>
-<h3 id="r0-february-2026-pre-tokyo-mailing">R0: February 2026 (pre-Tokyo
-mailing)</h3>
+<h3 id="r0-february-2026-post-croydon-mailing">R0: February 2026
+(post-Croydon mailing)</h3>
 <ul>
 <li>Initial version.</li>
 </ul>
 <hr />
 <h2 id="the-need-for-escape-hatches">1. The Need for Escape Hatches</h2>
 <p>Safe interfaces should be the default. They should validate input,
 maintain invariants, and protect users from misuse. However, C++ also
-needs an explicit path for trusted data - when the invariant is already
-established at a boundary and re-validation is pure overhead.</p>
+needs an explicit path for trusted data - when the precondition is
+already satisfied at a boundary and re-validation is pure overhead.</p>
 <p>This pattern appears in the standard library, in production Boost
 libraries, and in the current <code>cstring_view</code> proposal. Three
 independent examples follow.</p>
@@ -905,7 +905,7 @@ <h2 id="established-practice">3. Established Practice</h2>
 encoding before extracting URL components. Repeating that validation
 would be redundant. A separate function bypasses it at the trusted
 boundary:</p>
-<div class="sourceCode" id="cb3"><pre class="sourceCode cpp"><code class="sourceCode cpp"><span id="cb3-1"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a><span class="co">// Escape hatch: invariant already established by the parser.</span></span>
+<div class="sourceCode" id="cb3"><pre class="sourceCode cpp"><code class="sourceCode cpp"><span id="cb3-1"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a><span class="co">// Escape hatch: precondition already satisfied by the parser.</span></span>
 <span id="cb3-2"><a href="#cb3-2" aria-hidden="true" tabindex="-1"></a>pct_string_view s <span class="op">=</span> make_pct_string_view_unsafe<span class="op">(</span>data<span class="op">,</span> size<span class="op">,</span> decoded_size<span class="op">);</span></span></code></pre></div>
 <p>This pattern was adopted independently by three Boost libraries:
 Boost.URL (<a href="https://github.com/boostorg/url/blob/develop/include/boost/url/pct_string_view.hpp"><code>make_pct_string_view_unsafe</code></a><sup>[4]</sup>),
@@ -918,9 +918,8 @@ <h2 id="application-level">4. Application Level</h2>
 pointer and a filename length via <code>dirent</code>
 (<code>d_name</code> and <code>d_namlen</code>) <a href="https://man.freebsd.org/cgi/man.cgi?query=readdir&amp;sektion=3">FreeBSD
 <code>readdir(3)</code></a><sup>[7]</sup> and <a href="https://cgit.freebsd.org/src/tree/sys/sys/dirent.h">FreeBSD
-<code>dirent.h</code></a><sup>[8]</sup>. The common invariant for path
-components is that names are null-terminated and do not contain embedded
-null bytes <a href="https://pubs.opengroup.org/onlinepubs/9799919799/">POSIX Base
+<code>dirent.h</code></a><sup>[8]</sup>. POSIX requires that path
+components are null-terminated and contain no embedded null bytes <a href="https://pubs.opengroup.org/onlinepubs/9799919799/">POSIX Base
 Definitions</a><sup>[9]</sup>. Rescanning each name in a validating
 constructor repeats work the operating system already did.</p>
 <div class="sourceCode" id="cb4"><pre class="sourceCode cpp"><code class="sourceCode cpp"><span id="cb4-1"><a href="#cb4-1" aria-hidden="true" tabindex="-1"></a><span class="dt">void</span> visit_directory<span class="op">(</span>DIR<span class="op">*</span> dir<span class="op">)</span></span>
@@ -930,22 +929,23 @@ <h2 id="application-level">4. Application Level</h2>
 <span id="cb4-5"><a href="#cb4-5" aria-hidden="true" tabindex="-1"></a>        <span class="at">const</span> <span class="dt">char</span><span class="op">*</span> p <span class="op">=</span> de<span class="op">-&gt;</span>d_name<span class="op">;</span></span>
 <span id="cb4-6"><a href="#cb4-6" aria-hidden="true" tabindex="-1"></a>        <span class="bu">std::</span>size_t n <span class="op">=</span> de<span class="op">-&gt;</span>d_namlen<span class="op">;</span></span>
 <span id="cb4-7"><a href="#cb4-7" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb4-8"><a href="#cb4-8" aria-hidden="true" tabindex="-1"></a>        <span class="co">// Trusted boundary: OS already established the invariant.</span></span>
+<span id="cb4-8"><a href="#cb4-8" aria-hidden="true" tabindex="-1"></a>        <span class="co">// Trusted boundary: OS already satisfied the precondition.</span></span>
 <span id="cb4-9"><a href="#cb4-9" aria-hidden="true" tabindex="-1"></a>        cstring_view name <span class="op">=</span> cstring_view<span class="op">::</span>unsafe<span class="op">(</span>p<span class="op">,</span> n<span class="op">);</span></span>
 <span id="cb4-10"><a href="#cb4-10" aria-hidden="true" tabindex="-1"></a>        consume<span class="op">(</span>name<span class="op">);</span></span>
 <span id="cb4-11"><a href="#cb4-11" aria-hidden="true" tabindex="-1"></a>    <span class="op">}</span></span>
 <span id="cb4-12"><a href="#cb4-12" aria-hidden="true" tabindex="-1"></a><span class="op">}</span></span></code></pre></div>
 <p>The safe path remains the default for untrusted input. The unsafe
-path exists for proven invariants and zero additional runtime cost.</p>
+path exists for proven preconditions and zero additional runtime
+cost.</p>
 <h2 id="conclusion">5. Conclusion</h2>
 <p>The standard library already provides constrained defaults with
 explicit broader counterparts. Production libraries independently
 converge on the same pattern for trusted boundaries. This paper asks for
 no wording and no poll. It asks the committee to recognize a design
 value: safe by default, with explicit escape hatches where zero-cost
 composition requires them.</p>
-<p>The interaction between explicit escape hatches and hardened
-precondition checking is a related question that deserves separate
+<p>How explicit escape hatches interact with Hardening, Contracts, and
+Erroneous Behavior is a related question that deserves separate
 treatment.</p>
 <hr />
 <h1 id="acknowledgements">Acknowledgements</h1>

d4003-coroutine-io.pdf

@@ -1,6 +1,6 @@
 ---
 title: "Coroutines for I/O"
-document: P4003R0
+document: P4003R1
 date: 2026-02-22
 reply-to:
   - "Vinnie Falco <vinnie.falco@gmail.com>"
@@ -157,7 +157,9 @@ struct my_awaitable
     bool await_ready() const noexcept { return false; }
 
     // This signature satisfies IoAwaitable
-    std::coroutine_handle<> await_suspend( std::coroutine_handle<> cont, io_env const* env )
+    std::coroutine_handle<>
+    await_suspend( std::coroutine_handle<> cont,
+                   io_env const* env )
     {
         cont_ = cont;
         env_ = env;
@@ -304,7 +306,9 @@ struct task
     T await_resume() { return h_.promise().result(); }
 
     // Satisfies IoAwaitable
-    std::coroutine_handle<> await_suspend( std::coroutine_handle<> cont, io_env const* env )
+    std::coroutine_handle<>
+    await_suspend( std::coroutine_handle<> cont,
+                   io_env const* env )
     {
         h_.promise().set_continuation( cont );
         h_.promise().set_environment( env );
@@ -434,10 +438,12 @@ A launch function (e.g., `run_async`, `run`) bridges non-coroutine code into the
 
 ```cpp
 template<Executor Ex, class... Args>
-unspecified run_async( Ex ex, Args&&... args );  // returns wrapper, caller invokes with task
+// returns wrapper, caller invokes with task
+unspecified run_async( Ex ex, Args&&... args );
 
 template<Executor Ex, class... Args>
-unspecified run( Ex ex, Args&&... args );        // returns wrapper for co_await
+// returns wrapper for co_await
+unspecified run( Ex ex, Args&&... args );
 ```
 
 **Requirements:**
@@ -594,7 +600,8 @@ concept ExecutionContext =
     requires(X& x) {
         typename X::executor_type;
         requires Executor<typename X::executor_type>;
-        { x.get_executor() } noexcept -> std::same_as<typename X::executor_type>;
+        { x.get_executor() } noexcept
+            -> std::same_as<typename X::executor_type>;
     };
 ```
 
@@ -622,7 +629,8 @@ Coroutine frame allocation has a fundamental timing constraint: `operator new` e
 auto t = my_coro(sock);  // operator new called HERE
 co_await t;              // await_transform kicks in HERE (too late)
 
-spawn( my_coro(sock) );  // my_coro(sock) evaluated BEFORE calling spawn (too late)
+// my_coro(sock) evaluated BEFORE calling spawn (too late)
+spawn( my_coro(sock) );
 ```
 
 ### 5.2 The Awkward Approach
@@ -1262,7 +1270,9 @@ concept io_runnable =
   requires { typename T::promise_type; } &&
   requires(T& t, T const& ct, typename T::promise_type const& cp,
            typename T::promise_type& p) {
-    { ct.handle() } noexcept -> same_as<coroutine_handle<typename T::promise_type>>;
+    { ct.handle() } noexcept
+        -> same_as<coroutine_handle<
+            typename T::promise_type>>;
     { cp.exception() } noexcept -> same_as<exception_ptr>;
     { t.release() } noexcept;
     { p.set_continuation(coroutine_handle<>{}) } noexcept;

d4007-senders-and-coros.html

@@ -1,6 +1,6 @@
 ---
 title: "Senders and Coroutines"
-document: P4007R0
+document: P4007R1
 date: 2026-02-22
 reply-to:
   - "Vinnie Falco <vinnie.falco@gmail.com>"
@@ -165,7 +165,8 @@ read(tcp::socket& sock)
     for (;;)
     {
         auto [ec, n] = co_await sock.read_some(buf);    // also a tuple
-        result.append(buf, n);                          // n bytes arrived regardless of ec
+        // n bytes arrived regardless of ec
+        result.append(buf, n);
         if (ec)
             co_return {ec, std::move(result)};
     }
@@ -206,14 +207,14 @@ sender_of<dynamic_buffer> auto async_read_array(auto handle) {
            return just(std::as_writeable_bytes(std::span(&buf.size, 1)))
                 | async_read(handle)
                 | then(
-                    [&buf] (std::size_t bytes_read) {           // from set_value
+                    [&buf] (std::size_t bytes_read) { // from set_value
                       assert(bytes_read == sizeof(buf.size));
                       buf.data = std::make_unique<std::byte[]>(buf.size);
                       return std::span(buf.data.get(), buf.size);
                     })
                 | async_read(handle)
                 | then(
-                    [&buf] (std::size_t bytes_read) {           // from set_value
+                    [&buf] (std::size_t bytes_read) { // from set_value
                       assert(bytes_read == buf.size);
                       return std::move(buf);
                     });
@@ -412,7 +413,7 @@ do_read(tcp_socket& s, buffer& buf)
 {
     auto [ec, n] = co_await s.async_read(buf);
     if (ec)
-        co_yield with_error(ec);        // unfortunately, terminates the coroutine
+        co_yield with_error(ec); // unfortunately, terminates the coroutine
     co_return n;
 }
 ```
@@ -526,8 +527,10 @@ recycling_allocator<> alloc;
 auto op = connect(
     write_env(
         ex::on(sch,
-            handle_connection(std::move(conn))),   // operator new allocates here...
-        prop(get_allocator, alloc)),               // ...but allocator arrives here
+            // operator new allocates here...
+            handle_connection(std::move(conn))),
+        // ...but allocator arrives here
+        prop(get_allocator, alloc)),
     rcvr);
 start(op);
 ```
@@ -875,9 +878,16 @@ struct read_op
 {
     struct recv_rcvr {
         read_op* self_;
-        void set_value(std::size_t n) && noexcept { self_->completed({}, n); }
-        void set_error(std::error_code ec) && noexcept { self_->completed(ec, 0); }
-        void set_stopped() && noexcept { execution::set_stopped(std::move(self_->rcvr_)); }
+        void set_value(std::size_t n) && noexcept {
+            self_->completed({}, n);
+        }
+        void set_error(std::error_code ec) && noexcept {
+            self_->completed(ec, 0);
+        }
+        void set_stopped() && noexcept {
+            execution::set_stopped(
+                std::move(self_->rcvr_));
+        }
     };
 
     Rcvr rcvr_;
@@ -902,7 +912,8 @@ struct read_op
             return execution::set_value(std::move(rcvr_), bytes_read_);
         if (!ec)
             return start_recv();
-        execution::set_error(std::move(rcvr_), ec);   // bytes_read_ bytes are lost
+        // bytes_read_ bytes are lost
+        execution::set_error(std::move(rcvr_), ec);
     }
 };
 ```

d4007-senders-and-coros.pdf

@@ -1,6 +1,6 @@
 ---
 title: "The Sender Sub-Language"
-document: P4014R0
+document: P4014R1
 date: 2026-02-22
 reply-to:
   - "Vinnie Falco <vinnie.falco@gmail.com>"