syntect
syntect
is a syntax highlighting library for Rust that uses Sublime Text syntax definitions. It aims to be a good solution for any Rust project that needs syntax highlighting, including deep integration with text editors written in Rust. It's used in production by at least two companies, and by many open source projects.
If you are writing a text editor (or something else needing highlighting) in Rust and this library doesn't fit your needs, I consider that a bug and you should file an issue or email me. I consider this project mostly complete, I still maintain it and review PRs, but it's not under heavy development.
Important Links
- API docs with examples: https://docs.rs/syntect
- Changelogs and upgrade notes for past releases
Getting Started
syntect
is available on crates.io. You can install it by adding this line to your Cargo.toml
:
= "3.2"
After that take a look at the documentation and the examples.
If you've cloned this repository, be sure to run
git submodule update --init
to fetch all the required dependencies for running the tests.
Features/Goals
- Work with many languages (accomplished through using existing grammar formats)
- Highlight super quickly, faster than nearly all text editors
- Include easy to use API for basic cases
- API allows use in fancy text editors with piece tables and incremental re-highlighting and the like.
- Expose internals of the parsing process so text editors can do things like cache parse states and use semantic info for code intelligence
- High quality highlighting, supporting things like heredocs and complex syntaxes (like Rust's).
- Include a compressed dump of all the default syntax definitions in the library binary so users don't have to manage a folder of syntaxes.
- Well documented, I've tried to add a useful documentation comment to everything that isn't utterly self explanatory.
- Built-in output to coloured HTML
<pre>
tags or 24-bit colour ANSI terminal escape sequences. - Nearly complete compatibility with Sublime Text 3, including lots of edge cases. Passes nearly all of Sublime's syntax tests, see issue 59.
- Load up quickly, currently in around 23ms but could potentially be even faster.
Screenshots
There's currently an example program called syncat
that prints one of the source files using hard-coded themes and syntaxes using 24-bit terminal escape sequences supported by many newer terminals. These screenshots don't look as good as they could for two reasons: first the sRGB colours aren't corrected properly, and second the Rust syntax definition uses some fancy labels that these themes don't have highlighting for.
Example Code
Prints highlighted lines of a string to the terminal. See the easy and html module docs for more basic use case examples.
use HighlightLines;
use SyntaxSet;
use ;
use ;
// Load these once at the start of your program
let ps = load_defaults_newlines;
let ts = load_defaults;
let syntax = ps.find_syntax_by_extension.unwrap;
let mut h = new;
let s = "pub struct Wow { hi: u64 }\nfn blah() -> u64 {}";
for line in from
Performance
Currently syntect
is one of the faster syntax highlighting engines, but not the fastest. The following perf features are done and to-be-done:
- Pre-link references between languages (e.g
<script>
tags) so there are no tree traversal string lookups in the hot-path - Compact binary representation of scopes to allow quickly passing and copying them around
- Determine if a scope is a prefix of another scope using bit manipulation in only a few instructions
- Cache regex matches to reduce number of times oniguruma is asked to search a line
- Accelerate scope lookups to reduce how much selector matching has to be done to highlight a list of scope operations
- Lazily compile regexes so startup time isn't taken compiling a thousand regexs for Actionscript that nobody will use
- Use a better regex engine, perhaps the in progress fancy-regex crate
- Parallelize the highlighting. Is this even possible? Would it help? To be determined.
The current perf numbers are below. These numbers may get better if more of the things above are implemented, but they're better than many other text editors. All measurements were taken on a mid 2012 15" retina Macbook Pro.
- Highlighting 9200 lines/247kb of jQuery 2.1 takes 600ms. For comparison:
- Textmate 2, Spacemacs and Visual Studio Code all take around 2ish seconds (measured by hand with a stopwatch, hence approximate).
- Atom takes 6 seconds
- Sublime Text 3 dev build takes 98ms (highlighting only, takes ~200ms click to pixels), despite having a super fancy javascript syntax definition.
- Vim is instantaneous but that isn't a fair comparison since vim's highlighting is far more basic than the other editors (Compare vim's grammar to Sublime's).
- These comparisons aren't totally fair, except the one to Sublime Text since that is using the same theme and the same complex definition for ES6 syntax.
- Simple syntaxes are faster, JS is one of the most complex. It only takes 34ms to highlight a 1700 line 62kb XML file or 50,000 lines/sec.
- ~138ms to load and link all the syntax definitions in the default Sublime package set.
- but only ~23ms to load and link all the syntax definitions from an internal pre-made binary dump with lazy regex compilation.
- ~1.9ms to parse and highlight the 30 line 791 character
testdata/highlight_test.erb
file. This works out to around 16,000 lines/second or 422 kilobytes/second. - ~250ms end to end for
syncat
to start, load the definitions, highlight the test file and shut down. This is mostly spent loading.
Feature Flags
Syntect makes heavy use of cargo features, to support users who require only a subset of functionality. In particular, it is possible to use the highlighting component of syntect without the parser (for instance when hand-rolling a higher performance parser for a particular language), by adding default-features = false
to the syntect entry in your Cargo.toml
.
For more information on available features, see the features section in Cargo.toml
.
Caching
Because syntect
's API exposes internal cacheable data structures, there is a caching strategy that text editors can use that allows the text on screen to be re-rendered instantaneously regardless of the file size when a change is made after the initial highlight.
Basically, on the initial parse every 1000 lines or so copy the parse state into a side-buffer for that line. When a change is made to the text, because of the way Sublime Text grammars work (and languages in general), only the highlighting after that change can be affected. Thus when a change is made to the text, search backwards in the parse state cache for the last state before the edit, then kick off a background task to start re-highlighting from there. Once the background task highlights past the end of the current editor viewport, render the new changes and continue re-highlighting the rest of the file in the background.
This way from the time the edit happens to the time the new colouring gets rendered in the worst case only 999+length of viewport
lines must be re-highlighted. Given the speed of syntect
even with a long file and the most complicated syntax and theme this should take less than 100ms. This is enough to re-highlight on every key-stroke of the world's fastest typist in the worst possible case. And you can reduce this asymptotically to the length of the viewport by caching parse states more often, at the cost of more memory.
Any time the file is changed the latest cached state is found, the cache is cleared after that point, and a background job is started. Any already running jobs are stopped because they would be working on old state. This way you can just have one thread dedicated to highlighting that is always doing the most up-to-date work, or sleeping.
Parallelizing
Since 3.0, syntect
can be used to do parsing/highlighting in parallel. SyntaxSet
is both Send
and Sync
and so can easily be used from multiple threads. It is also Clone
, which means you can construct a syntax set and then clone it to use for other threads if you prefer.
Compared to older versions, there's nothing preventing the serialization of a SyntaxSet
either. So you can directly deserialize a fully linked SyntaxSet
and start using it for parsing/highlighting. Before, it was always necessary to do linking first.
It is worth mentioning that regex compilation is done lazily only when the regexes are actually needed. Once a regex has been compiled, the compiled version is used for all threads after that. Note that this is done using interior mutability, so if multiple threads happen to encounter the same uncompiled regex at the same time, compiling might happen multiple times. After that, one of the compiled regexes will be used. When a SyntaxSet
is cloned, the regexes in the cloned set will need to be recompiled currently.
For adding parallelism to a previously single-threaded program, the recommended thread pooling is rayon
. However, if you're working in an already-threaded context where there might be more threads than you want (such as writing a handler for an Iron request), the recommendation is to force all highlighting to be done within a fixed-size thread pool using rust-scoped-pool
. An example of the former is in examples/parsyncat.rs
.
Examples Available
There's a number of examples of programs that use syntect
in the examples
folder and some code outside the repo:
syncat
prints a highlighted file to the terminal using 24-bit colour ANSI escape codes. It demonstrates a simple file highlighting workflow.synhtml
prints an HTML file that will display the highlighted code. Demonstrates how syntect could be used by web servers and static site generators.synstats
collects a bunch of statistics about the code in a folder. Includes basic things like line count but also fancier things like number of functions. Demonstrates howsyntect
can be used for code analysis as well as highlighting, as well as how to use the APIs to parse out the semantic tokenization.faiyels
is a little code minimap visualizer I wrote that usessyntect
for highlighting.parsyncat
is likesyncat
, but accepts multiple files and highlights them in parallel. It demonstrates how to usesyntect
from multiple threads.
Here's that stats that synstats
extracts from syntect
's codebase (not including examples and test data) as of this commit:
################## Stats ###################
File count: 19
Total characters: 155504
Function count: 165
Type count (structs, enums, classes): 64
Code lines (traditional SLOC): 2960
Total lines (w/ comments & blanks): 4011
Comment lines (comment but no code): 736
Blank lines (lines-blank-comment): 315
Lines with a documentation comment: 646
Total words written in doc comments: 4734
Total words written in all comments: 5145
Characters of comment: 41099
Projects using Syntect
Below is a list of projects using Syntect, in approximate order by how long they've been using syntect
(feel free to send PRs to add to this list):
- Zola, a static site generator that uses
syntect
for highlighting code snippets. - xi-editor, a text editor in Rust which uses
syntect
for highlighting. - Scribe, a Rust text editor framework which uses
syntect
for highlighting. - tokio-cassandra, CQL shell in Rust, uses
syntect
for shell colouring. - Cobalt, a static site generator that uses
syntect
for highlighting code snippets. - catmark, a console markdown printer, uses
syntect
for code blocks. - crowbook, a Markdown book generator, uses
syntect
for code blocks. - syntect_server, an HTTP server for syntax highlighting.
- mdcat, a console markdown printer, uses
syntect
for code blocks. - bat, a
cat(1)
clone, usessyntect
for syntax highlighting. - hors, instant coding answers via command line, uses
syntect
for highlighting code blocks.
License and Acknowledgements
Thanks to Robin Stocker and also Keith Hall for making awesome substantial contributions of the most important impressive improvements syntect
has had post-v1.0
! They deserve lots of credit for where syntect
is today.
Thanks to Textmate 2 and @defuz's sublimate for the existing open source code I used as inspiration and in the case of sublimate's tmTheme
loader, copy-pasted. All code (including defuz's sublimate code) is released under the MIT license.