Use solidity/javascript highlighting in various EIPs (ethereum#2372)

EIPS/eip-1062.md

@@ -36,13 +36,13 @@ When mapping the IPFS base58 string to ENS resolver, first we convert the Base58
 ## Rationale
 To implement the specification, need two methods from ENS public resolver contract, when we want to store IPFS file fingerprint to contract, convert the Base58 string identifier to the hex format and invoke the `setMultihash` method below :
 
-```
+```solidity
 function setMultihash(bytes32 node, bytes hash) public only_owner(node);
 ```
 
 Whenever users need to visit the ENS content, we call the `multihash` method to get the IPFS hex data, transfer to the Base58 format, and return the IPFS resources to use.
 
-```
+```solidity
 function multihash(bytes32 node) public view returns (bytes);
 ```
 
@@ -52,7 +52,7 @@ To implement the way to transfer from base58 to hex format and the reverse one,
 The library link : [https://www.npmjs.com/package/multihashes](https://www.npmjs.com/package/multihashes)  
 To implement the method transfer from IPFS(Base58) to hex format :
 
-```
+```javascript
 import multihash from 'multihashes'
 
 export const toHex = function(ipfsHash) {
@@ -63,7 +63,7 @@ export const toHex = function(ipfsHash) {
 
 To implement the method transfer from hex format to IPFS(Base58) :
 
-```
+```javascript
 import multihash from 'multihashes'
 
 export const toBase58 = function(contentHash) {

EIPS/eip-1132.md

@@ -43,7 +43,7 @@ The intention with this proposal is to enhance the ERC20 standard with token-loc
 I’ve extended the ERC20 interface with the following enhancements:
 
 ### Locking of tokens
-```
+```solidity
 /**
   * @dev Locks a specified amount of tokens against an address,
   *      for a specified reason and time
@@ -55,7 +55,7 @@ function lock(bytes32 _reason, uint256 _amount, uint256 _time) public returns (b
 ```
 
 ### Fetching number of tokens locked under each utility
-```
+```solidity
 /**
   * @dev Returns tokens locked for a specified address for a
   *      specified reason
@@ -67,7 +67,7 @@ function lock(bytes32 _reason, uint256 _amount, uint256 _time) public returns (b
 ```
 
 ### Fetching number of tokens locked under each utility at a future timestamp
-```
+```solidity
 /**
   * @dev Returns tokens locked for a specified address for a
   *      specified reason at a specific time
@@ -80,7 +80,7 @@ function lock(bytes32 _reason, uint256 _amount, uint256 _time) public returns (b
 ```
 
 ### Fetching number of tokens held by an address
-```
+```solidity
 /**
   * @dev @dev Returns total tokens held by an address (locked + transferable)
   * @param _of The address to query the total balance of
@@ -89,7 +89,7 @@ function totalBalanceOf(address _of)  view returns (uint256 amount)
 ```
 
 ### Extending lock period
-```
+```solidity
 /**
   * @dev Extends lock for a specified reason and time
   * @param _reason The reason to lock tokens
@@ -99,7 +99,7 @@ function totalBalanceOf(address _of)  view returns (uint256 amount)
 ```
 
 ### Increasing number of tokens locked
-```
+```solidity
 /**
   * @dev Increase number of tokens locked for a specified reason
   * @param _reason The reason to lock tokens
@@ -108,7 +108,7 @@ function totalBalanceOf(address _of)  view returns (uint256 amount)
   function increaseLockAmount(bytes32 _reason, uint256 _amount) public returns (bool)
 ```
 ### Fetching number of unlockable tokens under each utility
-```
+```solidity
 /**
   * @dev Returns unlockable tokens for a specified address for a specified reason
   * @param _of The address to query the the unlockable token count of
@@ -117,15 +117,15 @@ function totalBalanceOf(address _of)  view returns (uint256 amount)
   function tokensUnlockable(address _of, bytes32 _reason) public view returns (uint256 amount)
  ```    
 ### Fetching number of unlockable tokens
-```
+```solidity
 /**
   * @dev Gets the unlockable tokens of a specified address
   * @param _of The address to query the the unlockable token count of
   */
   function getUnlockableTokens(address _of) public view returns (uint256 unlockableTokens)
 ```
 ### Unlocking tokens
-```
+```solidity
 /**
   * @dev Unlocks the unlockable tokens of a specified address
   * @param _of Address of user, claiming back unlockable tokens

EIPS/eip-137.md

@@ -53,14 +53,14 @@ Resolving a name in ENS is a two-step process. First, the ENS registry is called
 
 For example, suppose you wish to find the address of the token contract associated with 'beercoin.eth'. First, get the resolver:
 
-```
+```javascript
 var node = namehash("beercoin.eth");
 var resolver = ens.resolver(node);
 ```
 
 Then, ask the resolver for the address for the contract:
 
-```
+```javascript
 var address = resolver.addr(node);
 ```
 
@@ -112,43 +112,43 @@ Implementations should conform to the following test vectors for namehash:
 
 The ENS registry contract exposes the following functions:
 
-```
+```solidity
 function owner(bytes32 node) constant returns (address);
 ```
 
 Returns the owner (registrar) of the specified node.
 
-```
+```solidity
 function resolver(bytes32 node) constant returns (address);
 ```
 
 Returns the resolver for the specified node.
 
-```
+```solidity
 function ttl(bytes32 node) constant returns (uint64);
 ```
 
 Returns the time-to-live (TTL) of the node; that is, the maximum duration for which a node's information may be cached.
 
-```
+```solidity
 function setOwner(bytes32 node, address owner);
 ```
 
 Transfers ownership of a node to another registrar. This function may only be called by the current owner of `node`. A successful call to this function logs the event `Transfer(bytes32 indexed, address)`.
 
-```
+```solidity
 function setSubnodeOwner(bytes32 node, bytes32 label, address owner);
 ```
 
 Creates a new node, `sha3(node, label)` and sets its owner to `owner`, or updates the node with a new owner if it already exists. This function may only be called by the current owner of `node`. A successful call to this function logs the event `NewOwner(bytes32 indexed, bytes32 indexed, address)`.
 
-```
+```solidity
 function setResolver(bytes32 node, address resolver);
 ```
 
 Sets the resolver address for `node`. This function may only be called by the owner of `node`. A successful call to this function logs the event `NewResolver(bytes32 indexed, address)`.
 
-```
+```solidity
 function setTTL(bytes32 node, uint64 ttl);
 ```
 
@@ -159,7 +159,7 @@ Resolvers may implement any subset of the record types specified here. Where a r
 
 Resolvers have one mandatory function:
 
-```
+```solidity
 function supportsInterface(bytes4 interfaceID) constant returns (bool)
 ```
 
@@ -184,7 +184,7 @@ EIPs may define new interfaces to be added to this registry.
 
 Resolvers wishing to support contract address resources must provide the following function:
 
-```
+```solidity
 function addr(bytes32 node) constant returns (address);
 ```
 
@@ -194,12 +194,12 @@ Clients resolving the `addr` record MUST check for a zero return value, and trea
 
 Changes to an address MUST trigger the following event:
 
-```
+```solidity
 event AddrChanged(bytes32 indexed node, address a);
 ```
 # Appendix A: Registry Implementation
 
-```
+```solidity
 contract ENS {
     struct Record {
         address owner;
@@ -261,7 +261,7 @@ contract ENS {
 
 The simplest possible resolver is a contract that acts as its own name resolver by implementing the contract address resource profile:
 
-```
+```solidity
 contract DoSomethingUseful {
     // Other code
 
@@ -285,7 +285,7 @@ Such a contract can be inserted directly into the ENS registry, eliminating the
 
 A basic resolver that implements the contract address profile, and allows only its owner to update records:
 
-```
+```solidity
 contract Resolver {
     event AddrChanged(bytes32 indexed node, address a);
 
@@ -325,7 +325,7 @@ After deploying this contract, use it by updating the ENS registry to reference
 
 Similar to the resolver above, this contract only supports the contract address profile, but uses the ENS registry to determine who should be allowed to update entries:
 
-```
+```solidity
 contract PublicResolver {
     event AddrChanged(bytes32 indexed node, address a);
     event ContentChanged(bytes32 indexed node, bytes32 hash);
@@ -364,7 +364,7 @@ contract PublicResolver {
 
 This registrar allows users to register names at no cost if they are the first to request them.
 
-```
+```solidity
 contract FIFSRegistrar {
     ENS ens;
     bytes32 rootNode;

EIPS/eip-1386.md

@@ -40,7 +40,7 @@ The wine vendors smart contract validates the attestation, checks the payment am
 When the wine vendor shows up to her apartment with the wine, there is no need to prove her age again.
 
 ### Draft interface
-```
+```solidity
 /* each attestation issuer should provide their own verify() for the
  * attestations they issued. There are two reasons for this. First, we
  * need to leave room for new attestation methods other than the

EIPS/eip-1387.md

@@ -21,7 +21,7 @@ Unlike previous attempts, we assume that the attestation is signed and issued of
 This ERC provides an interface and reference implementation for smart contracts that need users to provide an attestation and validate it.
 
 ### Draft implementation
-```
+```solidity
 contract MerkleTreeAttestationInterface {
     struct Attestation
     {

EIPS/eip-1388.md

@@ -21,7 +21,7 @@ Anyone can publish a list of issuers. Only the most trusted and carefully mainta
 This ERC provides a smart contract interface for anyone to manage a list of attestation issuers. A smart contract would explicitly trust a list, and therefore all attestations issued by the issuers on the list.
 
 ### Draft implementation
-  ```
+```solidity
     /* The purpose of this contract is to manage the list of attestation
      * issuer contracts and their capacity to fulfill requirements
      */

EIPS/eip-1450.md

@@ -52,7 +52,7 @@ For compliance reasons, the `ERC-1450` constructor must specify the issuer (the
 ### ERC-20 Extension
 `ERC-20` tokens provide the following functionality:
 
-```
+```solidity
 contract ERC20 {
   function totalSupply() public view returns (uint256);
   function balanceOf(address who) public view returns (uint256);
@@ -67,7 +67,7 @@ contract ERC20 {
 
 `ERC-20` is extended as follows:
 
-```
+```solidity
 /**
  * ERC-1450 is an ERC-20 compatible token that facilitates compliance with one or more of Securities Act Regulations CF, D and A. 
  *

EIPS/eip-1485.md

@@ -132,7 +132,7 @@ FNV Mix Algorithm Analysis for TEthashV1
 You can compile it with simple in terminal.
 No additional library needs, 
 
-```
+```sh
 gcc -o fnvtest fnvcltest.c
 ```
 

EIPS/eip-1491.md

@@ -41,7 +41,7 @@ The BDI software model is an attempt to solve a problem of plans and planning ch
 
 
 #### Main Interface
-```
+```solidity
 pragma solidity ^0.4.25;
 pragma experimental ABIEncoderV2;
 
@@ -327,7 +327,7 @@ interface IERC_HUCAP {
 
 <!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).-->
 
-```
+```solidity
 
 interface IERC_HUCAP_TYPES {
 
@@ -359,7 +359,7 @@ interface IERC_HUCAP_TYPES {
 
 <!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).-->
 
-```
+```solidity
 pragma solidity ^0.4.25;
 pragma experimental ABIEncoderV2;
 
@@ -451,7 +451,7 @@ interface IERC_HUCAP_KEYSIGNING_EXTENSION {
 ```
 #### Human Capital Accounting Extension Interface
 
-```
+```solidity
 pragma solidity ^0.4.25;
 pragma experimental ABIEncoderV2;
 

EIPS/eip-1504.md

@@ -51,7 +51,7 @@ Below is the specification of Handler interface. In the Handler interface we def
 Developers have to define their business-related functions as well.
 
 
-```
+```solidity
 /// Handler interface.
 /// Handler defines business related functions.
 /// Use the interface to ensure that your external services are always supported.
@@ -105,7 +105,7 @@ Below is the specification of Data contract. There are three parts in the Data c
 - **Resource Data**: all other resources that the contract needs to keep and manage.
 
 
-```
+```solidity
 /// Data Contract
 contract DataContract {
 
@@ -236,7 +236,7 @@ Note:
 - Function status() can be called at any time to show caller status of the upgrader.
 
 
-```
+```solidity
 /// Handler upgrader
 contract Upgrader {
     // Data contract

EIPS/eip-152.md

@@ -202,7 +202,7 @@ For reference, further discussion on this EIP also occurred in the following PRs
 
 Assuming ecRecover precompile is perfectly priced, we executed a set of benchmarks comparing Blake2b F compression function precompile with ecRecover precompile. For benchmarks, we used 3.1 GHz Intel Core i7 64-bit machine.
 
-```
+```sh
 $ sysctl -n machdep.cpu.brand_string
 Intel(R) Core(TM) i7-7920HQ CPU @ 3.10GHz
 ```

EIPS/eip-1592.md

@@ -105,7 +105,7 @@ To use rules within a token is as easy as having the token inherit from WithRule
 
 Below is a template for a rule.
 
-```
+```solidity
 import "../interface/IRule.sol";
 
 contract TemplateRule is IRule {