erlang · garazdawi · Dec 7, 2023 · Dec 7, 2023
diff --git a/.github/workflows/action.yml b/.github/workflows/action.yml
@@ -3,8 +3,6 @@ name: action
 
 on:
   push:
-    branches:
-      - master
   pull_request:
     branches:
       - master
@@ -15,10 +13,12 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v2
-      - uses: docker://avtodev/markdown-lint:v1
+      - uses: DavidAnson/markdownlint-cli2-action@v14
         with:
-          config: 'markdownlint.config'
-          args: 'eeps/*.md README.md'
+          config: 'eep.markdownlint.json'
+          globs: |
+            README.md
+            eeps/*.md
       - name: Deploy on erlang.org
         if: github.ref == 'refs/heads/master'
         env:

diff --git a/markdownlint.config → eep.markdownlint.json b/markdownlint.config → eep.markdownlint.json
@@ -8,5 +8,6 @@
     "MD029": { "style": "ordered" },
     "MD033": false,
     "MD036": false,
-    "MD041": false
+    "MD041": false,
+    "MD053": { "ignored_definitions": ["numerical index of eeps","eep status legend","eep owners","eep","emacsvar","vimvar","//"]}
 }
diff --git a/eeps/eep-0008.md b/eeps/eep-0008.md
@@ -331,8 +331,6 @@ Current limitations
 
 The main limitation is the inability to define recursive types.
 
-[EEP-8]: <eep-0008.md> "EEP 8 Source"
-
 Copyright
 =========
 

diff --git a/eeps/eep-0009.md b/eeps/eep-0009.md
@@ -526,8 +526,6 @@ Reference implementation
 
 A reference implementation has been provided to the OTP team.
 
-[EEP-9]: <eep-0009.md> "EEP 9 Source"
-
 [1]: http://en.wikipedia.org/wiki/PCRE
 
 [2]: http://www.pcre.org/pcre.txt

diff --git a/eeps/eep-0010.md b/eeps/eep-0010.md
@@ -739,8 +739,6 @@ The io-protocol need to be changed to always handle Unicode characters.
 Options given when opening a file will allow for implicit conversion of
 text files.
 
-[EEP-10]: <eep-00010.md> "EEP 10 Source"
-
 [1]: http://www.ietf.org/rfc/rfc3629.txt
     "The UTF-8 RFC"
 [2]: http://www.unicode.org/

diff --git a/eeps/eep-0012.md b/eeps/eep-0012.md
@@ -208,8 +208,6 @@ This implementation does the three source to source rewrites
 described in the previous section, entirely in the parser.
 The rest of the Erlang system needs no changes whatever.
 
-[EEP-12]: <eep-00012.md> "EEP 12 Source"
-
 [1]: eep-0012-1.diff
      "Patch file to be applied to erl_parse.yrl"
 

diff --git a/eeps/eep-0018.md b/eeps/eep-0018.md
@@ -354,7 +354,7 @@ and above all Python, all of which have such a distinction, it is
 fortunate that JSON syntax and the RFC allow the distinction.
 
 Clearly, Erlang->JSON->Erlang is going to be tricky.  To take
-just one minor point, neither www.json.org nor RFC 4627 makes
+just one minor point, neither <www.json.org> nor RFC 4627 makes
 an promises whatever about the range of numbers that can be
 passed through JSON.  There isn't even any minimum range.  It
 seems as though a JSON implementation could reject all numbers
@@ -960,8 +960,6 @@ None.
     "The JSON web site"
 [2]: http://www.ietf.org/rfc/rfc4627.txt
     "The JSON RFC"
-[3]: http://www.json-rpc.org/
-    "The JSON RPC web site"
 [4]: http://json-rpc.org/wd/JSON-RPC-1-1-WD-20060807.html
     "The JSON RPC 1.1 draft specification"
 [5]: http://unicode.org/reports/tr16/

diff --git a/eeps/eep-0040.md b/eeps/eep-0040.md
@@ -14,9 +14,10 @@ Abstract
 This EEP proposes how to extend variable and atom names in Erlang
 to contain Unicode characters in a backwards compatible way.
 
-[Note]: <> (Underscores in regular text below are backslash escaped)
-[Note]: <> (due to a weird Markdown rule for emphasis within words.)
-[Note]: <> (So e.g. where you find XID\_Start it means XID_Start.)
+<!--
+Underscores in regular text below are backslash escaped due to a weird Markdown
+rule for emphasis within words. So e.g. where you find XID\_Start it means XID_Start.
+-->
 
 Forces
 ======
@@ -33,7 +34,7 @@ Forces
    represent Internationalized Domain Names as unquoted
    atoms would be just as much of a convenience as
    being able to represent ASCII domain names like
-   www.example.com (which needs no quotes in Erlang) is.
+   `www.example.com` (which needs no quotes in Erlang) is.
 4. There is a framework for Unicode identifiers in [UAX#31][],
    used by several programming languages, including Ada, Java,
    C++, C, C#, Javascript, and Python (section 2.3 of [Python Lexical][],
@@ -268,9 +269,6 @@ counterpart.  Since "ß" and "ÿ" have upper-case counterparts in
 Unicode, Latin-1 unquoted atoms would not be affected by such a rule.
 The great mass of Lo characters would also be unaffected.
 
-[References]: <>
-"==========="
-
 [Unicode]: http://www.unicode.org/versions/Unicode6.2.0/
     "The Unicode Standard version 6.2.0"
 

diff --git a/eeps/eep-0041.md b/eeps/eep-0041.md
@@ -582,9 +582,6 @@ Reference Implementation
 
 None in this draft, though implementation hints are given.
 
-[References]: <>
-"=========="
-
 [S]: http://en.wikipedia.org/wiki/S_%28programming_language%29
      "The S programming language"
 [R]: http://www.r-project.org/

diff --git a/eeps/eep-0043.md b/eeps/eep-0043.md
@@ -1354,8 +1354,6 @@ Distribution will not be backwards compatible.
     "5. Data Structures - Python v2.7.3 documentation"
 [scala-maps]: http://docs.scala-lang.org/overviews/collections/maps.html
     "Collections - Maps - Scala Documentation"
-[dict-module]: http://www.Erlang.org/doc/man/dict.html
-    "Erlang -- dict"
 [ROKframe]: http://www.cs.otago.ac.nz/staffpriv/ok/frames.pdf
     "No more need for records"
 [erlspec]: http://www.Erlang.org/download/erl_spec47.ps.gz

diff --git a/eeps/eep-0060.md b/eeps/eep-0060.md
@@ -509,7 +509,7 @@ In Python, feature names are never removed from the `__future__`
 module, which means that the `__future__` module contains a history of
 language changes.
 
-Some of the benefits of Pythons future import statement and __future__
+Some of the benefits of Pythons future import statement and `__future__`
 module are:
 
 * Users can start migrating code module by module before using a

diff --git a/eeps/eep-0064.md b/eeps/eep-0064.md
@@ -538,9 +538,6 @@ there is no possibility to remove it.
 [EEP 59]: https://www.erlang.org/eeps/eep-0059
     "EEP 59: Module attributes for documentation"
 
-[EEP 62]: https://www.erlang.org/eeps/eep-0062
-    "String Interpolation Syntax"
-
 [PR-7343]: https://github.com/erlang/otp/pull/7343
     "Feature: String Interpolation"
 

diff --git a/eeps/eep-0066.md b/eeps/eep-0066.md
@@ -351,6 +351,8 @@ be translated to something useful for tools/libraries.
 There are at least two ways; [uncompiled regular expressions][],
 or [compiled regular expressions][].
 
+<a id="uncompiled-regular-expressions"></a>
+
 #### Uncompiled Regular Expression
 
 The value of a regular expression [Sigil][] is chosen
@@ -386,6 +388,8 @@ for any compile options (only allow run-time options), or if
 the options argument is a literal to be included in
 pre-compilation, then such an optimization is safe.
 
+<a id="compiled-regular-expressions"></a>
+
 #### Compiled Regular Expression
 
 Another possibility would be that the value of a regular expression