docs: Code blocks in SDK docs are broken (#11189)

Author: julienrbrt

.markdownlint.json

@@ -6,6 +6,7 @@
     "MD024": { "siblings_only": true },
     "MD025": false,
     "MD033": false,
+    "MD034": false,
     "no-hard-tabs": false,
     "whitespace": false
 }

CHANGELOG.md

@@ -1665,7 +1665,7 @@ that error is that the account doesn't exist.
     * Added a `ModuleAccount` for the mint module
   [\#4472](https://github.com/cosmos/cosmos-sdk/issues/4472) validation for crisis genesis
 * [\#3985](https://github.com/cosmos/cosmos-sdk/issues/3985) `ValidatorPowerRank` uses potential consensus power instead of tendermint power
-* [\#4104](https://github.com/cosmos/cosmos-sdk/issues/4104) Gaia has been moved to its own repository: <https://github.com/cosmos/gaia>
+* [\#4104](https://github.com/cosmos/cosmos-sdk/issues/4104) Gaia has been moved to its own repository: https://github.com/cosmos/gaia
 * [\#4104](https://github.com/cosmos/cosmos-sdk/issues/4104) Rename gaiad.toml to app.toml. The internal contents of the application
   config remain unchanged.
 * [\#4159](https://github.com/cosmos/cosmos-sdk/issues/4159) create the default module patterns and module manager
@@ -2427,7 +2427,7 @@ BUG FIXES
 * Gaia CLI  (`gaiacli`)
     * [\#3417](https://github.com/cosmos/cosmos-sdk/pull/3417) Fix `q slashing signing-info` panic by ensuring safety of user input and properly returning not found error
     * [\#3345](https://github.com/cosmos/cosmos-sdk/issues/3345) Upgrade ledger-cosmos-go dependency to v0.9.3 to pull
-    <https://github.com/ZondaX/ledger-cosmos-go/commit/ed9aa39ce8df31bad1448c72d3d226bf2cb1a8d1> in order to fix a derivation path issue that causes `gaiacli keys add --recover`
+    https://github.com/ZondaX/ledger-cosmos-go/commit/ed9aa39ce8df31bad1448c72d3d226bf2cb1a8d1 in order to fix a derivation path issue that causes `gaiacli keys add --recover`
     to malfunction.
     * [\#3419](https://github.com/cosmos/cosmos-sdk/pull/3419) Fix `q distr slashes` panic
     * [\#3453](https://github.com/cosmos/cosmos-sdk/pull/3453) The `rest-server` command didn't respect persistent flags such as `--chain-id` and `--trust-node` if they were
@@ -2464,7 +2464,7 @@ BREAKING CHANGES
     * [\#3320](https://github.com/cosmos/cosmos-sdk/pull/3320) Ensure all `gaiacli query` commands respect the `--output` and `--indent` flags
 
 * Gaia
-    * <https://github.com/cosmos/cosmos-sdk/issues/2838> - Move store keys to constants
+    * https://github.com/cosmos/cosmos-sdk/issues/2838 - Move store keys to constants
     * [\#3162](https://github.com/cosmos/cosmos-sdk/issues/3162) The `--gas` flag now takes `auto` instead of `simulate`
     in order to trigger a simulation of the tx before the actual execution.
     * [\#3285](https://github.com/cosmos/cosmos-sdk/pull/3285) New `gaiad tendermint version` to print libs versions
@@ -3097,7 +3097,7 @@ BUG FIXES
     * [docs] Fixed light client section links
 
 * SDK
-    * [\#1988](https://github.com/cosmos/cosmos-sdk/issues/1988) Make us compile on OpenBSD (disable ledger) [#1988] (<https://github.com/cosmos/cosmos-sdk/issues/1988>)
+    * [\#1988](https://github.com/cosmos/cosmos-sdk/issues/1988) Make us compile on OpenBSD (disable ledger)
     * [\#2105](https://github.com/cosmos/cosmos-sdk/issues/2105) Fix DB Iterator leak, which may leak a go routine.
     * [ledger] [\#2064](https://github.com/cosmos/cosmos-sdk/issues/2064) Fix inability to sign and send transactions via the LCD by
     loading a Ledger device at runtime.

CONTRIBUTING.md

@@ -207,7 +207,7 @@ For example, in vscode your `.vscode/settings.json` should look like:
 
 ## Branching Model and Release
 
-User-facing repos should adhere to the trunk based development branching model: <https://trunkbaseddevelopment.com/>. User branches should start with a user name, example: `{moniker}/{issue#}-branch-name`.
+User-facing repos should adhere to the trunk based development branching model: https://trunkbaseddevelopment.com. User branches should start with a user name, example: `{moniker}/{issue#}-branch-name`.
 
 The Cosmos SDK repository is a [multi Go module](https://github.com/golang/go/wiki/Modules#is-it-possible-to-add-a-module-to-a-multi-module-repository) repository. It means that we have more than one Go module in a single repository.
 

cosmovisor/RELEASE_NOTES.md

@@ -3,10 +3,12 @@
 ### New execution model
 
 With this release we are shifting to a new CLI design: 
+
 * in the past, Cosmovisor was designed to act as a wrapper for a Cosmos App. An admin could link it and use it instead of the Cosmos App. When running it will pass all options and configuration  parameters to the app. Hence the only way to configure the Cosmovisor was through environment variables.
 * now, we are moving to a more traditional model, where Cosmovisor has it's own command set and is a true supervisor.
 
 New commands have been added:
+
 * `run` will start the Cosmos App and pass remaining arguments to the app (similar to `npm run`)
 * `help` will display Cosmovisor help
 * `version` will display both Cosmovisor and the associated app version.

crypto/keys/secp256k1/internal/secp256k1/README.md

@@ -1,5 +1,5 @@
 # secp256k1
 
-This package is copied from <https://github.com/ethereum/go-ethereum/tree/729bf365b5f17325be9107b63b233da54100eec6/crypto/secp256k1>
+This package is copied from https://github.com/ethereum/go-ethereum/tree/729bf365b5f17325be9107b63b233da54100eec6/crypto/secp256k1
 
 Unlike the rest of go-ethereum it is MIT licensed so compatible with our Apache2.0 license. We opt to copy in here rather than depend on go-ethereum to avoid issues with vendoring of the GPL parts of that repository by downstream.

docs/DOCS_README.md

@@ -19,7 +19,7 @@ If you want to open a PR in Cosmos SDK to update the documentation, please follo
 
 ## Docs Build Workflow
 
-The documentation for Cosmos SDK is hosted at <https://docs.cosmos.network/> and built from the files in the `/docs` directory.
+The documentation for Cosmos SDK is hosted at https://docs.cosmos.network/ and built from the files in the `/docs` directory.
 
 ### How It Works
 
@@ -84,7 +84,7 @@ Install the theme and all dependencies.
 npm run serve
 ```
 
-Run `pre` and `post` hooks and start a hot-reloading web-server. See output of this command for the URL (it is often <https://localhost:8080>).
+Run `pre` and `post` hooks and start a hot-reloading web-server. See output of this command for the URL (it is often https://localhost:8080).
 
 To build documentation as a static website run `npm run build`. You will find the website in `.vuepress/dist` directory.
 

docs/architecture/adr-002-docs-structure.md

@@ -70,7 +70,7 @@ Accepted
 * Developers only have to update `/docs` folder when they open a PR (and not `/examples` for example).
 * Easier for developers to find what they need to update in the docs thanks to reworked architecture.
 * Cleaner vuepress build for website docs.
-* Will help build an executable doc (cf <https://github.com/cosmos/cosmos-sdk/issues/2611>)
+* Will help build an executable doc (cf https://github.com/cosmos/cosmos-sdk/issues/2611)
 
 ### Neutral
 
@@ -81,6 +81,6 @@ Accepted
 
 ## References
 
-* <https://github.com/cosmos/cosmos-sdk/issues/1460>
-* <https://github.com/cosmos/cosmos-sdk/pull/2695>
-* <https://github.com/cosmos/cosmos-sdk/issues/2611>
+* https://github.com/cosmos/cosmos-sdk/issues/1460
+* https://github.com/cosmos/cosmos-sdk/pull/2695
+* https://github.com/cosmos/cosmos-sdk/issues/2611

docs/architecture/adr-004-split-denomination-keys.md

@@ -115,6 +115,6 @@ None in particular.
 
 ## References
 
-* Ref: <https://github.com/cosmos/cosmos-sdk/issues/4982>
-* Ref: <https://github.com/cosmos/cosmos-sdk/issues/5467>
-* Ref: <https://github.com/cosmos/cosmos-sdk/issues/5492>
+* Ref: https://github.com/cosmos/cosmos-sdk/issues/4982
+* Ref: https://github.com/cosmos/cosmos-sdk/issues/5467
+* Ref: https://github.com/cosmos/cosmos-sdk/issues/5492

docs/architecture/adr-016-validator-consensus-key-rotation.md

@@ -7,7 +7,7 @@
 
 ## Context
 
-Validator consensus key rotation feature has been discussed and requested for a long time, for the sake of safer validator key management policy (e.g. <https://github.com/tendermint/tendermint/issues/1136>). So, we suggest one of the simplest form of validator consensus key rotation implementation mostly onto Cosmos SDK.
+Validator consensus key rotation feature has been discussed and requested for a long time, for the sake of safer validator key management policy (e.g. https://github.com/tendermint/tendermint/issues/1136). So, we suggest one of the simplest form of validator consensus key rotation implementation mostly onto Cosmos SDK.
 
 We don't need to make any update on consensus logic in Tendermint because Tendermint does not have any mapping information of consensus key and validator operator key, meaning that from Tendermint point of view, a consensus key rotation of a validator is simply a replacement of a consensus key to another.
 
@@ -109,7 +109,7 @@ Proposed
 ### Positive
 
 * Validators can immediately or periodically rotate their consensus key to have better security policy
-* improved security against Long-Range attacks (<https://nearprotocol.com/blog/long-range-attacks-and-a-new-fork-choice-rule>) given a validator throws away the old consensus key(s)
+* improved security against Long-Range attacks (https://nearprotocol.com/blog/long-range-attacks-and-a-new-fork-choice-rule) given a validator throws away the old consensus key(s)
 
 ### Negative
 
@@ -120,6 +120,6 @@ Proposed
 
 ## References
 
-* on tendermint repo : <https://github.com/tendermint/tendermint/issues/1136>
-* on cosmos-sdk repo : <https://github.com/cosmos/cosmos-sdk/issues/5231>
-* about multiple consensus keys : <https://github.com/tendermint/tendermint/issues/1758#issuecomment-545291698>
+* on tendermint repo : https://github.com/tendermint/tendermint/issues/1136
+* on cosmos-sdk repo : https://github.com/cosmos/cosmos-sdk/issues/5231
+* about multiple consensus keys : https://github.com/tendermint/tendermint/issues/1758#issuecomment-545291698

docs/architecture/adr-019-protobuf-state-encoding.md

@@ -375,5 +375,5 @@ seamless.
 
 ## References
 
-1. <https://github.com/cosmos/cosmos-sdk/issues/4977>
-2. <https://github.com/cosmos/cosmos-sdk/issues/5444>
+1. https://github.com/cosmos/cosmos-sdk/issues/4977
+2. https://github.com/cosmos/cosmos-sdk/issues/5444

docs/architecture/adr-020-protobuf-transaction-encoding.md

@@ -270,7 +270,7 @@ processors because:
   not `TxBody`)
 
 There are also scenarios where we may choose to safely ignore unknown fields
-(<https://github.com/cosmos/cosmos-sdk/issues/6078#issuecomment-624400188>) to
+(https://github.com/cosmos/cosmos-sdk/issues/6078#issuecomment-624400188) to
 provide graceful forwards compatibility with newer clients.
 
 We propose that field numbers with bit 11 set (for most use cases this is
@@ -379,7 +379,7 @@ can gracefully transition away from Amino JSON.
 
 ### `SIGN_MODE_DIRECT_AUX`
 
-(\*Documented as option (3) in <https://github.com/cosmos/cosmos-sdk/issues/6078#issuecomment-628026933>)
+(\*Documented as option (3) in https://github.com/cosmos/cosmos-sdk/issues/6078#issuecomment-628026933)
 
 We could add a mode `SIGN_MODE_DIRECT_AUX`
 to support scenarios where multiple signatures
@@ -437,7 +437,7 @@ To generate a signature in `SIGN_MODE_DIRECT_AUX` these steps would be followed:
 
 ### `SIGN_MODE_DIRECT_RELAXED`
 
-(_Documented as option (1)(a) in <https://github.com/cosmos/cosmos-sdk/issues/6078#issuecomment-628026933>_)
+(_Documented as option (1)(a) in https://github.com/cosmos/cosmos-sdk/issues/6078#issuecomment-628026933_)
 
 This is a variation of `SIGN_MODE_DIRECT` where multiple signers wouldn't need to
 coordinate public keys and signing modes in advance. It would involve an alternate

docs/architecture/adr-027-deterministic-protobuf-serialization.md

@@ -260,7 +260,7 @@ for all protobuf documents we need in the context of Cosmos SDK signing.
 * Simple enough to keep the barrier to implement transaction signing low
 * It allows us to continue to use 0 and other empty values in SignDoc, avoiding
   the need to work around 0 sequences. This does not imply the change from
-  <https://github.com/cosmos/cosmos-sdk/pull/6949> should not be merged, but not
+  https://github.com/cosmos/cosmos-sdk/pull/6949 should not be merged, but not
   too important anymore.
 
 ### Negative
@@ -288,27 +288,27 @@ the need of implementing a custom serializer that adheres to this standard (and
   implementation detail and the details of any particular implementation may
   change in the future. Therefore, protocol buffer parsers must be able to parse
   fields in any order._ from
-  <https://developers.google.com/protocol-buffers/docs/encoding#order>
-* <sup>2</sup> <https://developers.google.com/protocol-buffers/docs/encoding#signed_integers>
+  https://developers.google.com/protocol-buffers/docs/encoding#order
+* <sup>2</sup> https://developers.google.com/protocol-buffers/docs/encoding#signed_integers
 * <sup>3</sup> _Note that for scalar message fields, once a message is parsed
   there's no way of telling whether a field was explicitly set to the default
   value (for example whether a boolean was set to false) or just not set at all:
   you should bear this in mind when defining your message types. For example,
   don't have a boolean that switches on some behavior when set to false if you
   don't want that behavior to also happen by default._ from
-  <https://developers.google.com/protocol-buffers/docs/proto3#default>
+  https://developers.google.com/protocol-buffers/docs/proto3#default
 * <sup>4</sup> _When a message is parsed, if the encoded message does not
   contain a particular singular element, the corresponding field in the parsed
   object is set to the default value for that field._ from
-  <https://developers.google.com/protocol-buffers/docs/proto3#default>
+  https://developers.google.com/protocol-buffers/docs/proto3#default
 * <sup>5</sup> _Also note that if a scalar message field is set to its default,
   the value will not be serialized on the wire._ from
-  <https://developers.google.com/protocol-buffers/docs/proto3#default>
+  https://developers.google.com/protocol-buffers/docs/proto3#default
 * <sup>6</sup> _For enums, the default value is the first defined enum value,
   which must be 0._ from
-  <https://developers.google.com/protocol-buffers/docs/proto3#default>
+  https://developers.google.com/protocol-buffers/docs/proto3#default
 * <sup>7</sup> _For message fields, the field is not set. Its exact value is
   language-dependent._ from
-  <https://developers.google.com/protocol-buffers/docs/proto3#default>
+  https://developers.google.com/protocol-buffers/docs/proto3#default
 * Encoding rules and parts of the reasoning taken from
   [canonical-proto3 Aaron Craelius](https://github.com/regen-network/canonical-proto3)

docs/architecture/adr-028-public-key-addresses.md

@@ -29,12 +29,12 @@ a security break of one account type shouldn't impact the security of other acco
 One initial proposal was extending the address length and
 adding prefixes for different types of addresses.
 
-@ethanfrey explained an alternate approach originally used in <https://github.com/iov-one/weave>:
+@ethanfrey explained an alternate approach originally used in https://github.com/iov-one/weave:
 
 > I spent quite a bit of time thinking about this issue while building weave... The other cosmos Sdk.
 > Basically I define a condition to be a type and format as human readable string with some binary data appended. This condition is hashed into an Address (again at 20 bytes). The use of this prefix makes it impossible to find a preimage for a given address with a different condition (eg ed25519 vs secp256k1).
-> This is explained in depth here <https://weave.readthedocs.io/en/latest/design/permissions.html>
-> And the code is here, look mainly at the top where we process conditions. <https://github.com/iov-one/weave/blob/master/conditions.go>
+> This is explained in depth here https://weave.readthedocs.io/en/latest/design/permissions.html
+> And the code is here, look mainly at the top where we process conditions. https://github.com/iov-one/weave/blob/master/conditions.go
 
 And explained how this approach should be sufficiently collision resistant:
 
@@ -60,7 +60,7 @@ In the issue we discussed various modifications:
 
 ### Requirements
 
-* Support currently used tools - we don't want to break an ecosystem, or add a long adaptation period. Ref: <https://github.com/cosmos/cosmos-sdk/issues/8041>
+* Support currently used tools - we don't want to break an ecosystem, or add a long adaptation period. Ref: https://github.com/cosmos/cosmos-sdk/issues/8041
 * Try to keep the address length small - addresses are widely used in state, both as part of a key and object value.
 
 ### Scope

docs/architecture/adr-029-fee-grant-module.md

@@ -148,6 +148,6 @@ created to use it
 
 ## References
 
-* Blog article describing initial work: <https://medium.com/regen-network/hacking-the-cosmos-cosmwasm-and-key-management-a08b9f561d1b>
-* Initial public specification: <https://gist.github.com/aaronc/b60628017352df5983791cad30babe56>
-* Original subkeys proposal from B-harvest which influenced this design: <https://github.com/cosmos/cosmos-sdk/issues/4480>
+* Blog article describing initial work: https://medium.com/regen-network/hacking-the-cosmos-cosmwasm-and-key-management-a08b9f561d1b
+* Initial public specification: https://gist.github.com/aaronc/b60628017352df5983791cad30babe56
+* Original subkeys proposal from B-harvest which influenced this design: https://github.com/cosmos/cosmos-sdk/issues/4480

docs/architecture/adr-030-authz-module.md

@@ -244,6 +244,6 @@ SDK users
 
 ## References
 
-* Initial Hackatom implementation: <https://github.com/cosmos-gaians/cosmos-sdk/tree/hackatom/x/delegation>
-* Post-Hackatom spec: <https://gist.github.com/aaronc/b60628017352df5983791cad30babe56#delegation-module>
-* B-Harvest subkeys spec: <https://github.com/cosmos/cosmos-sdk/issues/4480>
+* Initial Hackatom implementation: https://github.com/cosmos-gaians/cosmos-sdk/tree/hackatom/x/delegation
+* Post-Hackatom spec: https://gist.github.com/aaronc/b60628017352df5983791cad30babe56#delegation-module
+* B-Harvest subkeys spec: https://github.com/cosmos/cosmos-sdk/issues/4480

docs/architecture/adr-031-msg-service.md

@@ -41,7 +41,7 @@ This isn’t really documented anywhere and clients would need to know the inter
 of the Cosmos SDK to parse that value and return it to users.
 
 Also, there may be cases where we want to use these return values programatically.
-For instance, <https://github.com/cosmos/cosmos-sdk/issues/7093> proposes a method for
+For instance, https://github.com/cosmos/cosmos-sdk/issues/7093 proposes a method for
 doing inter-module Ocaps using the `Msg` router. A well-defined return type would
 improve the developer UX for this approach.
 

docs/architecture/adr-034-account-rekeying.md

@@ -73,4 +73,4 @@ Breaks the current assumed relationship between address and pubkeys as H(pubkey)
 
 ## References
 
-* <https://www.algorand.com/resources/blog/announcing-rekeying>
+* https://www.algorand.com/resources/blog/announcing-rekeying

docs/architecture/adr-035-rosetta-api-support.md

@@ -208,4 +208,4 @@ Proposed
 
 ## References
 
-* <https://www.rosetta-api.org/>
+* https://www.rosetta-api.org/

docs/architecture/adr-036-arbitrary-signature.md

@@ -126,7 +126,7 @@ Backwards compatibility is maintained as this is a new message spec definition.
 
 ## References
 
-1. <https://github.com/cosmos/ics/pull/33>
-2. <https://github.com/cosmos/cosmos-sdk/pull/7727#discussion_r515668204>
-3. <https://github.com/cosmos/cosmos-sdk/pull/7727#issuecomment-722478477>
-4. <https://github.com/cosmos/cosmos-sdk/pull/7727#issuecomment-721062923>
+1. https://github.com/cosmos/ics/pull/33
+2. https://github.com/cosmos/cosmos-sdk/pull/7727#discussion_r515668204
+3. https://github.com/cosmos/cosmos-sdk/pull/7727#issuecomment-722478477
+4. https://github.com/cosmos/cosmos-sdk/pull/7727#issuecomment-721062923