Enable rumdl markdown line-length enforcement and reflowing (#7667)

This should handle over-long lines. I had tried to make the normalize
method work, but it doesn't seem promising and so let's at least enable
this version.

Assisted-by: Antigravity with Gemini

docs/design/generics/appendix-coherence.md

@@ -46,8 +46,9 @@ These last two cases are highlighted as concerns in Rust in
 Since Carbon is bundling interface implementations into types, for the
 convenience and expressiveness that provides, we satisfy those use cases by
 giving the user control over the type of a value. This means having facilities
-for defining new [compatible types](/docs/design/classes.md#compatible-types) with
-different interface implementations, and casting between those types as needed.
+for defining new [compatible types](/docs/design/classes.md#compatible-types)
+with different interface implementations, and casting between those types as
+needed.
 
 ## The "Hashtable Problem"
 

docs/design/generics/appendix-rewrite-constraints.md

@@ -31,9 +31,9 @@ This document explains the rationale for choosing to make
 ## Rewrite constraints
 
 Rewrite constraints are [`where` clauses](details.md#where-constraints) of the
-form `.AssociatedConstant = Value`. Given a checked generic binding `T: A where .B = C`,
-references to `T.(A.B)` are rewritten to `C`. This appendix describes the
-precise rules governing them.
+form `.AssociatedConstant = Value`. Given a checked generic binding `T: A where
+.B = C`, references to `T.(A.B)` are rewritten to `C`. This appendix describes
+the precise rules governing them.
 
 ## Combining constraints with `&`
 

docs/design/generics/details.md

@@ -1123,7 +1123,8 @@ instead.
 
 ### Constraints that don't depend on `.Self`
 
-> **TODO:** Link to section explaining when identifying a facet type happens when
+> **TODO:** Link to section explaining when identifying a facet type happens
+> when
 > [#5168: Forward `impl` declaration of an incomplete interface](/proposals/p005168-forward-impl-declaration-of-an-incomplete-interface.md)
 > is applied to these docs.
 
@@ -1139,11 +1140,11 @@ constraint N(T: type) {
 }
 ```
 
-When the above named constraint is identified as part of a facet type as
-`C impls N(.Self)`, the resulting requirement `Z where .Z1 = {}` is only
+When the above named constraint is identified as part of a facet type as `C
+impls N(.Self)`, the resulting requirement `Z where .Z1 = {}` is only
 constraining `C`, and not `.Self` from the top-level top-level facet type. So we
-require that `C impls (Z where .Z1 = {})` is already true in order to successfully
-identify.
+require that `C impls (Z where .Z1 = {})` is already true in order to
+successfully identify.
 
 ```carbon
 interface Z(V: type) {
@@ -1799,9 +1800,10 @@ be detected in function overloading.
 Since interfaces may only be implemented for a type once, and we limit where
 implementations may be added to a type, there is a need to allow the user to
 switch the type of a value to access different interface implementations. Carbon
-therefore provides [adapters](/docs/design/classes.md#adapters) as a way to create new types
-[compatible with](/docs/design/classes.md#compatible-types) existing types with different
-APIs, in particular with different interface implementations:
+therefore provides [adapters](/docs/design/classes.md#adapters) as a way to
+create new types [compatible with](/docs/design/classes.md#compatible-types)
+existing types with different APIs, in particular with different interface
+implementations:
 
 ```carbon
 interface Printable {
@@ -2675,9 +2677,9 @@ member of another. The `where` operator is not associative, so a type expression
 using multiple must use round parens `(`...`)` to specify grouping.
 
 The scope of a facet type formed by a `where` declaration
-[extends](/docs/design/expressions/member_access.md#extend) the scope of its first
-operand, and the resulting facet type is complete if that scope it extends is
-complete.
+[extends](/docs/design/expressions/member_access.md#extend) the scope of its
+first operand, and the resulting facet type is complete if that scope it extends
+is complete.
 
 > **Comparison with other languages:** Both Swift and Rust use `where` clauses
 > on declarations instead of in the expression syntax. These happen after the
@@ -2863,7 +2865,8 @@ constraint ContainerIsSlice {
 
 The `.Self` construct follows these rules:
 
--   A checked binding `X` introduces a checked generic binding `.Self: type`, where
+-   A checked binding `X` introduces a checked generic binding `.Self: type`,
+    where
 
     references to `.Self` are resolved to `X`. This allows you to use `.Self` as
     an interface parameter as in `X: I(.Self)`.
@@ -3967,11 +3970,11 @@ fn DownCast[T: type](p: T*, generic U: type where .Self extends T) -> U*;
 
 Given a type `U`, define the facet type `CompatibleWith(U)` as follows:
 
-> `CompatibleWith(U)` is a facet type whose values are facets `T` such that
-> `T as type` and `U as type` are
-> [compatible types](/docs/design/classes.md#compatible-types). That is values of `T` and
-> `U` as types can be cast back and forth without any change in representation
-> (for example `T` is an [adapter](#adapting-types) for `U`).
+> `CompatibleWith(U)` is a facet type whose values are facets `T` such that `T
+> as type` and `U as type` are
+> [compatible types](/docs/design/classes.md#compatible-types). That is values
+> of `T` and `U` as types can be cast back and forth without any change in
+> representation (for example `T` is an [adapter](#adapting-types) for `U`).
 
 `CompatibleWith` determines an equivalence relationship between types.
 Specifically, given two types `T1` and `T2`, they are equivalent if
@@ -4819,7 +4822,8 @@ difference.
 #### Prioritization rule
 
 > **TODO:** Document the changes to prioritization adopted in
-> [#5337: Interface extension and `final impl` update](/proposals/p005337-interface-extension-and-final-impl-update.md) and
+> [#5337: Interface extension and `final impl` update](/proposals/p005337-interface-extension-and-final-impl-update.md)
+> and
 > [#7493: Disallow impl in match_first twice](/proposals/p007493-disallow-impl-in-match-first-twice.md).
 
 Since at most one library can contain `impl` definitions with a given type

docs/design/generics/overview.md

@@ -142,8 +142,8 @@ fn SortVector(generic T: Comparable, a: Vector(T)*) { ... }
 ```
 
 The syntax above uses the `generic` keyword to indicate that the parameter named
-`T` is a _checked generic_ parameter. The `template` keyword may be added instead to
-make it a _template generic_.
+`T` is a _checked generic_ parameter. The `template` keyword may be added
+instead to make it a _template generic_.
 
 Given an `i32` vector `iv`, `SortVector(i32, &iv)` is equivalent to
 `SortInt32Vector(&iv)`. Similarly for a `String` vector `sv`,
@@ -527,9 +527,10 @@ cast from `T` to `CDCover`.
 ### Adapting types
 
 Carbon has a mechanism called [adapting types](/docs/design/classes.md#adapters)
-to create new types that are [compatible](/docs/design/classes.md#compatible-types) with
-existing types but with different interface implementations. This could be used
-to add or replace implementations, or define implementations for reuse.
+to create new types that are
+[compatible](/docs/design/classes.md#compatible-types) with existing types but
+with different interface implementations. This could be used to add or replace
+implementations, or define implementations for reuse.
 
 In this example, we have multiple ways of sorting a collection of `Song` values.
 

docs/design/generics/terminology.md

@@ -551,14 +551,16 @@ make it clear that the data representation of the value is not changing, just
 its type as reflected in the API available to manipulate the value.
 
 Casting is indicated explicitly by way of some syntax in the source code. You
-might use a cast to switch between [type adaptations](/docs/design/classes.md#adapters), or to
-be explicit where an implicit conversion would otherwise occur. For now, we are
-saying "`x as y`" is the provisional syntax in Carbon for casting the value `x`
-to the type `y`. Note that outside of generics, the term "casting" includes any
-explicit type change, including those that change the data representation.
+might use a cast to switch between
+[type adaptations](/docs/design/classes.md#adapters), or to be explicit where an
+implicit conversion would otherwise occur. For now, we are saying "`x as y`" is
+the provisional syntax in Carbon for casting the value `x` to the type `y`. Note
+that outside of generics, the term "casting" includes any explicit type change,
+including those that change the data representation.
 
 In contexts where an expression of one type is provided and a different type is
-required, an [implicit conversion](/docs/design/expressions/implicit_conversions.md) is
+required, an
+[implicit conversion](/docs/design/expressions/implicit_conversions.md) is
 performed if it is considered safe to do so. Such an implicit conversion, if
 permitted, always has the same meaning as an explicit cast.
 
@@ -824,9 +826,9 @@ express, for example:
     element type.
 -   An interface may define an associated facet that needs to be constrained to
     implement some interfaces.
--   This type must be [compatible](/docs/design/classes.md#compatible-types) with another type. You
-    might use this to define alternate implementations of a single interfaces,
-    such as sorting order, for a single type.
+-   This type must be [compatible](/docs/design/classes.md#compatible-types)
+    with another type. You might use this to define alternate implementations of
+    a single interfaces, such as sorting order, for a single type.
 
 Note that type constraints can be a restriction on one facet parameter or
 associated facet, or can define a relationship between multiple facets.