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.
Since the gocode completions contain white space, they cannot be used without quotations.
Also, since I'm in there, the buffer should be quoted for heathens who use white space in their paths.
These templates are simple shell scripts, similar to PKGBUILDs.
They reside in srcpkgs, so we can use this to identify if
`template` really is a Void Linux package template.
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.
Unfortunately Strings that start with a quoted quote (like '''str')
are still incorrectly highlighted, a deeper refactoring of the regions
highlighter will be necessary.
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
A Rust data structure that is generic over a type conventionally uses a single
capital letter for the type variable, like `Vec<T>` or `HashMap<K, V>`. A Rust
data structure that is generic over a reference-lifetime conventionally uses an
apostrophe followed by a single lower-case letter for the lifetime variable,
like `Something<'a>`.
Previously, Kakoune would highlight "'a>" as the lifetime parameter; with this
change Kakoune highlights "'a" and leaves the closing ">" alone.
The :format command is often called from a BufWritePre hook to format the
current buffer, however the :format command itself calls `:write` to store the
buffer in a temporary location, potentially causing an infinite recursion.
If we disable hooks while running :format, there's no danger of that occurring.
Changes:
- Highlight float literals with float type suffixes (nf64 and nf32)
- Make module items use the module color
- Highlight macro variables $variable
- Highlight lifetimes
- Highlight u128 and i128
- Highlight character literals (e.g. 'a')
- Highlight dyn keyword (will in the future be used for trait objects)
Previously, due to a typo, Kakoune would highlight backtick spans from the first backtick to the last backtick in a paragraph, no matter how many backticks were in between. Now spans correctly stop at the first backtick after the opening backtick.
even though tmux 2.7 is installed.
The problem is that
```
expr "$(tmux -V)" : 'tmux \([0-9]*\|master\)'
```
fails on FreeBSD. It works fine with GNU expr.
Replace the expression with cut(1) and a simple parameter expansion
which should hopefully work fine on any POSIX system.
Signed-off-by: Tobias Kortkamp <git@tobik.me>
set-face now takes a scope argument, and faces can be overridden on
a buffer or window basis.
colorscheme apply on global scope, which should be good enough for
now.
Fixes#1411
Instead of starting the default shell and sending it text (hoping
it will support POSIX like shell syntax), just use the `env` utility
to set the correct environment and exec kakoune.
- Added <?php and ?> tags, and highlight everything outside as html
- Highlight documentation comments and @fields
- Added basic string interpolation highlighting
Letting any character to be escaped is error prone as it looks like
\l could mean [:lower:] (as it used to with boost) when it only means
literal l.
Fix the haskell.kak file as well.
Fixes#1945
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.
