1. Deleted back-tick strings which are not a valid Dart syntax
2. Added string interpolation for ${}
3. NOT adding string interpolation for $var as this is considered a bad practice
This commit adds highlighting characters other than the first with red color helping to get immediate feedback of the syntax error.
This helps those who come from languagles like JS where single quotes also denote multi-character strings.
Adding highlighting for string interpolation inside double-quoted strings and character literals inside single-quotes.
Avoiding string interpolation in the form of $var as this is considered bad practice.
The off-by-one was introduced by cd9b1e66 which changed `column-1` to `column`.
The refactoring solves some esoteric quoting errors: I think cases like
unbalanced braces in the bufname and client were not supported.
* bring colors more aligned with upstream solarized implementations
(e.g. vim, emacs)
* tweak rust syntax
* add more details, like operators, highlighting certain traits and
types from std, etc
* remove certain highlighters, like user types. This has the effect
of just highlighting almost the whole code base one color, and
wasn't really correct either. CamelCase for types is only convention
Updates to address these comments:
"I still dont quite see why we need to introduce all those options, especially with names that dont say anything about kotlin. I would expect a single kotlin_static_words option to be enough.
Similarly, a single highlighter should be enough here."
This should cover all filetypes that already auto-insert comments,
except for rust.kak, which is left for a follow-up.
Most of these are straightforward, some explanation for special cases:
rc/filetype/zig.kak rc/filetype/cue.kak
These indent hooks used their own logic to indent after "{" only if
no comment was inserted. Replace this logic by checking if a comment
was inserted. This works because these "*-insert" hooks are run
before their respective "*-indent" hooks.
rc/filetype/php.kak
This also has some logic to insert "*" after "/*" lines. Basic
usage seems to work still. In future this should borrow from the
c-family one, which works a bit better.
Function taking a parameter with a struct tag on the last line
before the opening { were wrongly treated as structs. Add some
additional regex logic to try to catch those cases.
Fixes#4136
