Automated export from internal guides

PiperOrigin-RevId: 1005568362

csharpguide.md

@@ -434,18 +434,18 @@ removing items from containers while iterating. There are a couple of options:
     that are noisy, obvious, or unimportant.
 *   Encouraged:
 
-    *   When the type is obvious - e.g. `var apple = new Apple();`, or `var
-        request = Factory.Create<HttpRequest>();`
+    *   When the type is obvious - e.g. `var apple = new Apple();`, or
+        `var request = Factory.Create<HttpRequest>();`
     *   For transient variables that are only passed directly to other methods -
         e.g. `var item = GetItem(); ProcessItem(item);`
 
 *   Discouraged:
 
     *   When working with basic types - e.g. `var success = true;`
-    *   When working with compiler-resolved built-in numeric types - e.g. `var
-        number = 12 * ReturnsFloat();`
-    *   When users would clearly benefit from knowing the type - e.g. `var
-        listOfItems = GetList();`
+    *   When working with compiler-resolved built-in numeric types - e.g.
+        `var number = 12 * ReturnsFloat();`
+    *   When users would clearly benefit from knowing the type - e.g.
+        `var listOfItems = GetList();`
 
 ### Attributes
 

haskellguide.md

@@ -196,8 +196,8 @@ compile with both `-Wall` and `-Werror`, ensuring warnings are not ignored.
 
 In the rare cases when it's necessary to declare an instance in a module which
 contains neither the corresponding class declaration nor the corresponding type
-declaration, warnings about orphans can be suppressed by adding `{-# OPTIONS_GHC
--fno-warn-orphans #-}` line at the top of the relevant file.
+declaration, warnings about orphans can be suppressed by adding
+`{-# OPTIONS_GHC -fno-warn-orphans #-}` line at the top of the relevant file.
 
 <a id="Style"></a>
 

htmlcssguide.md

@@ -190,9 +190,9 @@ Use UTF-8 (no BOM).
 Make sure your editor uses UTF-8 as character encoding, without a byte order
 mark.
 
