Kakoune's balanced strings require that delimiter characters nested inside
them are also paired, so for example in %{ }, each nested { must occur
before a corresponding } to balance it out.
In general this will automatically be the case for code in common scripting
languages, but sometimes regular expressions used for syntax highlighting
do end up containing an unbalanced bracket of one type or another.
This problem is easily solved because there is a free choice of balanced
delimiter characters. However, it can also be worked around by adding
a comment which itself contains an unbalanced delimiter character, to
'balance out' the unpaired one in the regular expression.
These unbalanced comments are not ideal as the semantic role they perform
is easy for a casual reader to overlook. A good example is
catch %{
# indent after lines with an unclosed { or (
try %< execute-keys -draft [c[({],[)}] <ret> <a-k> \A[({][^\n]*\n[^\n]*\n?\z <ret> j<a- gt> >
# indent after a switch's case/default statements
try %[ execute-keys -draft kx <a-k> ^\h*(case|default).*:$ <ret> j<a-gt> ]
# deindent closing brace(s) when after cursor
try %[ execute-keys -draft x <a-k> ^\h*[})] <ret> gh / [})] <ret> m <a-S> 1<a-&> ]
}
in rc/filetype/go/kak. Here, it is not instantly obvious that the comment
containing an unmatched { is required for correctness. If you change the
comment, delete it or rearrange the contents of the catch block, go.kak
will fail to load, and if you cut-and-paste this code as the basis for
a new filetype, it is a loaded gun pointing at your feet.
Luckily, a careful audit of the standard kakoune library turned up only
three such instances, in go.kak, hare.kak and markdown.kak.
The examples in go.kak and hare.kak are easily made robust by replacing
a %{ } with %< > or %[ ] respectively. The example in markdown.kak is
least-intrusively fixed by rewriting the affected regular expression
slightly so it has balanced { and } anyway.
The current handling of preprocessor directives in filetype/c-family.kak
leads to a wall of solid colour for more complicated #if or #define
directives, although #include is already nicely highlighted.
Instead of highlighting an entire directive with the meta face, highlight
just the #define, #if or #elif keyword as meta, treating the rest of the
directive as normal c-family expressions. This significantly improves
the readability of complex macro definitions.
For directives other than #define, #if and #elif, we treat the rest of
the directive as an opaque string in normal face rather than trying to
highlight it, covering cases like #error, #pragma, etc. where the rest
of the line is an error message string or other non-expression content.
This does the right thing for #ifdef and #ifndef too, as we don't highlight
identifiers in c-family text so their arguments should be normal face
anyway.
We already pull in the diff module in mail.kak to enable the nice
:diff-jump behaviour on inline patches. Also enable the shared/diff/
highlighter underneath our shared/mail/ highlighter for inline diffs,
listing it first so mail patterns take precedence over diff patterns.
De-emphasise signatures including the standard '^-- \n' separator in the
same way as quoted text in a reply.
Fixes: https://github.com/mawww/kakoune/issues/4998
prompt has fuzzy filtering which is more discoverable than the menu
mode's regex filtering (because that one needs / to trigger it).
There are no important differences left, so replace the menu builtin
with a prompt-based command.
prompt does not support markup in the completion menu, so drop that
feature for now.
This makes Kakoune behave more consistently when using it for Zig.
Empty comments are already auto-removed from the C-family and Python.
In this PR, string literals that start with \\ are not removed in purpose.
This continues the work started by 0a9c90fec (rc: use a separate
*-insert hook to auto-insert comments, 2021-04-17).
The one that's left is Rust but that one is trickier.