Removing the handlebars highlighters when a client toggles away from hbs window unintentionally causes
other clients attached to hbs windows to no longer highlight correctly. The only other option is to
copy the entire html highlighter and all of it's rules, but that seems like a maitenance headache.
So instead, just leave the hbs rules injected into the html rules once the user opens any handlebars file.
It's not ideal, but I'd say it's the least bad option.
This commit also introduces a regression in that I decided that the best way to
avoid overly long and confusing names was to rename the current shell-*
switches to script-*, and have the shell command completion be
shell-completion.
renamed script-{completion,candidates} to shell-script-*
Updated docs with new switch names
Added -shell-completion switch to x11-repl and kitty-repl
Algol-like indenting doesn't work for Lisp as we tend to open (and
close) many forms on one line. This generally puts the cursor
where it should be, though it is probably confused by strings
with brackets and things.
- Removes -recurse from handlebars comments. Handlebars parsers (janl/mustache.js, ember-cli/ember-cli-htmlbars), do not treat comments as recursive, so don't highlight them as so.
- Creates shared/hbs-file highligher group. This represents a handlebars file, which is html that happens to contain some handlebars tags.
- Augments the shared/html highlighter when needed. Because handlebars lives inside of html, we need to add the highlighter inside of it. Since there's no way to scope modifications of a shared highlighter to a window, here I'm modifying/unmodifying the shared/html highlighter whenever the user attaches/detaches a filetype of "hbs" to/from the window.
- Matches namespaced helpers as well. In htmlbars, helpers (components) can have '/'s in them, so make sure to continue highlighting through those. Also removes unused capturing groups.
- Allows for de-indenting when closing a block expression
- Brings in html highlighter hooks
- Improves indent matching on close of yielded blocks. Previous version just flat out didn't work.
Use regions to avoid highlighting the commit message as a diff.
The new method will fail if one line of the commit message matches
'^diff --git' but that is fairly unlikely.
Fixes#2371
Values like `0xffffffffffffffffull` were highlighted only till first `u` leaving `ll` without highlighting. This change addresses this issue. It also adds uppercase `ULL` highlighting in values.
Previously, one of the syntaxes for italic was (greatly summarized) something
like this:
[^_]_[^_]+_[^_]
That is to say, the regex matched the blanks on both sides of the italic span,
as well as the actual span content. That means that if you had consecutive
italic words:
_some_ _italic_ _words_
...only the odd-numbered words would be highlighted: the space after "_some_"
was counted as part of that span, so it wasn't available as part of "_italic_"
and therefore "_italic_" wouldn't be highlighted. Likewise, if the first word
in a buffer was italic, it wouldn't be highlighted because the first underscore
was not preceded by a non-underscore character!
Now we use lookahead/lookbehind assertions, which don't count as part of the
matched span, so consecutive spans don't interfere with one another.
Fixes#2111.
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.
