Using `{\}` in an Awk script results in the following error being printed:
```
awk: cmd. line:18: warning: escape sequence `\}' treated as plain `}'
```
The selection descriptions use the format
`<buffer>@<timestamp>@<main_index>`. This fails when file paths have `@`
symbols in them: the parser splits on `@` symbols and finds more values
than it expects.
We here modify the behavior to require *at least* two @ symbols, using
the last two for `<timestamp>` and `<main_index>` and leaving the
remaining text for the <buffer>. This should work for any number of `@`
symbols, since `<timestamp>` and `<main_index>` are numbers and should
never contain `@` symbols.
The description of startup_info_version in the manual says "only messages
relating to a Kakoune version greater than this value will be displayed,"
but showed messages relating to the version equal to that value.
This change aligns the code with the manual and makes a workaround that set
startup_info_version next to the original version (ex. 20200117) unnecessary.
Signed-off-by: Masanori Ogino <masanori.ogino@gmail.com>
I dedicate any and all copyright interest in this software to the public
domain. I make this dedication for the benefit of the public at large
and to the detriment of my heirs and successors. I intend this
dedication to be an overt act of relinquishment in perpetuity of all
present and future rights to this software under copyright law.
I dedicate any and all copyright interest in this software to the
public domain. I make this dedication for the benefit of the public at
large and to the detriment of my heirs and successors. I intend this
dedication to be an overt act of relinquishment in perpetuity of all
present and future rights to this software under copyright law.
Previously, the keywords were a mess. They contained the shell’s
reserved words and some arbitrarily selected builtins. I generated
the word list using bash because it contains all POSIX builtins and
is common for scripting.
In variable assignments some characters that are allowed to be in
variables used to not be highlighted, e.g. hyphens. With this commit
all characters except whitespace are considered to be part of the
variable.
I dedicate any and all copyright interest in this software to the
public domain. I make this dedication for the benefit of the public at
large and to the detriment of my heirs and successors. I intend this
dedication to be an overt act of relinquishment in perpetuity of all
present and future rights to this software under copyright law.
I dedicate any and all copyright interest in this software to the
public domain. I make this dedication for the benefit of the public at
large and to the detriment of my heirs and successors. I intend this
dedication to be an overt act of relinquishment in perpetuity of all
present and future rights to this software under copyright law.
This commit implements a standalone shared highlighter group that
highlights Jinja statements and expressions.
The traditional way of highlighting file contents is to hook on the
file extension, and assign a custom filetype/highlighter group to
the current buffer. However, since Jinja templates can be based on
any text file format in existence, we do not have a specific file
extension to hook, and consequently, no custom "jinja" filetype.
The user is expected to add the `jinja` highlighter whenever required:
```
require-module jinja
add-highlighter window/ ref jinja
```
Alternatively, file extensions that are known to occasionally pair
with Jinja can be hooked from the user configuration:
```
hook global WinCreate .+\.html %[
try %[
execute-keys -draft \%s \{%|\{\{ <ret>
require-module jinja
add-highlighter window/ ref jinja
]
]
```
The above hook auto-detects statements/expressions (respectively
{%…%} and {{…}} expansions), but will cause false positives
(in terms of highlighting), and therefore isn't part of `jinja.kak`
by default.
When a region calls the regex highlighter, it is incorrect to share
the regex cache as it means we can get matches that span multiple
regions.
Fixes#3041
