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.
* 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
The invalid regex `)\b` currently matches anything, so this didn't cause
any errors.
It is still invalid though, so I fixed it by moving the `\b` to the end
of the non-raw_attribute language name (like the original regex). The
raw_attribute one shouldn't need this because the `}` marks the end of
the language name anyway.
Fixes#4025
Current solution makes it difficult to use common Lua practices of having one-liner if statements and using anonymous functions.
New solution prevents auto-indentation and end insertion, if the previous line contains an "end" keyword.
It does not attempt to match each structure with corresponding end, since using multiple end keywords in single line is a very rare occurance in Lua.
