Define a command :Run to compile and run the current file. This supports
unnamed buffers (by writing to a temporary file). See the comment above
the command definition for notes on usage.
Define <D-r> and <D-R> mappings for :Run to make it easier to invoke in
MacVim.
Define a command :Expand to display the --pretty expanded output for the
current file. This can be configured to use different pretty types. See
the comment above the command definition for notes on usage.
Create an autoload file and put function definitions there to speed up
load time.
(Expressed another way: make `[[` et al. work with the curly brace at
the end of a line as is standard Rust style, not just at the start is it
is by default in Vim, from K&R style.)
This came out of #11492, where a simpler but less effective technique
was initially proposed; some discussion of the techniques, ways and
means can be found there.
There are still a few caveats:
- Operator-pending mode behaves differently to the standard behaviour:
if inside curly braces, it should delete up to and including the
closing of the outermost curly brace (that doesn't seem to me
consistent with documented behaviour, but it's what it does). Actual
behaviour (the more logical and consistent, in my opinion): up to the
start of the next outermost curly brace.
- With folding enabled (`set fdm=syntax`), `[[` and `]]` do not behave
as they should: the default behaviour treats an entire closed fold as
one line for these purposes while this code does not (I explicitly
`set nofoldenable` in the function—the side-effects are worse with
folds enabled), leading to unexpected behaviour, the worst of which is
`[[` and/or `]]` not working in visual mode on a closed fold (visual
mode keeps it at the extreme end of the region line of the folded
region, so it's always going back to the opening line of that fold and
immediately being shoved back to the end by visual mode).
- `[[` and `]]` are operating inside comments, whereas the standard
behaviour skips comments.
- The viewport position is sometimes changed when it should not be
necessary.
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.
