- 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.
Also, moved the "Markup strings" section to faces.asciidoc, since it wasn't
anything to do with expansions, and updated various hyperlinks to point at the
new location.
The GitHub issue referenced below describes the default behavior of
the 'm' key in a way that was unknown to me. As the issue says,
"'m' is a pretty misunderstood key", and goes on to describe how
the documentation makes it sound as if the cursor must be on the
matching character before 'm' will work. However, this is not true;
pressing 'm' will jump forward to "select the next sequence enclosed
in balanced chars". This patch updates the documentation so that it
describes that behavior.
GitHub-Issue: #2425
Special-thanks: Delapouite
Final is more granular, it consists of FinalFg (f), FinalBg (g)
and FinalAttr (a) which control if a face's fg, bg, or attributes
fully overwrite the previous face (instead of merging) and if
following faces apply on top of this face or not.
Fixes#2388 if the Whitespace face has the FinalFg flag.
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.
