Previously, two underscore characters in a document would mark the entire
space between them as italic, no matter how far apart. Now we only accept a
single consecutive newline within an inline-formatted span, so hard-wrapped
documents will still format nicely but stray characters won't mess up your
entire document.
Note that the highlighter for backtick-enclosed spans was modified,
even though it's redundant with the code-block highlighting introduced
in 5bc62c694.
As well as the traditional `[text](url)` syntax, Markdown allows the text to
be followed by a tag in square brackets. If the text is followed by nothing
at all, then the tag for that link is the text itself. The actual URL
is supplied later in the document, like a footnote at the bottom of the page:
Some text with [a link][tag] and [another link].
[tag]: http://www.example.com/link1
[another link]: http://www.example.com/link2
This adds the "link" face to the URL in such footnote lines.
There does not seem to be any reasonable use cases of not collapsing
jumps when the input is not comming from the user. Always collapse
them.
It could make sense to move jump collapsing out of context_wrap as
in general any action not comming directly from the user should
collapse them, at the moment a comment or mapping will not collapse
jumps, which is unfortunate.
With the introduction of -match-capture for the lua region highlighter,
the string closing regex had spurious captures that were not going to
match.
Fixes#1850
This commit avoids false positives when highlighting literals such as
`$window`, which is a regular variable but still highlighted as a
special value.
Special highlighting of variables that start with a dollar sign `$`
was also removed, as not all variables start with a dollar sign,
and we don't have a reliable way yet to detect variables.
unsetting static_words whenever any buffer filetype is set to non ocaml
is wrong, it breaks static_words for every filetype whose filetype hook
run before the ocaml ones.
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.
