diff --git a/.github/workflows/action.yml b/.github/workflows/action.yml index c6358a1..c4a6a1f 100644 --- 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 b/eep.markdownlint.json similarity index 66% rename from markdownlint.config rename to eep.markdownlint.json index 3c3d859..e593fc9 100644 --- a/markdownlint.config +++ b/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 index b007d45..ee47f30 100644 --- 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 8 Source" - Copyright ========= diff --git a/eeps/eep-0009.md b/eeps/eep-0009.md index 45987b7..d96d75f 100644 --- 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 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 index 1d1e70c..b1cdf25 100644 --- 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 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 index 0a868a1..29c2b02 100644 --- 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 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 index d4929b0..712b1f1 100644 --- 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 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 index ef456d2..2f2d407 100644 --- 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.) + 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 index 238fef9..d3be20b 100644 --- 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 index bf66ba4..e64c2c1 100644 --- 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 index 87dd16e..c36b340 100644 --- 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 index 2db6721..e9fc78b 100644 --- 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 index e29bfe2..1627c95 100644 --- 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][]. + + #### 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. + + #### Compiled Regular Expression Another possibility would be that the value of a regular expression