modify documentation

Author: duaraghav8

README.md

@@ -40,12 +40,13 @@ This creates 2 files for you:
   "plugins": ["security"],
   "rules": {
     "quotes": ["error", "double"],
-    "indentation": ["error", 4]
+    "indentation": ["error", 4],
+    "linebreak-style": ["error", "unix"]
   }
 }
 ```
 
-To know which lint rules Solium applies for you, see [Style rules](http://solium.readthedocs.io/en/latest/user-guide.html#list-of-style-rules) and [Security rules](https://www.npmjs.com/package/solium-plugin-security#list-of-rules).
+To know which lint rules Solium applies for you, see [Style rules](http://ethlint.readthedocs.io/en/latest/user-guide.html#list-of-style-rules) and [Security rules](https://www.npmjs.com/package/solium-plugin-security#list-of-rules).
 
 ---
 **NOTE**

docs/known-issues.rst

@@ -6,7 +6,7 @@ While Solium is being actively maintained, a few major issues are still lurking
 
 - Solium is currently **file-aware instead of being project-aware**. What this means is that while linting, Solium doesn't have the context of all the contracts and how they may be using the contract currently being linted. A consequence of this is that the linter currently flags a state variable as unused if it doesn't find its usage in the same contract, whereas its clearly possible that you're ``import`` ing the contract elsewhere to use that variable (See `issue <https://github.com/duaraghav8/Solium/issues/11>`_). This is a fairly critical problem and will be resolved in a future release. We believe a codebase-aware linter would be much more powerful because of its broader context.
 
-- The linter's internal parser supports Solidity ``v0.5``. This means that it supports the `calldata <https://solidity.readthedocs.io/en/v0.5.2/types.html#data-location>` storage location specifier, but in a non-backward-compatible manner. If you're currently using Solidity version < 0.5 and have used ``calldata`` as a name for a variable or function parameter, you might see false lint issues because ``calldata`` is treated as location and hence, the variable name is seen as ``null``. Regardless of whether you use Solium or not, it is a good idea to rename all such variables to keep your code compatible with Solidity 0.5.
+- The linter's internal parser supports Solidity ``v0.5``. This means that it supports the `calldata <https://solidity.readthedocs.io/en/v0.5.2/types.html#data-location>`_ storage location specifier, but in a non-backward-compatible manner. If you're currently using Solidity version < 0.5 and have used ``calldata`` as a name for a variable or function parameter, you might see false lint issues because ``calldata`` is treated as location and hence, the variable name is seen as ``null``. Regardless of whether you use Solium or not, it is a good idea to rename all such variables to keep your code compatible with Solidity 0.5.
 
 If you discover any other pain points while using Solium, we encourage you to open up an issue.