github/zyedidia.micro
2
0
Fork 0
mirror of https://github.com/zyedidia/micro.git synced 2026-03-25 18:07:07 +09:00
Code Issues Packages Projects Releases Wiki Activity

Use more consisten syntax in md files, format tp 80 collumns, fix some typos

Browse Source
This commit is contained in:
Camille Scholtz
2017-10-11 15:16:53 +02:00
parent d76704839a
commit 9daa05d696
9 changed files with 490 additions and 409 deletions
Download Patch File Download Diff File Expand all files Collapse all files

193
runtime/help/colors.md
View File

@@ -5,79 +5,85 @@ This help page aims to cover two aspects of micro's syntax highlighting engine:
- How to create colorschemes and use them
- How to create syntax files to add to the list of languages micro can highlight
## Colorschemes
Micro comes with a number of colorschemes by default. Here is the list:
* simple: this is the simplest colorscheme. It uses 16 colors which are
set by your terminal
* simple: this is the simplest colorscheme. It uses 16 colors which are set by
your terminal
* mc: A 16-color theme based on the look and feel of GNU Midnight Commander.
This will look great used in conjunction with Midnight Commander.
* nano: A 16-color theme loosely based on GNU nano's syntax highlighting.
* monokai: this is the monokai colorscheme; you may recognize it as
Sublime Text's default colorscheme. It requires true color to
look perfect, but the 256 color approximation looks very good as well.
It's also the default colorscheme.
* monokai: this is the monokai colorscheme; you may recognize it as Sublime
Text's default colorscheme. It requires true color to look perfect, but the
256 color approximation looks very good as well. It's also the default
colorscheme.
* zenburn: The 'zenburn' colorscheme and works well with 256 color terminals
* solarized: this is the solarized colorscheme.
You should have the solarized color palette in your terminal to use it.
* solarized: this is the solarized colorscheme. You should have the solarized
color palette in your terminal to use it.
* solarized-tc: this is the solarized colorscheme for true color; just
make sure your terminal supports true color before using it and that the
MICRO_TRUECOLOR environment variable is set to 1 before starting micro.
* solarized-tc: this is the solarized colorscheme for true color; just make sure
your terminal supports true color before using it and that the MICRO_TRUECOLOR
environment variable is set to 1 before starting micro.
* atom-dark-tc: this colorscheme is based off of Atom's "dark" colorscheme.
It requires true color to look good.
* atom-dark-tc: this colorscheme is based off of Atom's "dark" colorscheme. It
requires true color to look good.
* cmc-16: A very nice 16-color theme. Written by contributor CaptainMcClellan
(Collin Warren.) Licensed under the same license as the rest of the themes.
* cmc-paper: Basically cmc-16, but on a white background. ( Actually light grey on most
ANSI (16-color) terminals.)
* cmc-paper: Basically cmc-16, but on a white background. (Actually light grey
on most ANSI (16-color) terminals)
* cmc-tc: A true colour variant of the cmc theme.
It requires true color to look its best. Use cmc-16 if your terminal doesn't support true color.
* cmc-tc: A true colour variant of the cmc theme. It requires true color to
look its best. Use cmc-16 if your terminal doesn't support true color.
* codeblocks: A colorscheme based on the Code::Blocks IDE's default syntax highlighting.
* codeblocks: A colorscheme based on the Code::Blocks IDE's default syntax
highlighting.
* codeblocks-paper: Same as codeblocks, but on a white background. ( Actually light grey. )
* codeblocks-paper: Same as codeblocks, but on a white background. (Actually
light grey)
* github-tc: A colorscheme based on Github's syntax highlighting. Requires true color to look its best.
* github-tc: A colorscheme based on Github's syntax highlighting. Requires true
color to look its best.
* paper-tc: A nice minimalist theme with a light background, good for editing documents on.
Requires true color to look its best. Not to be confused with `-paper` suffixed themes.
* paper-tc: A nice minimalist theme with a light background, good for editing
documents on. Requires true color to look its best. Not to be confused with
`-paper` suffixed themes.
* geany: Colorscheme based on geany's default highlighting.
* geany-alt-tc: Based on an alternate theme bundled with geany.
* flamepoint-tc: A fire inspired, high intensity true color theme written by CaptainMcClellan.
As with all the other `-tc` suffixed themes, it looks its best on a
* flamepoint-tc: A fire inspired, high intensity true color theme written by
CaptainMcClellan. As with all the other `-tc` suffixed themes, it looks its
best on a
To enable one of these colorschemes just press CtrlE in micro and type `set colorscheme solarized`.
(or whichever one you choose). You can also use `set colorscheme monochrome` if you'd prefer
to have just the terminal's default foreground and background colors.
Note: This provides no syntax highlighting!
To enable one of these colorschemes just press CtrlE in micro and type
`set colorscheme solarized`. (or whichever one you choose). You can also use
`set colorscheme monochrome` if you'd prefer to have just the terminal's default
foreground and background colors. Note: This provides no syntax highlighting!
See `help gimmickcolors` for a list of some true colour themes that are more
just for fun than for serious use. ( Though feel free if you want! )
just for fun than for serious use. (Though feel free if you want!)
---
### Creating a Colorscheme
## Creating a Colorscheme
Micro's colorschemes are also extremely simple to create. The default ones can be found
Micro's colorschemes are also extremely simple to create. The default ones ca
be found
[here](https://github.com/zyedidia/micro/tree/master/runtime/colorschemes).
They are only about 18-30 lines in total.
Basically to create the colorscheme you need to link highlight groups with actual colors.
This is done using the `color-link` command.
Basically to create the colorscheme you need to link highlight groups with
actual colors. This is done using the `color-link` command.
For example, to highlight all comments in green, you would use the command:
@@ -109,20 +115,22 @@ color-link comment "bold red"
There are three different ways to specify the color.
Color terminals usually have 16 colors that are preset by the user. This means that
you cannot depend on those colors always being the same. You can use those colors with
the names `black, red, green, yellow, blue, magenta, cyan, white` and the bright variants
of each one (brightblack, brightred...).
Color terminals usually have 16 colors that are preset by the user. This means
that you cannot depend on those colors always being the same. You can use those
colors with the names `black, red, green, yellow, blue, magenta, cyan, white`
and the bright variants of each one (brightblack, brightred...).
Then you can use the terminals 256 colors by using their numbers 1-256 (numbers 1-16 will
refer to the named colors).
Then you can use the terminals 256 colors by using their numbers 1-256 (numbers
1-16 will refer to the named colors).
If the user's terminal supports true color, then you can also specify colors exactly using
their hex codes. If the terminal is not true color but micro is told to use a true color colorscheme
it will attempt to map the colors to the available 256 colors.
If the user's terminal supports true color, then you can also specify colors
exactly using their hex codes. If the terminal is not true color but micro is
told to use a true color colorscheme it will attempt to map the colors to the
available 256 colors.
Generally colorschemes which require true color terminals to look good are marked with a `-tc` suffix
and colorschemes which supply a white background are marked with a `-paper` suffix.
Generally colorschemes which require true color terminals to look good are
marked with a `-tc` suffix and colorschemes which supply a white background are
marked with a `-paper` suffix.
---
@@ -140,9 +148,10 @@ Here is a list of the colorscheme groups that you can use:
* underlined
* error
* todo
* statusline ( Color of the statusline)
* tabbar ( Color of the tabbar that lists open files.)
* indent-char ( Color of the character which indicates tabs if the option is enabled)
* statusline (Color of the statusline)
* tabbar (Color of the tabbar that lists open files)
* indent-char (Color of the character which indicates tabs if the option is
enabled)
* line-number
* gutter-error
* gutter-warning
@@ -150,29 +159,30 @@ Here is a list of the colorscheme groups that you can use:
* current-line-number
* color-column
* ignore
* divider ( Color of the divider between vertical splits. )
* divider (Color of the divider between vertical splits)
Colorschemes must be placed in the `~/.config/micro/colorschemes` directory to be used.
Colorschemes must be placed in the `~/.config/micro/colorschemes` directory to
be used.
---
In addition to the main colorscheme groups, there are subgroups that you can
specify by adding `.subgroup` to the group. If you're creating your own
custom syntax files, you can make use of your own subgroups.
specify by adding `.subgroup` to the group. If you're creating your own custom
syntax files, you can make use of your own subgroups.
If micro can't match the subgroup, it'll default to the root group, so
it's safe and recommended to use subgroups in your custom syntax files.
If micro can't match the subgroup, it'll default to the root group, so it's
safe and recommended to use subgroups in your custom syntax files.
For example if `constant.string` is found in your colorscheme, micro will
use that for highlighting strings. If it's not found, it will use constant
instead. Micro tries to match the largest set of groups it can find in the
colorscheme definitions, so if, for examle `constant.bool.true` is found then
micro will use that. If `constant.bool.true` is not found but `constant.bool`
is found micro will use `constant.bool`. If not, it uses `constant`.
For example if `constant.string` is found in your colorscheme, micro will us
that for highlighting strings. If it's not found, it will use constant instead.
Micro tries to match the largest set of groups it can find in the colorscheme
definitions, so if, for examle `constant.bool.true` is found then micro will use
that. If `constant.bool.true` is not found but `constant.bool` is found micro
will use `constant.bool`. If not, it uses `constant`.
Here's a list of subgroups used in micro's built-in syntax files.
* comment.bright ( Some filetypes have distinctions between types of comments.)
* comment.bright (Some filetypes have distinctions between types of comments)
* constant.bool
* constant.bool.true
* constant.bool.false
@@ -180,29 +190,32 @@ Here's a list of subgroups used in micro's built-in syntax files.
* constant.specialChar
* constant.string
* constant.string.url
* identifier.class ( Also used for functions. )
* identifier.class (Also used for functions)
* identifier.macro
* identifier.var
* preproc.shebang ( The #! at the beginning of a file that tells the os what script interpreter to use. )
* symbol.brackets ( {}()[] and sometimes <> )
* symbol.operator ( Color operator symbols differently. )
* symbol.tag ( For html tags, among other things.)
* type.keyword ( If you want a special highlight for keywords like `private` )
* preproc.shebang (The #! at the beginning of a file that tells the os what
script interpreter to use)
* symbol.brackets ({}()[] and sometimes <>)
* symbol.operator (Color operator symbols differently)
* symbol.tag (For html tags, among other things)
* type.keyword (If you want a special highlight for keywords like `private`)
In the future, plugins may also be able to use color groups for styling.
## Syntax files
The syntax files is written in yaml-format and specify how to highlight languages.
The syntax files is written in yaml-format and specify how to highlight
languages.
Micro's builtin syntax highlighting tries very hard to be sane, sensible
and provide ample coverage of the meaningful elements of a language. Micro has
Micro's builtin syntax highlighting tries very hard to be sane, sensible and
provide ample coverage of the meaningful elements of a language. Micro has
syntax files built int for over 100 languages now. However, there may be
situations where you find Micro's highlighting to be insufficient or not to
your liking. Good news is you can create syntax files (.micro extension), place them in
`~/.config/micro/syntax` and Micro will use those instead.
situations where you find Micro's highlighting to be insufficient or not to your
liking. Good news is you can create syntax files (.micro extension), place them
in `~/.config/micro/syntax` and Micro will use those instead.
### Filetype defintion
### Filetype definition
You must start the syntax file by declaring the filetype:
@@ -219,8 +232,9 @@ detect:
filename: "\\.go$"
```
Micro will match this regex against a given filename to detect the filetype. You may also
provide an optional `header` regex that will check the first line of the file. For example:
Micro will match this regex against a given filename to detect the filetype. You
may also provide an optional `header` regex that will check the first line of
the file. For example:
```
detect:
@@ -230,9 +244,10 @@ detect:
#### Syntax rules
Next you must provide the syntax highlighting rules. There are two types of rules: patterns and regions.
A pattern is matched on a single line and usually a single word as well. A region highlights between two
patterns over multiple lines and may have rules of its own inside the region.
Next you must provide the syntax highlighting rules. There are two types of
rules: patterns and regions. A pattern is matched on a single line and usually a
single word as well. A region highlights between two patterns over multiple
lines and may have rules of its own inside the region.
Here are some example patterns in Go:
@@ -243,7 +258,8 @@ rules:
- preproc: "\\b(package|import|const|var|type|struct|func|go|defer|iota)\\b"
```
The order of patterns does matter as patterns lower in the file will overwrite the ones defined above them.
The order of patterns does matter as patterns lower in the file will overwrite
the ones defined above them.
And here are some example regions for Go:
@@ -269,12 +285,15 @@ And here are some example regions for Go:
- todo: "(TODO|XXX|FIXME):?"
```
Notice how the regions may contain rules inside of them. Any inner rules that are matched are then skipped when searching
for the end of the region. For example, when highlighting `"foo \" bar"`, since `\"` is matched by an inner rule in the
region, it is skipped. Likewise for `"foo \\" bar`, since `\\` is matched by an inner rule, it is skipped, and then the `"`
is found and the string ends at the correct place.
Notice how the regions may contain rules inside of them. Any inner rules that
are matched are then skipped when searching for the end of the region. For
example, when highlighting `"foo \" bar"`, since `\"` is matched by an inner
rule in the region, it is skipped. Likewise for `"foo \\" bar`, since `\\` is
matched by an inner rule, it is skipped, and then the `"` is found and the
string ends at the correct place.
You may also explicitly mark skip regexes if you don't want them to be highlighted. For example:
You may also explicitly mark skip regexes if you don't want them to be
highlighted. For example:
```
- constant.string:
@@ -286,8 +305,8 @@ You may also explicitly mark skip regexes if you don't want them to be highlight
#### Includes
You may also include rules from other syntax files as embedded languages. For example, the following is possible
for html:
You may also include rules from other syntax files as embedded languages. For
example, the following is possible for html:
```
- default: