feat: add github links in docs (cosmos#13491)

* feat: add github links in docs * apply proto theme * fix toc
bingwan · Oct 10, 2022 · 214b11d · 214b11d
1 parent b3abb8d
commit 214b11d
Show file tree

Hide file tree

Showing 62 changed files with 906 additions and 343 deletions.
diff --git a/UPGRADING.md b/UPGRADING.md
@@ -229,7 +229,7 @@ The protos can as well be downloaded using `buf export buf.build/cosmos/cosmos-s
 
 Cosmos message protobufs should be extended with `cosmos.msg.v1.signer`: 
 
-```proto
+```protobuf
 message MsgSetWithdrawAddress {
   option (cosmos.msg.v1.signer) = "delegator_address"; ++
 

diff --git a/docs/architecture/adr-020-protobuf-transaction-encoding.md b/docs/architecture/adr-020-protobuf-transaction-encoding.md
@@ -57,7 +57,7 @@ compatibility.
 In order to facilitate signing, transactions are separated into `TxBody`,
 which will be re-used by `SignDoc` below, and `signatures`:
 
-```proto
+```protobuf
 // types/types.proto
 package cosmos_sdk.v1;
 
@@ -190,7 +190,7 @@ the wire. This has the advantages of:
 Signatures are structured using the `SignDoc` below which reuses the serialization of
 `TxBody` and `AuthInfo` and only adds the fields which are needed for signatures:
 
-```proto
+```protobuf
 // types/types.proto
 message SignDoc {
     // A protobuf serialization of a TxBody that matches the representation in TxRaw.
@@ -295,7 +295,7 @@ The following public keys are implemented: secp256k1, secp256r1, ed25519 and leg
 
 Ex:
 
-```proto
+```protobuf
 message PubKey {
     bytes key = 1;
 }
@@ -408,7 +408,7 @@ To generate a signature in `SIGN_MODE_DIRECT_AUX` these steps would be followed:
 1. Encode `SignDocAux` (with the same requirement that fields must be serialized
    in order):
 
-    ```proto
+    ```protobuf
     // types/types.proto
     message SignDocAux {
         bytes body_bytes = 1;

diff --git a/docs/architecture/adr-021-protobuf-query-encoding.md b/docs/architecture/adr-021-protobuf-query-encoding.md
@@ -31,7 +31,7 @@ custom ABCI queries and even reuse a substantial amount of the GRPC infrastructu
 
 Each module with custom queries should define a service canonically named `Query`:
 
-```proto
+```protobuf
 // x/bank/types/types.proto
 
 service Query {
@@ -54,7 +54,7 @@ from also providing app-level queries that return use the app-level `oneof`s.
 
 A hypothetical example for the `gov` module would look something like:
 
-```proto
+```protobuf
 // x/gov/types/types.proto
 
 import "google/protobuf/any.proto";
@@ -159,7 +159,7 @@ translates REST calls into GRPC calls using special annotations on service
 methods. Modules that want to expose REST queries should add `google.api.http`
 annotations to their `rpc` methods as in this example below.
 
-```proto
+```protobuf
 // x/bank/types/types.proto
 
 service Query {

diff --git a/docs/architecture/adr-028-public-key-addresses.md b/docs/architecture/adr-028-public-key-addresses.md
@@ -150,7 +150,7 @@ For new multisig public keys, we define the `typ` parameter not based on any enc
 
 Example:
 
-```proto
+```protobuf
 package cosmos.crypto.multisig;
 
 message PubKey {
@@ -231,7 +231,7 @@ Since all Cosmos SDK account types are serialized in the state, we propose to us
 
 Example: all public key types have a unique protobuf message type similar to:
 
-```proto
+```protobuf
 package cosmos.crypto.sr25519;
 
 message PubKey {

diff --git a/docs/architecture/adr-029-fee-grant-module.md b/docs/architecture/adr-029-fee-grant-module.md
@@ -59,7 +59,7 @@ type FeeAllowanceI {
 
 Two basic fee allowance types, `BasicAllowance` and `PeriodicAllowance` are defined to support known use cases:
 
-```proto
+```protobuf
 // BasicAllowance implements FeeAllowanceI with a one-time grant of tokens
 // that optionally expires. The delegatee can use up to SpendLimit to cover fees.
 message BasicAllowance {
@@ -98,7 +98,7 @@ message PeriodicAllowance {
 
 Allowances can be granted and revoked using `MsgGrantAllowance` and `MsgRevokeAllowance`:
 
-```proto
+```protobuf
 // MsgGrantAllowance adds permission for Grantee to spend up to Allowance
 // of fees from the account of Granter.
 message MsgGrantAllowance {
@@ -116,7 +116,7 @@ message MsgGrantAllowance {
 
 In order to use allowances in transactions, we add a new field `granter` to the transaction `Fee` type:
 
-```proto
+```protobuf
 package cosmos.tx.v1beta1;
 
 message Fee {

diff --git a/docs/architecture/adr-030-authz-module.md b/docs/architecture/adr-030-authz-module.md
@@ -128,7 +128,7 @@ the field will be `nil`.
 
 ### `Msg` Service
 
-```proto
+```protobuf
 service Msg {
   // Grant grants the provided authorization to the grantee on the granter's
   // account with the provided expiration time.
@@ -216,7 +216,7 @@ This CLI command will send a `MsgRevoke` transaction.
 
 #### `SendAuthorization`
 
-```proto
+```protobuf
 // SendAuthorization allows the grantee to spend up to spend_limit coins from
 // the granter's account.
 message SendAuthorization {
@@ -226,7 +226,7 @@ message SendAuthorization {
 
 #### `GenericAuthorization`
 
-```proto
+```protobuf
 // GenericAuthorization gives the grantee unrestricted permissions to execute
 // the provided method on behalf of the granter's account.
 message GenericAuthorization {

diff --git a/docs/architecture/adr-031-msg-service.md b/docs/architecture/adr-031-msg-service.md
@@ -57,7 +57,7 @@ the code generated by them as a replacement for `Msg` handlers.
 Below we define how this will look for the `SubmitProposal` message from `x/gov` module.
 We start with a `Msg` `service` definition:
 
-```proto
+```protobuf
 package cosmos.gov;
 
 service Msg {

diff --git a/docs/architecture/adr-036-arbitrary-signature.md b/docs/architecture/adr-036-arbitrary-signature.md
@@ -57,7 +57,7 @@ It's applications developers decision how `Data` should be treated, by treated w
 
 Proto definition:
 
-```proto
+```protobuf
 // MsgSignData defines an arbitrary, general-purpose, off-chain message
 message MsgSignData {
     // Signer is the sdk.AccAddress of the message signer

diff --git a/docs/architecture/adr-042-group-module.md b/docs/architecture/adr-042-group-module.md
@@ -40,7 +40,7 @@ Group members can create proposals and vote on them through group accounts using
 It has an `admin` account which can manage members in the group, update the group
 metadata and set a new admin.
 
-```proto
+```protobuf
 message GroupInfo {
 
     // group_id is the unique ID of this group.
@@ -63,7 +63,7 @@ message GroupInfo {
 }
 ```
 
-```proto
+```protobuf
 message GroupMember {
 
     // group_id is the unique ID of the group.
@@ -102,7 +102,7 @@ and then to create separate group accounts with different decision policies
 and delegate the desired permissions from the master account to
 those "sub-accounts" using the [`x/authz` module](adr-030-authz-module.md).
 
-```proto
+```protobuf
 message GroupAccountInfo {
 
     // address is the group account address.
@@ -167,7 +167,7 @@ A threshold decision policy defines a minimum support votes (_yes_), based on a
 of voter weights, for a proposal to pass. For
 this decision policy, abstain and veto are treated as no support (_no_).
 
-```proto
+```protobuf
 message ThresholdDecisionPolicy {
 
     // threshold is the minimum weighted sum of support votes for a proposal to succeed.
@@ -191,7 +191,7 @@ Internally, a proposal also tracks:
 * its `Result`: unfinalized, accepted or rejected
 * its `VoteState` in the form of a `Tally`, which is calculated on new votes and when executing the proposal.
 
-```proto
+```protobuf
 // Tally represents the sum of weighted votes.
 message Tally {
     option (gogoproto.goproto_getters) = false;

diff --git a/docs/architecture/adr-043-nft-module.md b/docs/architecture/adr-043-nft-module.md
@@ -182,7 +182,7 @@ func (m msgServer) Send(ctx context.Context, msg *types.MsgSend) (*types.MsgSend
 
 The query service methods for the `x/nft` module are:
 
-```proto
+```protobuf
 service Query {
   // Balance queries the number of NFTs of a given class owned by the owner, same as balanceOf in ERC721
   rpc Balance(QueryBalanceRequest) returns (QueryBalanceResponse) {

diff --git a/docs/architecture/adr-049-state-sync-hooks.md b/docs/architecture/adr-049-state-sync-hooks.md
@@ -35,7 +35,7 @@ snapshot and the restoration. Each module could have mutiple snapshotters, and f
 implement `ExtensionSnapshotter` as extension snapshotters. When setting up the application, the snapshot `Manager` should call 
 `RegisterExtensions([]ExtensionSnapshotter…)` to register all the extension snapshotters.
 
-```proto
+```protobuf
 // SnapshotItem is an item contained in a rootmulti.Store snapshot.
 // On top of the exsiting SnapshotStoreItem and SnapshotIAVLItem, we add two new options for the item.
 message SnapshotItem {

diff --git a/docs/architecture/adr-050-sign-mode-textual-annex1.md b/docs/architecture/adr-050-sign-mode-textual-annex1.md
@@ -81,7 +81,7 @@ where:
 
 Given the proto definition:
 
-```proto
+```protobuf
 message AllowedMsgAllowance {
   repeated string allowed_messages = 1;
 }
@@ -123,7 +123,7 @@ End of Allowed messages
 
 Given the following Protobuf messages:
 
-```proto
+```protobuf
 enum VoteOption {
   VOTE_OPTION_UNSPECIFIED = 0;
   VOTE_OPTION_YES = 1;
@@ -268,7 +268,7 @@ Strings are rendered as-is.
 
 #### Example
 
-```proto
+```protobuf
 message TestData {
   string signer = 1;
   string metadata = 2;
@@ -298,7 +298,7 @@ _This paragraph is in the Annex for informational purposes only, and will be rem
 - all protobuf messages to be used with `SIGN_MODE_TEXTUAL` CAN have a short title associated with them that can be used in format strings whenever the type URL is explicitly referenced via the `cosmos.msg.v1.textual.msg_title` Protobuf message option.
 - if this option is not specified for a Msg, then the Protobuf fully qualified name will be used.
 
-```proto
+```protobuf
 message MsgSend {
   option (cosmos.msg.v1.textual.msg_title) = "bank send coins";
 }

diff --git a/docs/architecture/adr-050-sign-mode-textual.md b/docs/architecture/adr-050-sign-mode-textual.md
@@ -29,7 +29,7 @@ In an effort to remove Amino from the SDK, a new sign mode needs to be created f
 
 We propose to have SIGN_MODE_TEXTUAL’s signing payload `SignDocTextual` to be an array of strings, encoded as a `\n`-delimited string (see point #9). Each string corresponds to one "screen" on the hardware wallet device, with no (or little) additional formatting done by the hardware wallet itself.
 
-```proto
+```protobuf
 message SignDocTextual {
   repeated string screens = 1;
 }
@@ -136,7 +136,7 @@ End of transaction messages
 
 Given the following Protobuf message:
 
-```proto
+```protobuf
 message Grant {
   google.protobuf.Any       authorization = 1 [(cosmos_proto.accepts_interface) = "Authorization"];
   google.protobuf.Timestamp expiration    = 2 [(gogoproto.stdtime) = true, (gogoproto.nullable) = false];
@@ -167,7 +167,7 @@ Application developers may choose to not follow default renderer value output fo
 
 This is done by setting the `cosmos.msg.v1.textual.expert_custom_renderer` Protobuf option to a non-empty string. This option CAN ONLY be set on a Protobuf message representing transaction message object (implementing `sdk.Msg` interface).
 
-```proto
+```protobuf
 message MsgFooBar {
   // Optional comments to describe in human-readable language the formatting
   // rules of the custom renderer.

diff --git a/docs/docs/basics/00-app-anatomy.md b/docs/docs/basics/00-app-anatomy.md
@@ -55,13 +55,17 @@ The first thing defined in `app.go` is the `type` of the application. It is gene
 
 See an example of application type definition from `simapp`, the Cosmos SDK's own app used for demo and testing purposes:
 
-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/app.go#L151-L193
+```go reference
+https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/app.go#L151-L193
+```
 
 ### Constructor Function
 
 This function constructs a new application of the type defined in the section above. It must fulfill the `AppCreator` signature in order to be used in the [`start` command](../core/03-node.md#start-command) of the application's daemon command.
 
-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/server/types/app.go#L57-L59
+```go reference
+https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/server/types/app.go#L57-L59
+```
 
 Here are the main actions performed by this function:
 
@@ -83,7 +87,9 @@ Note that this function only creates an instance of the app, while the actual st
 
 See an example of application constructor from `simapp`:
 
-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/app.go#L204-L474
+```go reference
+https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/app.go#L204-L474
+```
 
 ### InitChainer
 
@@ -93,7 +99,9 @@ In general, the `InitChainer` is mostly composed of the [`InitGenesis`](../build
 
 See an example of an `InitChainer` from `simapp`:
 
-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/app.go#L524-L532
+```go reference
+https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/app.go#L524-L532
+```
 
 ### BeginBlocker and EndBlocker
 
@@ -105,13 +113,17 @@ As a sidenote, it is important to remember that application-specific blockchains
 
 See an example of `BeginBlocker` and `EndBlocker` functions from `simapp`
 
-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/app.go#L514-L522
+```go reference
+https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/app.go#L514-L522
+```
 
 ### Register Codec
 
 The `EncodingConfig` structure is the last important part of the `app.go` file. The goal of this structure is to define the codecs that will be used throughout the app.
 
-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/params/encoding.go#L9-L16
+```go reference
+https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/params/encoding.go#L9-L16
+```
 
 Here are descriptions of what each of the four fields means:
 
@@ -128,7 +140,9 @@ NOTE: This function is deprecated and should only be used to create an app or in
 
 See an example of a `MakeTestEncodingConfig` from `simapp`:
 
-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/encoding.go#L8-L19
+```go reference
+https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/encoding.go#L8-L19
+```
 
 ## Modules
 
@@ -157,7 +171,9 @@ For a more details look at a transaction [lifecycle](./01-tx-lifecycle.md).
 
 Module developers create custom `Msg` services when they build their own module. The general practice is to define the `Msg` Protobuf service in a `tx.proto` file. For example, the `x/bank` module defines a service with two methods to transfer tokens:
 
-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/bank/v1beta1/tx.proto#L12-L19
+```protobuf reference
+https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/bank/v1beta1/tx.proto#L12-L19
+```
 
 Service methods use `keeper` in order to update the module state.
 
@@ -227,7 +243,9 @@ The main interface is the [Command-Line Interface](../core/07-cli.md). The CLI o
 
 See an example of an application's main command-line file from the [Cosmos Hub](https://github.com/cosmos/gaia)
 
-+++ https://github.com/cosmos/gaia/blob/Theta-main/cmd/gaiad/cmd/root.go#L39-L77
+```go reference
+https://github.com/cosmos/gaia/blob/Theta-main/cmd/gaiad/cmd/root.go#L39-L77
+```
 
 ## Dependencies and Makefile
 
@@ -247,7 +265,9 @@ This section is optional, as developers are free to choose their dependency mana
 
 Below, the `go.mod` of the [Cosmos Hub](https://github.com/cosmos/gaia) is provided as an example.
 
-+++ https://github.com/cosmos/gaia/blob/Theta-main/go.mod#L1-L20
+```go reference
+https://github.com/cosmos/gaia/blob/Theta-main/go.mod#L1-L20
+```
 
 For building the application, a [Makefile](https://en.wikipedia.org/wiki/Makefile) is generally used. The Makefile primarily ensures that the `go.mod` is run before building the two entrypoints to the application, [`appd`](#node-client) and [`appd`](#application-interface).