Previously, a code block was anything between triple-backtics, including inline
blocks:
some text ```
not a codeblock, but highlighted as one
``` other text
and even if the closing backticks had the wrong indent:
```
this is a code block containing a triple backtick
```
this is still a code block, but Kakoune thinks otherwise
```
Now we use the -match-capture flag to ensure the start and end fences have
exactly the same indent.
Previously, the generic code-block region was defined first, which meant that
it took priority over all the language-specific highlighters. Now we define
the generic code-block highlighting *after* the others, which fixes#2304.
Previously, code-spans were defined as ordinary inline markup, but in Markdown
ordinary formatting doesn't work inside code-spans. Therefore, they are now
regions unto themselves, defined according to section 6.3 of the CommonMark
spec <https://spec.commonmark.org/0.28/#code-spans>, which addresses a comment
on #2111.
Some syntax checkers (such as `cppcheck`) like to pass
extra-information using a regular diagnostic line - but with null
coordinates (0:0).
This commit makes the `:lint` command ignore such messages, to prevent
`set-option` from failing when assigning coordinates to `lint_flags`, and to avoid unecessary information in the `*lint-output*` buffer.
According to the Rust language reference[1], a raw string starts with an 'r',
zero or more '#' characters, and a '"', and doesn't close until a '"' is
immediately followed by the matching number of '#' characters.
[1]: https://doc.rust-lang.org/reference/tokens.html#raw-string-literals
* Make clang.kak compatible with POSIX `[`.
* Make lint.kak dump range/line-specs correctly. It still doesn't read them
correctly -- that'll be easier after the upcoming $kak_ changes for lists.
Now that we have a nice standard way to express lists of strings,
registers can be fully exposed. An new $kak_main_reg_... env var
was added to provide the previous behaviour which is relied on by
doc.kak.
Automatic reparsing of %sh{...}, while convenient in many cases,
can be surprising as well, and can lead to security problems:
'echo %sh{ printf "foo\necho bar" }' runs 'echo foo', then 'echo bar'.
we make this danger explicit, and we fix the 'nop %sh{...}' pattern.
To reparse %sh{...} strings, they can be passed to evaluate-commands,
which has been fixed to work in every cases where %sh{...} reparsing
was used..
Note: `GNU/screen` has a different interpretation of what constitutes
a "vertical split", hence the inverted command descriptions, compared
to the tmux/iterm etc.
Closes#1626
