ecmarkdown
Advanced tools
Comparing version 3.0.9 to 4.0.0
{ | ||
"name": "ecmarkdown", | ||
"version": "3.0.9", | ||
"version": "4.0.0", | ||
"description": "A compiler for \"Ecmarkdown\" algorithm shorthand into HTML.", | ||
"main": "lib/ecmarkdown.js", | ||
"main": "dist/ecmarkdown.js", | ||
"scripts": { | ||
"test": "mocha --reporter dot test/tokenizer.js && node test/run-cases.js", | ||
"lint": "eslint lib && jscs lib && eslint test && jscs test" | ||
"build": "tsc -p src", | ||
"prepublish": "npm run build", | ||
"test": "mocha --reporter dot test/tokenizer.js test/parser.js && node test/run-cases.js", | ||
"lint": "eslint --ext .js,.ts src test", | ||
"format": "prettier --write src test" | ||
}, | ||
"repository": "domenic/ecmarkdown", | ||
"repository": "https://github.com/tc39/ecmarkdown", | ||
"keywords": [ | ||
@@ -22,3 +25,4 @@ "ecmascript", | ||
"files": [ | ||
"lib/*.js" | ||
"dist/*.js", | ||
"dist/*.d.ts" | ||
], | ||
@@ -29,14 +33,24 @@ "dependencies": { | ||
"devDependencies": { | ||
"baseline-tester": "^1.1.1", | ||
"bluebird": "^2.9.14", | ||
"eslint": "^0.24.1", | ||
"glob": "^5.0.3", | ||
"@typescript-eslint/eslint-plugin": "^2.29.0", | ||
"@typescript-eslint/parser": "^2.29.0", | ||
"eslint": "^6.8.0", | ||
"eslint-config-prettier": "^6.10.1", | ||
"eslint-plugin-prettier": "^3.1.2", | ||
"inline-elements": "^1.0.0", | ||
"js-beautify": "^1.5.5", | ||
"jscs": "^1.13.1", | ||
"mocha": "^2.2.5", | ||
"pegjs": "^0.8.0" | ||
"js-beautify": "1.5.5", | ||
"mocha": "^7.1.1", | ||
"prettier": "^2.0.4", | ||
"typescript": "^3.8.3" | ||
}, | ||
"prettier": { | ||
"singleQuote": true, | ||
"arrowParens": "avoid", | ||
"printWidth": 100 | ||
}, | ||
"author": "Domenic Denicola <d@domenic.me> (https://domenic.me/)", | ||
"contributors": [ | ||
"Domenic Denicola <d@domenic.me> (https://domenic.me/)", | ||
"Brian Terlson <brian.terlson@microsoft.com> (https://github.com/bterlson)" | ||
], | ||
"license": "WTFPL" | ||
} |
110
README.md
# Ecmarkdown | ||
**Ecmarkdown** is a Markdown-inspired syntax for writing text and algorithms in the style of the ECMAScript spec. This package will convert Ecmarkdown input to HTML output, allowing you to write | ||
**Ecmarkdown** is a Markdown-inspired syntax for writing text and algorithms in the style of [the ECMAScript spec](https://tc39.github.io/ecma262/). This package will convert Ecmarkdown input to HTML output. | ||
## Examples | ||
### An algorithm | ||
Some of Ecmarkdown's biggest benefits are when using it to write algorithm steps, without the many formalities HTML requires for list items and inline formatting of common algorithmic constructs. | ||
``` | ||
@@ -17,25 +23,27 @@ 1. Assert: Type(_iterator_) is Object. | ||
instead of | ||
will be converted to | ||
```html | ||
<ol> | ||
<li>Assert: Type(<var>iterator</var>) is Object.</li> | ||
<li>Assert: <var>completion</var> is a Completion Record.</li> | ||
<li>Let <var>hasReturn</var> be HasProperty(<var>iterator</var>, <code>"return"</code>).</li> | ||
<li>ReturnIfAbrupt(<var>hasReturn</var>). | ||
<ol> | ||
<li>If <var>hasReturn</var> is <emu-val>true</emu-val>, then | ||
<ol> | ||
<li>Let <var>innerResult</var> be Invoke(<var>iterator</var>, <code>"return"</code>, ( )).</li> | ||
<li>If <var>completion</var>.[[type]] is not <emu-const>throw</emu-const> and <var>innerResult</var>.[[type]] is <emu-const>throw</emu-const>, then | ||
<ol> | ||
<li>Return <var>innerResult</var>.</li> | ||
</ol> | ||
</li> | ||
</ol> | ||
</li> | ||
</ol> | ||
</li> | ||
<li>Return <var>completion</var>.</li> | ||
</ol> | ||
<emu-alg> | ||
<ol> | ||
<li>Assert: Type(<var>iterator</var>) is Object.</li> | ||
<li>Assert: <var>completion</var> is a Completion Record.</li> | ||
<li>Let <var>hasReturn</var> be HasProperty(<var>iterator</var>, <code>"return"</code>).</li> | ||
<li>ReturnIfAbrupt(<var>hasReturn</var>). | ||
<ol> | ||
<li>If <var>hasReturn</var> is <emu-val>true</emu-val>, then | ||
<ol> | ||
<li>Let <var>innerResult</var> be Invoke(<var>iterator</var>, <code>"return"</code>, ( )).</li> | ||
<li>If <var>completion</var>.[[type]] is not <emu-const>throw</emu-const> and <var>innerResult</var>.[[type]] is <emu-const>throw</emu-const>, then | ||
<ol> | ||
<li>Return <var>innerResult</var>.</li> | ||
</ol> | ||
</li> | ||
</ol> | ||
</li> | ||
</ol> | ||
</li> | ||
<li>Return <var>completion</var>.</li> | ||
</ol> | ||
</emu-alg> | ||
``` | ||
@@ -45,52 +53,20 @@ | ||
### Top-Level Constructs | ||
The following is a partial [EBNF](https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_Form#Basics) for the top-level constructs in Ecmarkdown. | ||
#### Lists | ||
``` | ||
Document = Paragraph , [ { "\n\n" , Paragraph } ] ; | ||
Lists are written as a series of lines, each starting with either a number, e.g. `1.`, or a star, e.g. `*`. Inside a list item line you can use inline Ecmarkdown constructs. The first list item's number determines the starting number in the output (via `<ol start="x">`); subsequent list items' numbers are ignored. | ||
Paragraph = OrderedList | UnorderedList | NonList ; | ||
Lists can be nested. To do so, use any number of spaces to indent; as long as the number of spaces is consistent, list items will stay together in a nested list. | ||
OrderedList = OrderedListItem , [ { "\n" , OrderedListItem | UnorderedListItem } ] ; | ||
#### HTML Blocks | ||
UnorderedList = UnorderedListItem , [ { "\n" , OrderedListItem | UnorderedListItem } ] ; | ||
Any line which starts with a block-level HTML tag ([as defined by CommonMark](http://spec.commonmark.org/0.22/#html-blocks), with the addition of `<emu-note>`, `<emu-clause>`, `<emu-intro>`, `<emu-annex>`, `<emu-biblio>`, `<emu-import>`, `<emu-table>`, `<emu-figure>`, `<emu-example>`, `<emu-alg>`, and `<emu-see-also-para>`) is a HTML block line. Ecmarkdown cannot be used on the line starting a HTML block, but subsequent lines before the closing tag do allow it. | ||
OrderedListItem = { white space } , { digit } , "." , space , Fragment ; | ||
#### Opaque HTML Blocks | ||
UnorderedListItem = { white space } , "*" , space , Fragment ; | ||
The tags `<emu-grammar>`, `<emu-eqn>`, `<emu-production>`, `<pre>`, `<code>`, `<script>`, and `<style>` are considered opaque. Their entire contents, until their closing tag is seen, are left alone, with no Ecmarkdown processing or HTML escaping. As with ordinary HTML blocks, this only applies if the tag begins the line; if they are seen mid-line they will be treated as inline HTML. | ||
NonList = Fragment ; | ||
### Inline Formatting | ||
Fragment = { StarFormat | UnderscoreFormat | TildeFormat | ||
| TickFormat | PipeFormat | Text } ; | ||
// could consider renaming to output element | ||
Inside a paragraph, list item, or header, the following inline formatting elements can appear: | ||
StarFormat = "*" , Text , "*" ; | ||
// With some complex restrictions on surrounding context to match Github-flavored | ||
// Markdown semantics | ||
// and etc. for each fragment type except TickFragment which has no context | ||
// restrictions per gmd semantics and UnderscoreFormat which doesn't allow whitespace | ||
// or format characters inside of it. | ||
``` | ||
The key takeaways from this grammar are the following: | ||
* Paragraphs are separated by two line breaks. | ||
* Paragraphs can either be lists or non-lists. | ||
* Lists can be ordered or unordered. List items must be preceded by a line break. You can have a ordered list as a sublist in an unordered list and vice versa. | ||
* List items and non-list paragraphs are fragments. Fragments are a series of one or more formats or plain text. | ||
Ecmarkdown also allows HTML tags and comments anywhere that does not otherwise disturb the parsing. They are included in the resulting output, in the equivalent location. | ||
### Lists | ||
Lists are written as a series of lines, each starting with either a number, e.g. `1.`, or a star, e.g. `*`. The first list item's number determines the starting number in the output (via `<ol start="x">`); subsequent list items' numbers are ignored. | ||
Lists can be nested. To do so, use any number of spaces to indent; as long as the number of spaces is consistent, list items will stay together in a nested list. | ||
## Inline Formatting | ||
Within a fragment, the following can be used: | ||
**Variables** are written as `_x_` and are translated to `<var>x</var>`. Variables cannot contain whitespace or other formatting characters. | ||
@@ -110,8 +86,12 @@ | ||
Finally, anything in between `<` and `>` will count as an **html tag** and will not be messed with, so e.g. `<span title="_x_">` will be left alone instead of being translated into `<span title=<code>"<var>x</var>"</code>>`. | ||
HTML tags used inside paragraphs will generally be passed through, with their contents processed further by Ecmarkdown (but not their attribute values). The exception is if the tag starts the line and is categorized as block or opaque, in which case the previous sections apply. | ||
## Interaction with Ecmarkup | ||
Ecmarkdown is meant to be used together with [Ecmarkup](https://github.com/bterlson/ecmarkup/). Ecmarkup has an `<emu-alg>` element within which Ecmarkdown numeric lists can be used, and in other contexts it treats the content of text nodes as Ecmarkdown fragments. In the other direction, several Ecmarkdown productions produce Ecmarkup elements (as noted above). This relationship is evolving, however. | ||
Ecmarkdown is meant to be used together with [Ecmarkup](https://github.com/bterlson/ecmarkup/). Ecmarkup provides: | ||
* The framework for structuring and compiling a specification containing Ecmarkdown contents | ||
* An auto-linking postprocessing step | ||
* A target vocabulary (the `<emu-` tags) for some Ecmarkdown constructs. | ||
In short, we expect Ecmarkdown to be embedded within a larger Ecmarkup document, used for writing algorithm steps and other text in a concise format. |
Major refactor
Supply chain riskPackage has recently undergone a major refactor. It may be unstable or indicate significant internal changes. Use caution when updating to versions that include significant changes.
Found 1 instance in 1 package
New author
Supply chain riskA new npm collaborator published a version of the package for the first time. New collaborators are usually benign additions to a project, but do indicate a change to the security surface area of a package.
Found 1 instance in 1 package
No repository
Supply chain riskPackage does not have a linked source code repository. Without this field, a package will have no reference to the location of the source code use to generate the package.
Found 1 instance in 1 package
No repository
Supply chain riskPackage does not have a linked source code repository. Without this field, a package will have no reference to the location of the source code use to generate the package.
Found 1 instance in 1 package
47839
15
1152
10
95
2