Block comments in Lua were broken, apparently due to the opening
sequence being interpreted as a line comment. Changing the order in the
highlighter seems to fix this issue.
Fixes#1735
We need \K to not interfer with languages own interpretation of ` like multiline strings in javascript
We need \b in e.g. java\b otherwise it blocks javascript
I couldn't get the bare ``` to not block the other highlighters when introducing \K any other way than negative lookahead of all possible highlighers
Commit 870d2d22d7 introduced a regression
in the highlighting of qualified Haskell variables, such as `Foo.bar`.
After that commit `Fo` was highlighted as a constructor (note, not
`Foo`, just `Fo` without the trailing `o`). This restores the original
behavior.
- The proper way to do this would be to switch focus to the target client's region but GNU Screen offers no obvious way to do that.
- Remove screen region after client is closed.
- Assumed: Kak server runs in screen.
- Hack: kak sets `/proc/self/fd/0 -> /dev/null`. Get the client process tty because Screen needs to know the controlling terminal. Else Screen will use the last known tty and will open new windows on a different terminal if one is connected.
As well as ordinary `//` line-comments, Rust regards `///` comments
as documentation applying to the following item, and `//!` comments as
documentation applying to the enclosing item, so we should copy those
to new lines, too.
That means we can now have highlighters active at global, buffer, and
window scope. The add-highlighter and remove-highlighter syntax changed
to take the parent path (scope/group/...) as a mandatory argument,
superseeding the previous -group switch.
boost regex tolerates non-escaped special characters, and escaped
non-special characters. Standardize on stricter syntax, where
special characters must be escaped, and non-special characters must
not.
Highlighting perl regex patterns with regular expressions (with
highlighters) caused several misses that made most of the file
unreadable. This commit makes `perl.kak` not try to highlight
those patterns in the code, and also addresses issues with string
highlighting.
Import keywords are put in keyword face instead of meta face.
This leaves room for pragmas and macros to be in the meta face.
Operator keywords are put in keyword face too.
Finally, expression keywords are put in face attribute.
Previously, if you opened a new line after an underlined heading (what
the CommonMark spec calls a "Setext heading") or inserted a newline into
a line that started with `**strong emphasis**` the Markdown autoindent
hook would assume the leading symbols were list bullets and paste them
at the beginning of the new line.
However, the CommonMark specification says that list bullets must be
followed by at least one horizontal whitespace character, so Setext
heading underlines and strong emphasis are not valid list bullets and
should not be matched by the autoindent pattern.
This commit changes the regex that selects the pastable prefix of the
previous line so that it must match either:
- One or more `>` characters with optional whitespace between them
(a blockquote prefix), optionally followed by a list bullet; or
- An optional blockquote prefix and a list bullet
Since we don't strictly need either the blockquote prefix nor the list
bullet, we could concievably just make both optional... but for lines
without either, the regex would find a zero-length match, and for the
purposes of copy/paste Kakoune treats that as a one-character match.
Therefore, the regex is written to fail if neither pattern is found.
