Updated docs and CI

.github/workflows/ci.yml

@@ -24,6 +24,10 @@ jobs:
     name: Shellcheck
     uses: ./.github/workflows/shellcheck.yml
 
+  markdownlint:
+    name: Markdown Lint
+    uses: ./.github/workflows/markdownlint.yml
+
   todo:
     if: github.event_name == 'push'
     name: TODO

.github/workflows/markdownlint.yml

@@ -0,0 +1,14 @@
+name: Markdown Lint
+
+on:
+  workflow_call:
+
+jobs:
+  markdownlint:
+    name: Markdown Lint
+    runs-on: ubuntu-latest
+    steps:
+      - name: Begin CI...
+        uses: actions/checkout@v3
+      - name: Markdown Lint
+        uses: articulate/actions-markdownlint@v1

.markdownlint.json

@@ -0,0 +1,11 @@
+{
+  "MD041": false,
+  "MD042": false,
+  "MD004": false,
+  "MD013": false,
+  "MD033": false,
+  "MD045": false,
+  "MD025": false,
+  "MD024": false,
+  "MD029": false
+}

CONTRIBUTING.md

@@ -6,10 +6,10 @@
 username will be referred to later as 'YOUR_GITHUB_USERNAME'. Change it
 accordingly in the steps below.)
 
-1. Fork https://github.com/vlang/vsl using GitHub's interface to your own account.
+1. Fork <https://github.com/vlang/vsl> using GitHub's interface to your own account.
    Let's say that the forked repository is at
    `https://github.com/YOUR_GITHUB_USERNAME/vsl` .
-2. Clone the main vsl repository https://github.com/vlang/vsl to a local folder on
+2. Clone the main vsl repository <https://github.com/vlang/vsl> to a local folder on
    your computer (`git clone https://github.com/vlang/vsl`)
 3. `cd vsl`
 4. `git remote add pullrequest https://github.com/YOUR_GITHUB_USERNAME/vsl`
@@ -21,11 +21,11 @@ accordingly in the steps below.)
 5. When finished with a feature/bugfix/change, you can:
    `git checkout -b fix_alabala`
 6. `git push pullrequest` # (NOTE: the `pullrequest` remote was setup on step 4)
-7. On GitHub's web interface, go to: https://github.com/vlang/vsl/pulls
+7. On GitHub's web interface, go to: <https://github.com/vlang/vsl/pulls>
 
    Here the UI shows a dialog with a button to make a new pull request based on
    the new pushed branch.
-   (Example dialog: https://url4e.com/gyazo/images/364edc04.png)
+   (Example dialog: <https://url4e.com/gyazo/images/364edc04.png>)
 
 8. After making your pullrequest (aka, PR), you can continue to work on the
    branch `fix_alabala` ... just do again `git push pullrequest` when you have more
@@ -46,19 +46,19 @@ main VSL repository's master, then `git checkout master`, as well as
 (these are actually used by `v up`) and git can always do it cleanly.
 
 Git is very flexible, so there are other ways to accomplish the same thing.
-See the [GitHub flow][https://guides.github.com/introduction/git-handbook/#github]
+See the [GitHub flow](https://guides.github.com/introduction/git-handbook/#github)
 for more information.
 
 ## Using Github's hub CLI tool
 
-You can download the `hub` tool from https://hub.github.com/ . Using
+You can download the `hub` tool from <https://hub.github.com/> . Using
 `hub`, you will not need to go through the (sometimes) slow website
 to make PRs. Most remote operations can be done through the `hub` CLI
 command.
 
 NB: You still need to have a GitHub account.
 
-### Preparation:
+### Preparation
 
 (steps 1..3 need to be done just _once_):
 
@@ -69,20 +69,20 @@ NB: You still need to have a GitHub account.
 4. `git checkout -b my_cool_feature` # Step 4 is better done _once per each new
    feature/bugfix_ that you make.
 
-### Improve VSL by making commits:
+### Improve VSL by making commits
 
 5. `git commit -am "math: add a new function copysign"`
 
-### Testing your commits locally:
+### Testing your commits locally
 
 You can test locally whether your changes have not broken something by
 running: `./bin/test`. See `README.md` for more details.
 
-### Publishing your commits to GitHub:
+### Publishing your commits to GitHub
 
 6. `git push pullrequest`
 
-### Making a PR with `hub`:
+### Making a PR with `hub`
 
 (so that your changes can be merged to the main VSL repository)
 
@@ -92,7 +92,7 @@ Optionally, you can track the status of your PR CI tests with:
 
 8. `hub ci-status --verbose`
 
-### Fixing failing tests:
+### Fixing failing tests
 
 If everything is OK, after some minutes, the CI tests should pass for
 all platforms. If not, visit the URLs for the failing CI jobs, see