Sigil highlighting isn't perfect (especially how it handles ``&``) but
after having used it for a week I feel it to be considerably nicer than
nothing. As usual, if you don't like it, you can turn it off easily by
overriding the default highlighting.
Generics are not handled specially; this means that for something like
``S<T>``, the ``<`` and ``>`` are highlighted as operators. For myself,
I like this, and there is no way to make it properly context aware
without expanding the syntax matching enormously.
Also, special characters are highlighted properly in strings/chars, e.g.
``"\x00"`` or ``'\Ufedcba98'`` appropriately.
Note that this is not actually *used* by default; it is a matter of
configuration still, because you might want to:
- Compile all .rs files with `rustc %` (where each can be built itself)
- Compile all .rs files with `rustc some-file.rs` (where you are editing
part of a crate)
- Compile with a different tool, such as `make`. (In this case you might
put a `~/.vim/after/compiler/rustc.vim` to match such cases, set
makeprg and extend errorformat as appropriate. That should probably go
in a different compiler mode, e.g. make-rustc.)
To try using it, `:compiler rustc`. Then, `:make` on a file you would
run `rustc` on will work its magic, invoking rustc. To automate this,
you could have something like `autocmd FileType rust compiler rustc` in
your Vim config.
Note that this is not actually *used* by default; it is a matter of
configuration still, because you might want to:
- Compile all .rs files with `rustc %` (where each can be built itself)
- Compile all .rs files with `rustc some-file.rs` (where you are editing
part of a crate)
- Compile with a different tool, such as `make`. (In this case you might
put a `~/.vim/after/compiler/rustc.vim` to match such cases, set
makeprg and extend errorformat as appropriate. That should probably go
in a different compiler mode, e.g. make-rustc.)
To try using it, `:compiler rustc`. Then, `:make` on a file you would
run `rustc` on will work its magic, invoking rustc. To automate this,
you could have something like `autocmd FileType rust compiler rustc` in
your Vim config.
When it's a lifetime, a single quotation mark shouldn't have a matching
single quotation mark inserted after it, as delimitMate does by default.
Note that this is not without problems; a char literal coming after an
odd number of lifetime markers will have its quotation marks behave a
little strangely. That, however, is not my fault, but delimitMate's:
https://github.com/Raimondi/delimitMate/issues/135
Indentation now works correctly on subsequent lines of a multi-line
comment, whether there are leaders (` * `) or not. (Formerly it was
incorrectly doing a two-space indent if there was no leader.)
By default, this no longer puts a ` * ` leader on `/*!` comments, as
that appears to be the current convention in the Rust source code, but
that can easily be re-enabled if desired:
let g:rust_bang_comment_leader = 1
This improves things like doc comment handling when you press Enter and
making using `gf` or `<C-W>f` work on a `use x;` statement in the
current directory.
- Add fold support (NOT turned on by default)
- Highlight `::` by default
- Support the common `NOTE` as an important note
- Highlight `assert!` and `fail!` differently
- Don't highlight `deriving(...)` except in `#[...]`
