around a bit and add some 
to your 
. Well we have a gift for you:
You can use emoji anywhere GFM is supported. 
You can use it to point out a 
or warn about 
patches. And if someone improves your really 
code, send them some 
. People will 
you for that.
If you are new to this, don't be 
. You can easily join the emoji 
. All you need to do is to look up one of the supported codes.
Consult the [Emoji Cheat Sheet](https://www.webfx.com/tools/emoji-cheat-sheet/) for a list of all supported emoji codes. 
> **Note:** The emoji example above uses hard-coded images for this documentation. The emoji,
when rendered within GitLab, may appear different depending on the OS and browser used.
Most emoji are natively supported on macOS, Windows, iOS, Android and will fallback to image-based emoji where there is lack of support.
NOTE: **Note:** On Linux, you can download [Noto Color Emoji](https://www.google.com/get/noto/help/emoji/)
to get full native emoji support. Ubuntu 18.04 (like many modern Linux distros) has
this font installed by default.
### Front matter
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23331)
in GitLab 11.6.
Front matter is metadata included at the beginning of a markdown document, preceding
its content. This data can be used by static site generators such as [Jekyll](https://jekyllrb.com/docs/front-matter/),
[Hugo](https://gohugo.io/content-management/front-matter/), and many other applications.
When you view a Markdown file rendered by GitLab, any front matter is displayed as-is,
in a box at the top of the document, before the rendered HTML content. To view an example,
you can toggle between the source and rendered version of a [GitLab documentation file](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/README.md).
In GitLab, front matter is only used in Markdown files and wiki pages, not the other
places where Markdown formatting is supported. It must be at the very top of the document,
and must be between delimiters, as explained below.
The following delimeters are supported:
- YAML (`---`):
~~~yaml
---
title: About Front Matter
example:
language: yaml
---
~~~
- TOML (`+++`):
~~~toml
+++
title = "About Front Matter"
[example]
language = "toml"
+++
~~~
- JSON (`;;;`):
~~~json
;;;
{
"title": "About Front Matter"
"example": {
"language": "json"
}
}
;;;
~~~
Other languages are supported by adding a specifier to any of the existing
delimiters. For example:
```php
---php
$title = "About Front Matter";
$example = array(
'language' => "php",
);
---
```
### Inline diff
> If this is not rendered correctly, [view it in GitLab itself](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/user/markdown.md#inline-diff).
With inline diff tags you can display `{+ additions +}` or `[- deletions -]`.
The wrapping tags can be either curly braces or square brackets:
```markdown
- {+ addition 1 +}
- [+ addition 2 +]
- {- deletion 3 -}
- [- deletion 4 -]
```
- {+ addition 1 +}
- [+ addition 2 +]
- {- deletion 3 -}
- [- deletion 4 -]
---
However the wrapping tags cannot be mixed:
```markdown
- {+ addition +]
- [+ addition +}
- {- deletion -]
- [- deletion -}
```
### Math
> If this is not rendered correctly, [view it in GitLab itself](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/user/markdown.md#math).
It is possible to have math written with LaTeX syntax rendered using [KaTeX](https://github.com/Khan/KaTeX).
Math written between dollar signs `$` will be rendered inline with the text. Math written
inside a [code block](#code-spans-and-blocks) with the language declared as `math`, will be rendered
on a separate line:
~~~
This math is inline $`a^2+b^2=c^2`$.
This is on a separate line
```math
a^2+b^2=c^2
```
~~~
This math is inline $`a^2+b^2=c^2`$.
This is on a separate line
```math
a^2+b^2=c^2
```
_Be advised that KaTeX only supports a [subset](https://katex.org/docs/supported.html) of LaTeX._
NOTE: **Note:** This also works for the asciidoctor `:stem: latexmath`. For details see
the [asciidoctor user manual](http://asciidoctor.org/docs/user-manual/#activating-stem-support).
### Special GitLab references
GFM recognizes special GitLab related references. For example, you can easily reference
an issue, a commit, a team member or even the whole team within a project. GFM will turn
that reference into a link so you can navigate between them easily.
Additionally, GFM recognizes certain cross-project references, and also has a shorthand
version to reference other projects from the same namespace.
GFM will recognize the following:
| references | input | cross-project reference | shortcut within same namespace |
| :------------------------------ | :------------------------- | :-------------------------------------- | :----------------------------- |
| specific user | `@user_name` | | |
| specific group | `@group_name` | | |
| entire team | `@all` | | |
| project | `namespace/project>` | | |
| issue | ``#123`` | `namespace/project#123` | `project#123` |
| merge request | `!123` | `namespace/project!123` | `project!123` |
| snippet | `$123` | `namespace/project$123` | `project$123` |
| epic **(ULTIMATE)** | `&123` | `group1/subgroup&123` | |
| label by ID | `~123` | `namespace/project~123` | `project~123` |
| one-word label by name | `~bug` | `namespace/project~bug` | `project~bug` |
| multi-word label by name | `~"feature request"` | `namespace/project~"feature request"` | `project~"feature request"` |
| project milestone by ID | `%123` | `namespace/project%123` | `project%123` |
| one-word milestone by name | `%v1.23` | `namespace/project%v1.23` | `project%v1.23` |
| multi-word milestone by name | `%"release candidate"` | `namespace/project%"release candidate"` | `project%"release candidate"` |
| specific commit | `9ba12248` | `namespace/project@9ba12248` | `project@9ba12248` |
| commit range comparison | `9ba12248...b19a04f5` | `namespace/project@9ba12248...b19a04f5` | `project@9ba12248...b19a04f5` |
| repository file references | `[README](doc/README)` | | |
| repository file line references | `[README](doc/README#L13)` | | |
### Task lists
> If this is not rendered correctly, [view it in GitLab itself](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/user/markdown.md#task-lists).
You can add task lists anywhere markdown is supported, but you can only "click" to
toggle the boxes if they are in issues, merge requests, or comments. In other places
you must edit the markdown manually to change the status by adding or removing the `x`.
To create a task list, add a specially-formatted Markdown list. You can use either
unordered or ordered lists:
```markdown
- [x] Completed task
- [ ] Incomplete task
- [ ] Sub-task 1
- [x] Sub-task 2
- [ ] Sub-task 3
1. [x] Completed task
1. [ ] Incomplete task
1. [ ] Sub-task 1
1. [x] Sub-task 2
```
- [x] Completed task
- [ ] Incomplete task
- [ ] Sub-task 1
- [x] Sub-task 2
- [ ] Sub-task 3
1. [x] Completed task
1. [ ] Incomplete task
1. [ ] Sub-task 1
1. [x] Sub-task 2
### Wiki-specific Markdown
The following examples show how links inside wikis behave.
#### Wiki - Direct page link
A link which just includes the slug for a page will point to that page,
_at the base level of the wiki_.
This snippet would link to a `documentation` page at the root of your wiki:
```markdown
[Link to Documentation](documentation)
```
#### Wiki - Direct file link
Links with a file extension point to that file, _relative to the current page_.
If the snippet below was placed on a page at `
Click me to collapse/fold.
These details will remain hidden until expanded.
PASTE LOGS HERE
Click me to collapse/fold.
These details will remain hidden until expanded.
PASTE LOGS HERE