- 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
-
-* 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.
-
-* zenburn: The 'zenburn' colorscheme and works well with 256 color terminals
+## Colorschemes
-* solarized: this is the solarized colorscheme.
- You should have the solarized color palette in your terminal to use it.
+To change your colorscheme, press Ctrl-E in micro to bring up the command
+prompt, and type:
+```
+set colorscheme solarized
+```
+(or whichever colorscheme you choose).
-* 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.
+Micro comes with a number of colorschemes by default. Here is the list:
-* atom-dark-tc: this colorscheme is based off of Atom's "dark" colorscheme.
- It requires true color to look good.
+### 256 color
-* 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.
+These should work and look nice in most terminals. I recommend these
+themes the most.
-* cmc-paper: Basically cmc-16, but on a white background. ( Actually light grey on most
- ANSI (16-color) terminals.)
+* `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`
+* `gruvbox`
+* `darcula`
+* `twilight`
+* `railscast`
+* `bubblegum`: a light colorscheme
-* 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.
+### 16 color
-* codeblocks: A colorscheme based on the Code::Blocks IDE's default syntax highlighting.
+These may vary widely based on the 16 colors selected for your terminal.
-* codeblocks-paper: Same as codeblocks, but on a white background. ( Actually light grey. )
+* `simple`: this is the simplest colorscheme. It uses 16 colors which are set by
+ your terminal
+* `solarized`: You should have the solarized color palette in your terminal to use this colorscheme properly.
+* `cmc-16`
+* `cmc-paper`: cmc-16, but on a white background. (Actually light grey
+ on most ANSI (16-color) terminals)
+* `geany`: Colorscheme based on geany's default highlighting.
-* github-tc: A colorscheme based on Github's syntax highlighting. Requires true color to look its best.
+### True color
-* 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.
+These require terminals that support true color and require `MICRO_TRUECOLOR=1` (this is an environment variable).
-* geany: Colorscheme based on geany's default highlighting.
+* `solarized-tc`: this is the solarized colorscheme for true color.
+* `atom-dark-tc`: this colorscheme is based off of Atom's "dark" colorscheme.
+* `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.
+* `gruvbox-tc`: The true color version of the gruvbox colorscheme
+* `github-tc`: The true color version of the Github colorscheme
-* geany-alt-tc: Based on an alternate theme bundled with geany.
+### Monochrome
-* 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
+You can also use `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!
+### Other
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 can
+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:
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.
---
* 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
* 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
* 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
-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.
+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 in for over 100 languages now! However, there may be
+situations where you find Micro's highlighting to be insufficient or not to your
+liking. The good news is that you can create your own syntax files, and 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:
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:
#### 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:
- 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:
- 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:
#### 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:
projects / micro.git / blobdiff