-Specify the encoding in HTML templates and documents via `<meta
-charset="utf-8">`. Do not specify the encoding of style sheets as these assume
-UTF-8.
+Specify the encoding in HTML templates and documents via
+`<meta charset="utf-8">`. Do not specify the encoding of style sheets as these
+assume UTF-8.
 
 (More on encodings and when and how to specify them can be found in
 [Handling character encodings in HTML and CSS](https://www.w3.org/International/tutorials/tutorial-char-enc/).)

jsoncguide.md

@@ -1059,8 +1059,8 @@ Property Value Type: `integer` \
 Parent: `data`
 
 The total number of pages in the result set. `totalPages` can also be calculated
-from the item-based paging properties above: `totalPages = ceiling(totalItems /
-itemsPerPage)`.
+from the item-based paging properties above:
+`totalPages = ceiling(totalItems / itemsPerPage)`.
 
 Example:
 

lispguide.md

@@ -1104,8 +1104,8 @@ are rare. The problem is that handling all conditions can mask program bugs. If
 you need to handle "all conditions", you MUST handle only `error`, *not* `t` and
 not `serious-condition`.
 
-`(error (make-condition 'foo-error ...))` is equivalent to `(error 'foo-error
-...)` — code must use the shorter form.
+`(error (make-condition 'foo-error ...))` is equivalent to
+`(error 'foo-error ...)` — code must use the shorter form.
 
 Do not signal conditions from inside the cleanup form of `unwind-protect` or
 otherwise exit non-locally from cleanup handlers outside of the handler e.g.
@@ -1633,8 +1633,8 @@ For maximum portability of a library, it is good form that `defmethod`
 definitions should `(declare (ignorable ...))` all the required arguments that
 they are not using. Indeed, some implementations will issue a warning if you
 `(declare (ignore ...))` those arguments, whereas other implementations will
-issue a warning if you fail to `(declare (ignore ...))` them. `(declare
-(ignorable ...))` works on all implementations.
+issue a warning if you fail to `(declare (ignore ...))` them.
+`(declare (ignorable ...))` works on all implementations.
 
 You should avoid excessive nesting of binding forms inside a function. If your
 function ends up with massive nesting, you should probably break it up into
@@ -1751,9 +1751,10 @@ and use of it for optimization should be treated just like any such
 [unsafe operations](lispprogrammingguide.md#unsafe-operations).
 
 Also, you should use `:start` and `:end` arguments to `string=` or
-`string-equal` instead of using `subseq`; e.g. `(string-equal (subseq s1 2 6)
-s2)` should instead be `(string-equal s1 s2 :start1 2 :end1 6)` This is
-preferable because it is clearer and does not cons.
+`string-equal` instead of using `subseq`; e.g.
+`(string-equal (subseq s1 2 6) s2)` should instead be
+`(string-equal s1 s2 :start1 2 :end1 6)` This is preferable because it is
+clearer and does not cons.
 
 You should use `zerop`, `plusp`, or `minusp`, instead of comparing a value to
 `0` or `0.0`.

lispprogrammingguide.md

@@ -218,14 +218,14 @@ which could blow away the stack on long lists (we want to avoid gratuitous
 non-portability in our code).
 
 However, you must be careful not to use `REDUCE` in ways that needlessly
-increase the complexity class of the computation. For instance, `(REDUCE 'STRCAT
-...)` is *O(n\^2)* when an appropriate implementation is only *O(n)*. Moreover,
-`(REDUCE 'APPEND ...)` is also *O(n\^2)* unless you specify `:FROM-END T`. In
-such cases, you MUST NOT use `REDUCE`, and you MUST NOT use `(APPLY 'STRCAT
-...)` or `(APPLY 'APPEND ...)` either. Instead you MUST use proper abstractions
-from a suitable library (that you may have to contribute to) that properly
-handles those cases without burdening users with implementation details. See for
-instance `UIOP:REDUCE/STRCAT`.
+increase the complexity class of the computation. For instance,
+`(REDUCE 'STRCAT ...)` is *O(n\^2)* when an appropriate implementation is only
+*O(n)*. Moreover, `(REDUCE 'APPEND ...)` is also *O(n\^2)* unless you specify
+`:FROM-END T`. In such cases, you MUST NOT use `REDUCE`, and you MUST NOT use
+`(APPLY 'STRCAT ...)` or `(APPLY 'APPEND ...)` either. Instead you MUST use
+proper abstractions from a suitable library (that you may have to contribute to)
+that properly handles those cases without burdening users with implementation
+details. See for instance `UIOP:REDUCE/STRCAT`.
 
 ### NCONC and MAPCAN
 
@@ -291,8 +291,8 @@ the clause uses the format argument.)
 
 `#` parameter, e.g. `"~#[ none~; ~s~; ~s and ~s~]"` \
 Use the number of arguments to format as the number to choose a clause. The same
-as no parameters in all other ways. Here's the full hairy example: `"Items:~#[
-none~; ~S~; ~S and ~S~:;~@{~#[~; and~] ~S~^ ,~}~]."`
+as no parameters in all other ways. Here's the full hairy example:
+`"Items:~#[ none~; ~S~; ~S and ~S~:;~@{~#[~; and~] ~S~^ ,~}~]."`
 
 ### Comparison Operators
 
@@ -551,9 +551,9 @@ or `makunbound` relevant variables.
 -   You must be careful when using a `SATISFIES` clause in a type specifier.
 
 Most Common Lisp implementations can't optimize based on a `SATISFIES` type, but
-many of them offer simple optimizations based on a type of the form `(AND FOO
-(SATISFIES BAR-P))` where the first term of the `AND` clause describes the
-structure of the object without any `SATISFIES` and the second term is the
+many of them offer simple optimizations based on a type of the form
+`(AND FOO (SATISFIES BAR-P))` where the first term of the `AND` clause describes
+the structure of the object without any `SATISFIES` and the second term is the
 `SATISFIES`.
 
 <div class='badcode'></div>

pyguide.md

@@ -192,10 +192,10 @@ Module names can still collide. Some module names are inconveniently long.
     -   `y` conflicts with a common parameter name that is part of the public
         API (e.g., `features`).
     -   `y` is an inconveniently long name.
-    -   `y` is too generic in the context of your code (e.g., `from
-        storage.file_system import options as fs_options`).
-*   Use `import y as z` only when `z` is a standard abbreviation (e.g., `import
-    numpy as np`).
+    -   `y` is too generic in the context of your code (e.g.,
+        `from storage.file_system import options as fs_options`).
+*   Use `import y as z` only when `z` is a standard abbreviation (e.g.,
+    `import numpy as np`).
 
 For example the module `sound.effects.echo` may be imported as follows:
 
@@ -863,8 +863,8 @@ Okay for simple cases.
 #### 2.11.1 Definition
 
 Conditional expressions (sometimes called a “ternary operator”) are mechanisms
-that provide a shorter syntax for if statements. For example: `x = 1 if cond
-else 2`.
+that provide a shorter syntax for if statements. For example:
+`x = 1 if cond else 2`.
 
 <a id="s2.11.2-pros"></a>
 <a id="2112-pros"></a>
@@ -1095,8 +1095,8 @@ Use the "implicit" false if at all possible (with a few caveats).
 #### 2.14.1 Definition
 
 Python evaluates certain values as `False` when in a boolean context. A quick
-"rule of thumb" is that all "empty" values are considered false, so `0, None,
-[], {}, ''` all evaluate as false in a boolean context.
+"rule of thumb" is that all "empty" values are considered false, so
+`0, None, [], {}, ''` all evaluate as false in a boolean context.
 
 <a id="s2.14.2-pros"></a>
 <a id="2142-pros"></a>
@@ -1124,8 +1124,8 @@ May look strange to C/C++ developers.
 
 #### 2.14.4 Decision
 
-Use the "implicit" false if possible, e.g., `if foo:` rather than `if foo !=
-[]:`. There are a few caveats that you should keep in mind though:
+Use the "implicit" false if possible, e.g., `if foo:` rather than
+`if foo != []:`. There are a few caveats that you should keep in mind though:
 
 -   Always use `if foo is None:` (or `is not None`) to check for a `None` value.
     E.g., when testing whether a variable or argument that defaults to `None`
@@ -1447,9 +1447,9 @@ import to enable them on a per-file basis within earlier runtimes.
 
 #### 2.20.1 Definition
 
-Being able to turn on some of the more modern features via `from __future__
-import` statements allows early use of features from expected future Python
-versions.
+Being able to turn on some of the more modern features via
+`from __future__ import` statements allows early use of features from expected
+future Python versions.
 
 <a id="s2.20.2-pros"></a>
 <a id="2202-pros"></a>
@@ -2246,9 +2246,10 @@ aptly described using a one-line docstring.
 :   Describe the semantics of the return value, including any type information
     that the type annotation does not provide. If the function only returns
     None, this section is not required. It may also be omitted if the docstring
-    starts with "Return", "Returns", "Yield", or "Yields" (e.g. `"""Returns row
-    from Bigtable as a tuple of strings."""`) *and* the opening sentence is
-    sufficient to describe the return value. Do not imitate older 'NumPy style'
+    starts with "Return", "Returns", "Yield", or "Yields" (e.g.
+    `"""Returns row from Bigtable as a tuple of strings."""`) *and* the opening
+    sentence is sufficient to describe the return value. Do not imitate older
+    'NumPy style'
     ([example](https://numpy.org/doc/1.24/reference/generated/numpy.linalg.qr.html)),
     which frequently documented a tuple return value as if it were multiple
     return values with individual names (never mentioning the tuple). Instead,
@@ -3009,8 +3010,9 @@ grouped from most generic to least generic:
     imports.
 
 Within each grouping, imports should be sorted lexicographically, ignoring case,
-according to each module's full package path (the `path` in `from path import
-...`). Code may optionally place a blank line between import sections.
+according to each module's full package path (the `path` in
+`from path import ...`). Code may optionally place a blank line between import
+sections.
 
 <div class='goodcode'></div>
 
@@ -3189,8 +3191,8 @@ Always use a `.py` filename extension. Never use dashes.
 -   Use CapWords for class names, but lower\_with\_under.py for module names.
     Although there are some old modules named CapWords.py, this is now
     discouraged because it's confusing when the module happens to be named after
-    a class. ("wait -- did I write `import StringIO` or `from StringIO import
-    StringIO`?")
+    a class. ("wait -- did I write `import StringIO` or
+    `from StringIO import StringIO`?")
 
     -   Note that [PEP 8 says][PEP-8-acronyms]: "When using acronyms in
         CapWords, capitalize all the letters of the acronym. Thus
@@ -3724,8 +3726,8 @@ _ShortName: TypeAlias = other_module.SignificantlyInconvenientlyLongName
 
 #### 3.19.7 Ignoring Types
 
-You can disable type checking on a line with the special comment `# type:
-ignore`.
+You can disable type checking on a line with the special comment
+`# type: ignore`.
 
 `pytype` has a disable option for specific errors (similar to lint):
 
@@ -3967,8 +3969,8 @@ needed for type checking must be avoided at runtime. This pattern is
 discouraged; alternatives such as refactoring the code to allow top-level
 imports should be preferred.
 
-Imports that are needed only for type annotations can be placed within an `if
-TYPE_CHECKING:` block.
+Imports that are needed only for type annotations can be placed within an
+`if TYPE_CHECKING:` block.
 
 -   Conditionally imported types need to be referenced as strings, to be forward
     compatible with Python 3.6 where the annotation expressions are actually

rustguide.md

@@ -194,9 +194,9 @@ contain one or more `.rs` files.
 
 Additional considerations:
 
-*   The root module is allowed to `re-export` public APIs from `leaf
-    submodules`, making submodules an implementation detail of the crate (as
-    users don't need to know about these submodules).
+*   The root module is allowed to `re-export` public APIs from
+    `leaf submodules`, making submodules an implementation detail of the crate
+    (as users don't need to know about these submodules).
 
 *   This rule about small crates applies equally to crates with and without
     submodules. First, evaluate whether the APIs need to be in the same crate,
@@ -415,8 +415,9 @@ consistency and a minor edge on reading code without xrefs.
 ### Type names should be imported and used unqualified
 
 By default, types and traits should be referenced in code without using their
-module path, e.g., code should use `Regex`, not `regex::Regex`, with a `use
-regex::Regex` at the top of the file or potentially in the relevant function.
+module path, e.g., code should use `Regex`, not `regex::Regex`, with a
+`use regex::Regex` at the top of the file or potentially in the relevant
+function.
 
 Exceptions:
 
@@ -767,8 +768,8 @@ proactively, while application code should add trait impls as needed.
 ### Implement known standard library traits instead of custom methods
 
 If a method matches the purpose and behavior of a standard library trait,
-implement that trait. For example, instead of writing `fn from_str(&str) ->
-Self` on `Foo`, you should `impl FromStr for Foo`.
+implement that trait. For example, instead of writing
+`fn from_str(&str) -> Self` on `Foo`, you should `impl FromStr for Foo`.
 
 It is acceptable to have both the method and the trait impl for discoverability
 reasons.
@@ -951,8 +952,8 @@ a function should implement `Default`.
 
 Rationale
 
-This enables convenient use of struct update syntax (`Struct { a: 0,
-..Default::default()}` ).
+This enables convenient use of struct update syntax
+(`Struct { a: 0, ..Default::default()}` ).
 
 <a id="concurrency"></a>
 
@@ -1356,10 +1357,10 @@ If an enum is part of a public API used by other teams, mark it
 Exceptions:
 
 *   The enum will never change. For example:
-    *   Enums describing an existing ontology (e.g., `enum Color { Red, Green,
-        Blue }`).
-    *   Enums with two states that could be Booleans (e.g., `enum Visibility {
-        Visible, Hidden }`)
+    *   Enums describing an existing ontology (e.g.,
+        `enum Color { Red, Green, Blue }`).
+    *   Enums with two states that could be Booleans (e.g.,
+        `enum Visibility { Visible, Hidden }`)
 *   The enum *may* change in the future, but you are committed to fixing
     resulting breakages via an LSC.
 
@@ -1368,9 +1369,9 @@ For context, see Clippy lint
 
 Rationale
 
-Marking an enum `#[non_exhaustive]` forces users to include a wildcard arm (`_
-=> ...`) in `match` statements. This ensures code continues to compile when new
-variants are added to the enum later.
+Marking an enum `#[non_exhaustive]` forces users to include a wildcard arm
+(`_ => ...`) in `match` statements. This ensures code continues to compile when
+new variants are added to the enum later.
 
 This rule is primarily important for enums used across team boundaries, because
 the scope of the breakage could be significant. Enums used only a small number
@@ -1557,8 +1558,8 @@ fn process_shape(shape: Shape) {
 
 Exceptions:
 
-*   You only care about specific variants *and* `match` is cleaner than `if
-    let`.
+*   You only care about specific variants *and* `match` is cleaner than
+    `if let`.
 
 This is covered by the built-in lint `non_exhaustive_omitted_patterns` which you
 can enable on your code.

shellguide.md

@@ -999,12 +999,12 @@ done
 echo "${last_line}"
 ```
 
-> Note: Be cautious using a for-loop to iterate over output, as in `for var in
-> $(...)`, as the output is split by whitespace, not by line. Sometimes you will
-> know this is safe because the output can't contain any unexpected whitespace,
-> but where this isn't obvious or doesn't improve readability (such as a long
-> command inside `$(...)`), a `while read` loop or `readarray` is often safer
-> and clearer.
+> Note: Be cautious using a for-loop to iterate over output, as in
+> `for var in $(...)`, as the output is split by whitespace, not by line.
+> Sometimes you will know this is safe because the output can't contain any
+> unexpected whitespace, but where this isn't obvious or doesn't improve
+> readability (such as a long command inside `$(...)`), a `while read` loop or
+> `readarray` is often safer and clearer.
 
 <a id="s6.9-arithmetic"></a>
 

vimscriptfull.md

@@ -607,8 +607,8 @@ Vim plugins should provide any or all of the following: **Commands**,
 
 *   All autocommands should be defined in the `plugin/autocmds.vim` file.
 
-    *   This allows users to disable your autocommands with `Glaive myplugin
-        !plugin[autocmds]`.
+    *   This allows users to disable your autocommands with
+        `Glaive myplugin !plugin[autocmds]`.
 
 *   Declare all autocommands in an `augroup` block.
 
@@ -706,9 +706,10 @@ Vim plugins should provide any or all of the following: **Commands**,
     `plugin/plugs.vim` (separate from standard key mappings).
 
     *   `<Plug>` is a sequence which can not be typed.
-    *   You can do something like `noremap <Plug>namespace#MappingName
-        some_key_sequence` and then users can do `noremap <leader>x
-        <Plug>namespace#MappingName` to take advantage of your pseudo-mapping.
+    *   You can do something like
+        `noremap <Plug>namespace#MappingName some_key_sequence` and then users
+        can do `noremap <leader>x <Plug>namespace#MappingName` to take advantage
+        of your pseudo-mapping.
     *   Pseudo-mappings should **not** be in `plugin/mappings.vim` or they will
         be disabled by default.
     *   Such pseudo-mappings should be named `<Plug>` followed by your plugin