docs(v1): remove exclusive language (#1961)

* Initial commit to replace easy, easily, simple, just, of course

* Revert ordered list change
This commit is contained in:
Eric Carboni 2019-11-11 17:06:54 -05:00 committed by Yangshun Tay
parent f1180d0eb6
commit b027db1b34
43 changed files with 56 additions and 56 deletions

View file

@ -20,7 +20,7 @@ Let's talk a bit more about what is done as part of the parsing stage. The resul
#### Inline tokens
Inline tokens are simple tokens that have text as a child. They are leaf nodes, and do not support having additional tokens within. An example of this might be `_emphasized text_`, which might be represented as a token of type `em` with contents of `emphasized text`.
Inline tokens are tokens that have text as a child. They are leaf nodes, and do not support having additional tokens within. An example of this might be `_emphasized text_`, which might be represented as a token of type `em` with contents of `emphasized text`.
#### Block tokens
@ -36,7 +36,7 @@ The plain markdown text above would be parsed into three tokens:
- `text`: Plain text token, with a value of "Hi there".
- `heading_close`: Marks the end of the heading. In this case, it would also have a `hLevel: 3` prop.
This is a basic example, because it contains a simple `text` token within the opening and closing tags. A common block encountered in markdown is the paragraph, which might be tokenized into a series of tokens such as `paragraph_open`, one or more `text` tokens, `link` tokens (if links are present within the text, for example), and, eventually, a `paragraph_close` token.
This is a basic example, because it contains a `text` token within the opening and closing tags. A common block encountered in markdown is the paragraph, which might be tokenized into a series of tokens such as `paragraph_open`, one or more `text` tokens, `link` tokens (if links are present within the text, for example), and, eventually, a `paragraph_close` token.
#### Core tokens
@ -48,7 +48,7 @@ After we have parsed everything into tokens, we go to the rendering phase. This
## Creating a Remarkable Extension
Now that you have a better idea of how parsing/rendering works, we can proceed to create a simple extension that renders heading anchors. First we need to determine if we need to extend the parser, or the renderer. In this case, we're only interested in changing how a heading is rendered to HTML, so we'll just need to override the heading renderers.
Now that you have a better idea of how parsing/rendering works, we can proceed to create an extension that renders heading anchors. First we need to determine if we need to extend the parser, or the renderer. In this case, we're only interested in changing how a heading is rendered to HTML, so we'll just need to override the heading renderers.
The default heading renderers may look like this (you can refer to the Remarkable source code here):